Splunk Enterprise Security

Time Range issue: triggered condition is "split" into two cron executions

woodentree
Communicator

Hello,

Our Horizontal Port Scan correlation search is triggered when a number of request destinations is superior of 10 in 15 minutes at the same port.

| tstats `security_content_summariesonly` count dc(All_Traffic.dest) as unique_dest from datamodel=Network_Traffic by All_Traffic.src, All_Traffic.dest_port
| `drop_dm_object_name("All_Traffic")`
| where unique_dest>10

The Time Range of the correlation search looks like below:

Earliset Time | 15m
Latest Time   | now
Cron Schedule | */15 * * * *

However, it looks like we have an issue:

alt text

With the current configuration, the correlation search will not detect the port scan as in the image above. In this condition 18 destination will be "split" into two cron execution.

Do you know how the correlation search can be modified in order to detect this type of condition?
Thanks.

1 Solution

woodcock
Esteemed Legend

We typically handle this by making the cron period set to 1/2 of the Timepicker span. So if your Timepicker is set for The last hour then you set your cron to run */30 * * * * * (i.e. Every half hour). Also be sure that you set your Timepicker a bit back to catch late-arriving events, so something like earliest=-65m@m latest=-5m@m. You may get an occasional double-positive but you should not miss the false-negative.

View solution in original post

woodcock
Esteemed Legend

We typically handle this by making the cron period set to 1/2 of the Timepicker span. So if your Timepicker is set for The last hour then you set your cron to run */30 * * * * * (i.e. Every half hour). Also be sure that you set your Timepicker a bit back to catch late-arriving events, so something like earliest=-65m@m latest=-5m@m. You may get an occasional double-positive but you should not miss the false-negative.

woodentree
Communicator

Got it.
Thank for the explanation!

0 Karma

wmyersas
Builder

Extend your earliest time by a bit of a "grace period"

We do this with Alerts that run every 30 minutes, but our search includes earliest=-35m, because we know that searches can end up running as much as 250 seconds late vs its scheduled time

woodentree
Communicator

Hi @wmersas,

It is a good point. Actually, for this search, we use -17m as an earliest time, but I didn’t want to mention it in order not to add an additional “complexity layer” to the question.

Unfortunately, I’m afraid it will not save as if we detect nearly critical amount of events 10 minutes before our search starts and one more nearly critical amount of events at its first minute of execution. Even if technically those two amounts happens in the period inferior to 15 minutes and together should trigger the correlation search.

*NEW* Splunk Love Promo!
Snag a $25 Visa Gift Card for Giving Your Review!

It's another Splunk Love Special! For a limited time, you can review one of our select Splunk products through Gartner Peer Insights and receive a $25 Visa gift card!

Review:





Or Learn More in Our Blog >>