Absolutely David. Because risk scores and notable events are just data, we can easily do this. Here's a sample search that will escalate to critical any open events that have an aggregate risk (between user, src, and dest) in excess of 1000. You may want to play with the "where" statement to apply your own business logic for when you want this to trigger (for example, maybe you only want it to run against new events, or not on "Pending" events).
`notable`
| fields _time dest src user status_label owner rule_id rule_name urgency
| fields - _raw _time
| eval risk_objects=mvdedup(mvappend(dest, src, user))
| mvexpand risk_objects
| lookup risk_correlation_by_system_lookup risk_object as risk_objects output risk_score as system_risk
| lookup risk_correlation_by_user_lookup risk_object as risk_objects output risk_score as user_risk
| eval risk_score=coalesce(user_risk,0) + coalesce(system_risk, 0)
| stats sum(risk_score) as aggregate_risk_score dc(risk_objects) as number_of_risk_objects by status_label owner rule_id rule_name urgency
| where (aggregate_risk_score > 1000 AND urgency!="critical" AND status_label!="Closed" OR status_label="whatever logic you want here..." )
| table rule_id status owner rule_name
| eval comment="Auto-setting Urgency to 'Critical' due to high level of aggregate risk.", urgency="critical", time=now(), user="admin"
| outputlookup append=t incident_review_lookup
Walking through what this search does:
- First we use the
notablemacro that will enrich the event with all the correct statuses, give us multi-value fields, etc. - Then we create risk_objects as the amalgamation of dest, src, and user. We dedup that (don't need to double-count if the src and dest are the same object), and expand each into its own event so that we can safely do a lookup.
- Then we use the risk_correlation_by_system_lookup and risk_correlation_by_user_lookup to pull the current risk score for the systems/users (this was added in ES 4.5 ish).
- Next we sum back up the aggregate risk (and number of unique entities) per correlation rule
- Here's the critical step: Now we include / exclude what we do or don't want to auto-update. This is your business logic.
- Finally we output this into the incident_review_lookup which stores all of our statuses / updates.
Schedule that search to run every so often and you'll be set. Notably, you probably want this search to run over a day or week each time it runs -- if a notable was created a week ago, but now you have new data in the risk framework that should prioritize that notable, you'll want that surfaced!
Here's what it looks like from some ES Demo data:
Absolutely David. Because risk scores and notable events are just data, we can easily do this. Here's a sample search that will escalate to critical any open events that have an aggregate risk (between user, src, and dest) in excess of 1000. You may want to play with the "where" statement to apply your own business logic for when you want this to trigger (for example, maybe you only want it to run against new events, or not on "Pending" events).
`notable`
| fields _time dest src user status_label owner rule_id rule_name urgency
| fields - _raw _time
| eval risk_objects=mvdedup(mvappend(dest, src, user))
| mvexpand risk_objects
| lookup risk_correlation_by_system_lookup risk_object as risk_objects output risk_score as system_risk
| lookup risk_correlation_by_user_lookup risk_object as risk_objects output risk_score as user_risk
| eval risk_score=coalesce(user_risk,0) + coalesce(system_risk, 0)
| stats sum(risk_score) as aggregate_risk_score dc(risk_objects) as number_of_risk_objects by status_label owner rule_id rule_name urgency
| where (aggregate_risk_score > 1000 AND urgency!="critical" AND status_label!="Closed" OR status_label="whatever logic you want here..." )
| table rule_id status owner rule_name
| eval comment="Auto-setting Urgency to 'Critical' due to high level of aggregate risk.", urgency="critical", time=now(), user="admin"
| outputlookup append=t incident_review_lookup
Walking through what this search does:
- First we use the
notablemacro that will enrich the event with all the correct statuses, give us multi-value fields, etc. - Then we create risk_objects as the amalgamation of dest, src, and user. We dedup that (don't need to double-count if the src and dest are the same object), and expand each into its own event so that we can safely do a lookup.
- Then we use the risk_correlation_by_system_lookup and risk_correlation_by_user_lookup to pull the current risk score for the systems/users (this was added in ES 4.5 ish).
- Next we sum back up the aggregate risk (and number of unique entities) per correlation rule
- Here's the critical step: Now we include / exclude what we do or don't want to auto-update. This is your business logic.
- Finally we output this into the incident_review_lookup which stores all of our statuses / updates.
Schedule that search to run every so often and you'll be set. Notably, you probably want this search to run over a day or week each time it runs -- if a notable was created a week ago, but now you have new data in the risk framework that should prioritize that notable, you'll want that surfaced!
Here's what it looks like from some ES Demo data:
