topic Re: Why drilldown using all-time in Enterprise Security Incident Review in Deployment Architecture

Why drilldown using all-time in Enterprise Security Incident Review

zksvc — Tue, 11 Feb 2025 04:44:55 GMT

Hi Everyone, in default correlation search the name "Excessive Failed Logins" my drilldown cannot define $info_min_time$ and $info_max_time$ and it make when click drilldown searching in All-Time. If in every correlation search drilldown is matching the time when it trigger in correlation search, why this one searching in All-Time mode?

Re: Why drilldown using all-time in Enterprise Security Incident Review

livehybrid — Tue, 11 Feb 2025 06:47:49 GMT

Hi @zksvc

Try adding ` | addinfo` to the end of your search, this will add the info_* fields to the results and should let you use them within your drilldown.

Please let me know how you get on and consider accepting this answer or adding karma this answer if it has helped.
Regards

Will

Re: Why drilldown using all-time in Enterprise Security Incident Review

zksvc — Thu, 13 Feb 2025 05:00:51 GMT

Its added some table like this

info_max_time	info_min_time	info_search_time	info_sid
+Infinity	0.000	17398492392.991	123123412132323

Is it because min_time = 0 and max_time = +Infinity? And what would be the solution?

Re: Why drilldown using all-time in Enterprise Security Incident Review

livehybrid — Thu, 13 Feb 2025 08:44:53 GMT

hmm, Is your ES rule looking at All Time? If so, does it need to? This could chew up quite a bit of resource.

Re: Why drilldown using all-time in Enterprise Security Incident Review

zksvc — Thu, 20 Feb 2025 03:46:49 GMT

This rule already has a default from Splunk, with the earliest rt-65m@m and latest rt-5m@m timerange. But doesn't the drilldown only follow the time when the event is triggered?

Re: Why drilldown using all-time in Enterprise Security Incident Review

StuartMacL — Mon, 10 Mar 2025 16:27:08 GMT

Did you find the reason for this?

Since upgrading to ES 8.0.2 all of our Correlation Searchers (Event-driven searches) now use 'All-time' instead of the $info_min_time$ and $info_max_time$ specified in the rule!

Re: Why drilldown using all-time in Enterprise Security Incident Review

zksvc — Tue, 24 Jun 2025 03:48:07 GMT

Removed

Re: Why drilldown using all-time in Enterprise Security Incident Review

LAME-Creations — Tue, 24 Jun 2025 03:51:30 GMT

Just for troubleshooting purposes, can you create a brand new event finding (what used to be called correlation search before splunk ES 8? )

What I like to do is just check to make sure if this is a problem with just this search or is systemic. So I make my search something generic like

index=_internal | head 1 | table index, sourcetype, _time

Again the above query is just a query that you know will have results each time it runs. Feel free to make the search anything you want. Then plug in your drilldown using the same values you applied in your question. When the alert fires and you click its drilldown, does it go all time or does it use the time selection that you gave it.

Again this is just to identify if this is a problem for one correlation search or for all of your correlation searches. This will allow us to get a better idea of what is and what is not working.

Re: Why drilldown using all-time in Enterprise Security Incident Review

Sodaro — Tue, 01 Jul 2025 12:18:00 GMT

Were you able to find a fix for this?

I'd really hate to have to modify all Detections again after prepping for ES8.

Re: Why drilldown using all-time in Enterprise Security Incident Review

zksvc — Mon, 07 Jul 2025 03:22:10 GMT

Unfortunately, I haven't found a fix for this yet.
I hope someone will share the solution so i can mark is as solution and help other people

Re: Why drilldown using all-time in Enterprise Security Incident Review

Collthulhu — Tue, 22 Jul 2025 22:12:30 GMT

I haven't found a fix, but this is how I've been working around it:

In the detection search, make sure to call addinfo .
Then, you can still use info_min/max_time to filter. You just have to do the filtering yourself.

Examples:

index=StuffYouWant starttimeu=$info_min_time$ endtimeu=$info_max_time$ | ...

| from datamodel:"Authentication"."Failed_Authentication" | search _time>$info_min_time$ _time<$info_max_time$ ...