Splunk Enterprise Security

Using relative_time to filter results before writing to index

Agent31
Engager

I'm using searches which are relatively noisy and difficult to simply write exclusions for, so one way that I've been writing the search syntax is to use a time-based self suppression in order to only generate results if it hasn't been seen before.

This works in the final search, however it seems like even with the suppression the initial results still get written to the index before the search has had a chance to search back far enough in time to discover that it needs to exclude the results.

Visually what this looks like is a result will appear, then as the search works back in time the result will disappear. However if I look in the risk index I will see that an entry has already been written to the index before the final search completed which should have excluded that entry.

Ultimately I guess the question is: Is there a way to prevent the correlation search writing to the index until the search fully completes?

 

 

| tstats `summariesonly` count earliest(_time) AS first_seen latest(_time) AS last_seen values(Processes.src_user) AS src_user values(Processes.process) AS Processes.process values(Processes.parent_process_name) AS parent_process_name values(Processes.process_name) AS process_name from datamodel=Endpoint.Processes 
    where Processes.process="<some filter">
by Processes.Dest
| where first_seen > relative_time(now(),"-1h") 

 

Labels (1)
0 Karma
Get Updates on the Splunk Community!

Splunk at Cisco Live 2025: Learning, Innovation, and a Little Bit of Mr. Brightside

Pack your bags (and maybe your dancing shoes)—Cisco Live is heading to San Diego, June 8–12, 2025, and Splunk ...

Splunk App Dev Community Updates – What’s New and What’s Next

Welcome to your go-to roundup of everything happening in the Splunk App Dev Community! Whether you're building ...

The Latest Cisco Integrations With Splunk Platform!

Join us for an exciting tech talk where we’ll explore the latest integrations in Cisco &#43; Splunk! We’ve ...