Security

Help on correlation search scheduling

jip31
Motivator

Hi

I have to create correlation searches in Splunk ES

My cron schedule will be */60****

Is it better to use a real-time schedule or a continuous schedule?

Is it necessary to fill the time range (start time and end time)?

Last question : if an alert event exists, does it means that this event will be created many times in the incident review dashboard?

I need to creat just an incident for the same alert. How to do this?

Thanks in advance

 

Labels (1)
Tags (1)
0 Karma
1 Solution

gcusello
SplunkTrust
SplunkTrust

Hi @jip31,

I try to answer to your questions:

Q: Is it better to use a real-time schedule or a continuous schedule?

A: never use a Real Time search, because in Splunk a searche  takes a CPU (more then one if you also have subsearches) and release it when finishes, but a RT search dosn't finish, so with few RTb searches you could use all your resources, it's always better a scheduled search.

Q: Is it necessary to fill the time range (start time and end time)?

A: yes, always and I usually use the same time of the running frequency: e.g. if I have a search running every hour I use earliest=-60m@m and latest=@m; eventually you can delay your search if you know that you have some logs that are delayed indexed, in this case, you could use earliest=-70m@m and latest=-10m@m.

Q: if an alert event exists, does it means that this event will be created many times in the incident review dashboard?

A: Yes, you could eventually use a grouping command (as stats or tstats) and threshold to group more events.

In ES, you could also use the Risk Analysis Action, instead the Notable Action to reduce the number of the Notables: in this way, every occurrance of the alert doesn't create a Notable, but it increments the Risk Score for that asset or identity, and the Notable will be created when the Risk Score will exceed the Risk Score threshold, in this way you create a Notable later, but you reduce the number of Notables to analyze, this is obviously possible only for alerts frequently triggered.

Ciao.

Giuseppe

View solution in original post

gcusello
SplunkTrust
SplunkTrust

Hi @jip31,

I try to answer to your questions:

Q: Is it better to use a real-time schedule or a continuous schedule?

A: never use a Real Time search, because in Splunk a searche  takes a CPU (more then one if you also have subsearches) and release it when finishes, but a RT search dosn't finish, so with few RTb searches you could use all your resources, it's always better a scheduled search.

Q: Is it necessary to fill the time range (start time and end time)?

A: yes, always and I usually use the same time of the running frequency: e.g. if I have a search running every hour I use earliest=-60m@m and latest=@m; eventually you can delay your search if you know that you have some logs that are delayed indexed, in this case, you could use earliest=-70m@m and latest=-10m@m.

Q: if an alert event exists, does it means that this event will be created many times in the incident review dashboard?

A: Yes, you could eventually use a grouping command (as stats or tstats) and threshold to group more events.

In ES, you could also use the Risk Analysis Action, instead the Notable Action to reduce the number of the Notables: in this way, every occurrance of the alert doesn't create a Notable, but it increments the Risk Score for that asset or identity, and the Notable will be created when the Risk Score will exceed the Risk Score threshold, in this way you create a Notable later, but you reduce the number of Notables to analyze, this is obviously possible only for alerts frequently triggered.

Ciao.

Giuseppe

gcusello
SplunkTrust
SplunkTrust

Hi @jip31 ,

good for you, see next time!

Ciao and happy splunking

Giuseppe

P.S.: Karma Points are appreciated 😉

0 Karma
Get Updates on the Splunk Community!

Earn a $35 Gift Card for Answering our Splunk Admins & App Developer Survey

Survey for Splunk Admins and App Developers is open now! | Earn a $35 gift card!      Hello there,  Splunk ...

Continuing Innovation & New Integrations Unlock Full Stack Observability For Your ...

You’ve probably heard the latest about AppDynamics joining the Splunk Observability portfolio, deepening our ...

Monitoring Amazon Elastic Kubernetes Service (EKS)

As we’ve seen, integrating Kubernetes environments with Splunk Observability Cloud is a quick and easy way to ...