Why single alerts mislead
Detection rules are written to catch one behaviour each: a burst of discovery commands, a new scheduled task, an unusual archive being created, a connection to a rare address. Each rule sees a slice. An attack is a sequence of slices, spread over minutes, days or weeks, and often across several machines and accounts.
When each alert is handled as its own ticket, three things go wrong. Analysts judge each slice without the others, so each one looks weaker than it is. The same attack is investigated several times by different people. And nobody sees how far the attacker has got, because no single ticket shows the whole path.
A low-severity alert for a directory listing is easy to close as harmless. Read next to a new persistence mechanism on the same machine an hour earlier, and an archive of documents created an hour later, it looks very different.
Correlation is how you read alerts that way on purpose, rather than by luck.
What correlation means
Correlation is the work of deciding which alerts belong together. The simplest joins are on shared entities: the same machine, the same account, the same process tree, the same outside address. Time matters too. Alerts close together on the same machine are more likely to be related than alerts weeks apart.
Good correlation goes beyond matching fields. Two alerts on different machines can belong to the same attack if the same account moved between them, or if one machine connected to the other just before the second alert fired. Two alerts on the same machine can be unrelated if one is a routine administrator task and the other is not. Each join is a judgement, and it should be explained like any other finding.
Correlation can be done by fixed rules, by a person, or by an AI investigator that reads each alert in light of the others. Whatever does it, the output should be the same: a group of alerts, a reason each one belongs, and a timeline a person can check.
- A shared machine, account or process
- A shared outside address, domain or file
- Movement from one machine to another
- Closeness in time
- A sensible order of attacker steps
Reading an attack in stages
MITRE ATT&CK gives security teams a common language for the stages of an attack. Its tactics describe what an attacker is trying to achieve at each step: discovery to learn the environment, execution to run code, persistence to survive a restart, privilege escalation, credential access, lateral movement, collection of data, and in the end exfiltration or impact.
Mapping each alert to a tactic turns a pile of alerts into a timeline. If the joined alerts run from discovery through execution and persistence to collection, you know the attacker has gathered data and the next step may be getting it out. That changes the urgency, and who needs to be told.
Stages also show gaps. An attack that jumps from discovery straight to collection, with nothing in between, suggests steps your rules did not see. That gap is worth writing down as a detection to build or a hunt to run.
- Reconnaissance
- Resource development
- Initial access
- Execution
- Persistence
- Privilege escalation
- Defence evasion
- Credential access
- Discovery
- Lateral movement
- Collection
- Command and control
- Exfiltration
- Impact
12 alerts from 5 rules → 1 campaign, discovery to collection
What a campaign view should show
Once alerts are joined, the people reviewing them need one view of the whole attack. A useful campaign view answers the questions a manager or incident lead will ask first, without making them open a dozen tickets.
The view should also make it easy to challenge the grouping. A person should be able to see why each alert was joined, open the original alert, and take it out if it does not belong.
Above all, it should be written for the people who decide. An incident lead needs to know which business processes are at risk and who owns the affected machines, not only which techniques were seen. Next steps should be concrete and assigned, and each should wait for the person responsible to agree to it.
- Which alerts belong to it, and which rules raised them
- The stages reached, from first to most recent
- The machines and accounts touched
- How long it has been running
- Which business processes it puts at risk
- A plan of next steps, each with an owner
Common mistakes
Joining too much is as harmful as joining too little. If each alert on a busy file server is pulled into one campaign, the campaign loses its meaning. Joins on very common values, such as a shared proxy address or a domain controller that every machine talks to, need particular care.
Time windows need thought as well. Too short, and slow attacks are split into pieces. Too long, and unrelated activity is merged. A sensible approach uses tight windows for weak links, such as sharing a machine and nothing else, and wider windows for strong links, such as the same unusual process or outside address.
Finally, keep the single alerts. A campaign is a summary built on top of them, and reviewers will want to open each one and check it for themselves.
Watch for groups that never end. A campaign should either close, or say clearly that the activity is still going on and when it was last seen.
An example from our lab
In our lab, a MITRE Caldera agent running on a Linux machine called linux04 set off a series of alerts from different detection rules. Handled one by one, they would have been twelve separate tickets. armor360 joined twelve alerts from five rules into one campaign and laid out its stages in order, from discovery to collection. It joins alerts from your tools that name the same machine, account or address within about two hours of each other.
The campaign page showed the machines and accounts touched, how long the activity had been running and which business processes it put at risk, with one coordinated plan of next steps. Each step in that plan waits for a person to approve it. armor360 recommends; people decide and act.