Splunk Enterprise Security: Is there a way to force a notable event to be critical?

[chiltonb]

Is there a way to force a notable event in Splunk Enterprise Security to be critical? We have certain notables that are created that are only registered as a high and we want to force them to be critical. Is there a way to accomplish this?

Thanks,

[jonasmeier]

Followup question:
We are only talking about the asset or identity priority. Same with the documentation. http://docs.splunk.com/Documentation/ES/5.1.0/User/Howurgencyisassigned
But we quite often have two identities (user and src_user) and two assets (dest and src) in a notable.
So which one counts?

The documentation says: "If both the asset and identity in the notable event have an assigned priority, the higher priority is used to calculate the urgency. ". So still the question remains: Which asset and which identity?
My guess is that it is always user and dest, but found no information on this till now.

Quite often you would want to use src instead of dest for the calculation, i.e. if your notable uses web proxy logs and the dest is always an external url, which of course has an unknown priority. In this case it is clearly the src that you want to use for urgency calculation. But if it is always dest, the only option you have is to calculate urgency yourself either with an eval or using the urgency lookup in your search to lookup the src.

Any comments on my thoughts? (also submitted this as a question at the above doc page)

[jstoner_splunk · Accepted solution]

Do you want it to be critical every time it fires or just when other conditions are met?

By default, correlation searches that have notable events associated with them have a severity associated with them. This severity combined with the asset priority will drive the notable event urgency. By default medium, high and critical priority, combined with critical severity will generate a critical urgency ranking. Unknown and low priority will default to high urgency. This lookup can be edited in the Config-List and Lookups - Urgency Levels if you want to make a global change.

Alternatively, if you want the notable to override all of what I talked about above, you could put the following at the end of your correlation search: |eval urgency="critical"

[chiltonb]

All I had to do was add the |eval urgency="critical" that did the job. Thanks!

[starcher]

One other note. I've turned in an ER for method to allow a bump in urgency. The static override works. But I can see cases where I want the auto urgency to work but I want to ++/-- the result. If that interests you go log a support ticket ER against ES and ask for it too. That will help ++ the request on the priority list. An example would be use machine learning toolkit to predict the notable closed state based on all the previous notables closed by the analysts. and ++/-- urgency based on the predicted closed value. This could help focus analyst attention without actually dropping notables that don't match the prediction.

[David]

I know that you know this, Starcher, but for posterity: In that case, we would normally recommend adjusting the severity for the notable event. Since severity + priority = urgency, you can always define severity = "critical" or | eval severity=case(severity="medium", "high", severity="high", "critical", 1=1, "medium") or something like to bump the urgency. http://docs.splunk.com/Documentation/ES/4.5.1/User/NotableEvents#How_urgency_is_assigned_to_notable_...

[kchamplin_splun]

You can always manually edit the notables' "urgency" after it has been created.
To affect the urgency at creation time please see here: http://docs.splunk.com/Documentation/ES/4.6.0/User/NotableEvents#How_urgency_is_assigned_to_notable_...

That explains how that urgency is determined, which is a combination of the notable severity as well as the priority of the asset or identity.

[David]

You can also override severity in your correlation search itself, as necessary, which would bump the urgency while still staying within the matrix that kchamplin linked to.