Actionable Alerting
What Makes a Good Alert?
There are a few qualities that make an alert good besides the query/rule itself:
- Immediately Human Actionable
- Automatically Enriched
- Well Prioritized
- Grouped and Correlated
Remember that if alerts are not properly triaged, then the detections are not effective. And you, as a detection engineer, have many tools to empower analysts to make the timely and correct decisions.
The following qualities represent the ideal, what we as detection engineers should strive towards. Please use your own judgment to know what of it is feasible for your detection, organization etc. and to what extent.
Human Actionable
If you as a detection engineer are going to present an alert, the analyst who’s responding to it should have the tools and information they need to immediately make a decision and take an action.
This requires the SOC Analyst / Incident Responder to:
- Review the content of the alert
- Know what their next steps should be
- And have the tools necessary to take those next steps!
Only steps which require the intelligence and ingenuity of our human analysts should be done by them, the rest should be automated.
Automatically Enriched
If the first step an analyst needs to take when triaging an alert is to collect additional data or information, I consider this failure.
It’s your job as a detection engineer to understand what questions the SOC/IR will have and work to answer as many of those in the alert as you can. The best way to know what questions they’ll ask is to go talk to them.
Well Prioritized
When presented with a slew of alerts to work, the analyst should be able to clearly identify which is the most important to work first and why.
Decide on a framework on how it’s set. The goal is that if two different engineers write the same rule, they would end up with the same severity. Ideally, you want to keep your framework to a limited number of questions. You don’t want your detection engineers to feel like they’re going through an audit every time severity is being set.
For an example framework, have a look at: Alert Prioritization Framework
Grouped and Correlated
If multiple different alerts trigger for a system or user, they should be grouped and correlated so the analyst(s) working the case doesn’t miss that multiple related alerts exist.
If you structure your alerts as "Actor
did Action
to/on Object
", then you can group them if:
Actor
andAction
are the sameActor
andObject
are the same
But feel free to be flexible with grouping and choose the properties that work best for your detection.
For Correlation, you can search for matches of any one of the three alert properties and even order their linkage based on the count/weight of matching properties and possibly time as well, this depends on the detection.
As an example, let's say you are investigating alert A and have the following alerts:
- B, which shares the same
Object
- C, which shares the same
Object
andActor
- D, which shares the same
Object
andAction
- E, which shares nothing
And the properties are weighed like this:
Actor
carries the weighting 0.7Action
carries the weighting 0.4Object
carries the weighting 1.0
Then the order of the strongest linkage will be: C, D, B E
Relevant Note(s):