Security incident detection

Security incident detection is the capability of identifying, and reacting quickly to, events or activity that suggest a threat or a breach of security.

It means monitoring networks, systems and applications continuously, looking for anomalous behaviour or indicators of compromise that point to an incident in progress.

Speed and accuracy are what make it worth anything. The difference between an incident found in an hour and the same incident found in three months is usually the difference between a contained event and a serious one.

What it involves

Continuous monitoring. Watching activity as it happens: network events, system logs, authentication records and anything else that carries signal, in order to pick out patterns that do not belong.

Indicators of compromise. Known malicious addresses, unusual traffic patterns, known malware signatures. Correlating several indicators is what raises confidence, because any one of them on its own generates more noise than it is worth.

A path to a response. Detection that ends at an alert is not detection. Somebody has to be able to act on it: contain, investigate the cause and apply a fix.

What makes it hard

Volume. Too much data is its own problem. Without a way of filtering, genuine signal is buried under everything else that is technically true and completely irrelevant.

False positives. Every alert nobody should have had to look at costs analyst time and, worse, trains people to ignore the console. Precision is not a nicety here, it is what keeps the capability alive.

New techniques. Detection describes what is already known. Attacker tradecraft moves, so rules and intelligence have to move with it or the coverage quietly decays.

A worked example

A company runs monitoring across its estate.

During normal operation, the system spots an unusual traffic pattern from an internal server towards an external address associated with malware, and raises an alert.

The response team picks it up and investigates immediately. They find that an internal device has been compromised and is being used to move sensitive data off the network.

Because the activity was detected rather than discovered months later, the team can contain the host, remove the malware and close the route that was used.

Who does what in detection

This entry describes the capability. The glossary also has an entry for each of the pieces that make it up, and confusing them is how organisations buy one thing believing it is another.

The SIEM is the platform: it collects logs from everything, normalises them, correlates them and stores them. It detects whatever somebody has written as a rule, and nothing else. Buying it is not the same as having detection.

Detection engineering is the discipline that writes and maintains those rules, treating them as software: with requirements, versions, tests and an owner. A rule nobody has tested by executing the technique in this environment is not a detection, it is an assumption. And rules break silently, because the absence of an alert looks exactly like the absence of an attack.

Threat hunting is the deliberate search for what the rules did not raise, starting from a hypothesis instead of an alert.

Anomaly detection is a different approach from the written rule: instead of describing what is bad, it describes what is normal and flags what departs from it.

And detecting is not responding. Identifying the incident is what this entry covers; carrying it through to closure is incident response. The separation matters because the most repeated failure is not that nothing was detected. It is that it was detected correctly, logged with the right severity, and nobody opened the console.

Where to read more

SANS Institute, Incident Handler’s Handbook: a practical guide to detection and response, covering the phases and what each one has to produce.

MITRE ATT&CK as an incident response framework: how to use the matrix to decide what you should be able to detect, rather than cataloguing what you already detect.