Detection Engineering: Writing Detections That Fire on Real Attacks
Buying detection content is easy; owning detections is hard. A detection is a claim — "when an attacker does X, this is the trace it leaves" — turned into a query that fires when the trace appears. The discipline of detection engineering treats that claim like software: written against a threat model, tested against real and simulated activity, versioned, measured, and retired when it stops earning its place. Most organisations have hundreds of detections and have validated almost none of them.
The unit of the craft is a detection tied to a specific attacker behaviour, ideally mapped to a technique in a framework like MITRE ATT&CK. That mapping is not bureaucracy — it is how you reason about coverage. "We have 400 rules" tells you nothing; "we can detect credential dumping three ways and lateral movement via SMB but have nothing for WMI" tells you where you are blind.
The false-positive death spiral
Every detection lives on a spectrum between missing real attacks (false negatives) and crying wolf (false positives), and the second kills programs faster than the first. A rule that fires fifty times a day on benign activity trains analysts to close it without looking — and the one day it fires on a real intrusion, it gets closed too. Good detection engineering spends most of its effort here: adding context, thresholds, and allow-lists until a fire means something. A precise detection that fires rarely and correctly is worth more than ten noisy ones.
Test the detection, not just the rule syntax
There is a world of difference between "the query is valid" and "the query fires when the attack happens." The only way to know the latter is to safely reproduce the behaviour — controlled adversary emulation — and confirm the detection lights up. This closes the loop: emulation reveals the detections that never fire, the log sources that were missing all along, and the rules that fire but are drowned in noise. Teams that emulate regularly know their coverage; teams that don't are guessing.
- Start from behaviour, not from the tool. Detect the technique — credential access, persistence, exfiltration — so the rule survives the attacker swapping their specific malware.
- Write for maintainability. A detection nobody understands in six months is a detection that breaks silently. Comment the intent, the expected false positives, and the response.
- Instrument every detection with a response. A fire with no defined next step is an alert that ages into the backlog. Say what the analyst does when it triggers.
- Retire dead weight. Detections that never fire usefully, or fire only noise, cost attention. Prune them the way you’d prune dead code.
- Pick one detection you rely on and ask: when was it last confirmed to fire on the behaviour it targets? If the answer is ‘at import’ or ‘never,’ you have coverage on paper only.
- Map your ten most important detections to attacker techniques and look for the columns with nothing in them. Those gaps are the attacks that will reach you unannounced.
Emulating real technique across your environment, finding the detections that silently don’t fire, and closing the coverage gaps is exactly the adversarial validation our assessment and SecStudio agents run — so your detections are tested before the attacker tests them.
Detection engineering is the difference between owning a pile of rules and owning the ability to see attacks. It is unglamorous, iterative, and never finished — the threat landscape moves, your environment changes, and yesterday's detection quietly stops matching. Treat detections as living software and they defend you; treat them as a one-time purchase and they decay into expensive noise. And you can only detect the behaviours you have thought to look for.