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 Forwarders and Forced Time Based Load Balancing

Splunk customers use universal forwarders to collect and send data to Splunk. A universal forwarder can send ...

NEW! Log Views in Splunk Observability Dashboards Gives Context From a Single Page

Today, Splunk Observability releases log views, a new feature for users to add their logs data from Splunk Log ...

Last Chance to Submit Your Paper For BSides Splunk - Deadline is August 12th!

Hello everyone! Don't wait to submit - The deadline is August 12th! We have truly missed the community so ...