Splunk Search

Help with the search for a reassigned alert?

AL3Z
Builder

Hi, Need a search for the below scenario,

If a previously assigned alert is reassigned to a different user on the portal, it will trigger a new alert because the updated time is considered in the cs. For example, with alert  was initially detected on the  portal  However, when I reassigned the alert to myself last week, a new alert was generated based on the updated time field.

Thanks

Labels (1)
0 Karma
1 Solution

Tom_Lundie
Contributor

There are three options that I can see here, you can either:
a) Make sure that the foundDate occured since the last CS-run so that the CS only ever fires for new events.

| eval founddate_ts = strptime(foundDate, "%Y-%m-%dT%H:%M:%S.%fZ")
| where founddate_ts > relative_time(now(), "-30min")

b) Maintain a lookup of fired alerts so that the same alert doesn't twice.

| eval id = _id
| search NOT [| inputlookup example_lookup | fields id | format]
| appendpipe [| fields id, _time | outputlookup append=t example_lookup]

 c) Throttle the alerts via the CS Configuration:
Throttle Duration: Five Years
Fields to Group By: _id


All three of these have pros / cons, so please experiment with these ideas to see what is right for you and your team.

View solution in original post

Tom_Lundie
Contributor

You can throttle the Correlation Search.

You can read more about throttling here. You could throttle by _id for a sufficient enough time to stop the alerts from re-firing.


0 Karma

AL3Z
Builder

Hi 

@Tom_Lundie 

Could you pls help me with the search with the founddate.

0 Karma

Tom_Lundie
Contributor

There are three options that I can see here, you can either:
a) Make sure that the foundDate occured since the last CS-run so that the CS only ever fires for new events.

| eval founddate_ts = strptime(foundDate, "%Y-%m-%dT%H:%M:%S.%fZ")
| where founddate_ts > relative_time(now(), "-30min")

b) Maintain a lookup of fired alerts so that the same alert doesn't twice.

| eval id = _id
| search NOT [| inputlookup example_lookup | fields id | format]
| appendpipe [| fields id, _time | outputlookup append=t example_lookup]

 c) Throttle the alerts via the CS Configuration:
Throttle Duration: Five Years
Fields to Group By: _id


All three of these have pros / cons, so please experiment with these ideas to see what is right for you and your team.

AL3Z
Builder

@Tom_Lundie  

Hi,

A)Why  we have taken "-30min" 

B) do we need to add the previous founddate values in the lookup table.

C) why the throttle duration is 5 years ?

 

Thanks..

0 Karma

Tom_Lundie
Contributor

A)Why  we have taken "-30min" 
This was just an example, ideally this value would match your CS scheduling window (factoring in event lag and search lag).

B) do we need to add the previous founddate values in the lookup table.
No, just the _id (as id in my example).

C) why the throttle duration is 5 years ?
This was an example that should be sufficiently long enough.

All just example ideas for you to experiment with to see which one works.

Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...