Detection engineering
In defensive operations, detection engineering is the discipline of building, testing and maintaining the logic that turns telemetry into alerts, treated as software rather than as configuration. Rules have requirements, versions, tests and owners, and a rule nobody has tested against real activity is an untested assumption.
How it works
The cycle starts from a technique rather than from a product. Pick something an adversary does, usually referenced through MITRE ATT&CK, and answer four questions in order. Is the telemetry that would reveal it being collected at all. What behaviour distinguishes it from the same action performed legitimately. Can that be expressed as logic with an acceptable false positive rate in this estate. And does it fire when the technique is actually executed here.
The last question is the one that makes it engineering. The rule is validated by running the technique in a controlled way and watching the alert appear, then kept in version control with the telemetry it depends on, the technique it covers and the response expected. Portable rule formats let logic be shared and translated between platforms rather than rewritten for each SIEM.
What goes wrong
Coverage is claimed from a matrix rather than measured. A team maps its rules onto a technique grid, colours in the squares and reports coverage, without anyone ever executing the technique to see whether the rule fires in this environment. The rule frequently does not, because the estate’s own software generates the same pattern and the rule was tuned until it stopped alerting.
Two related problems follow. Rules written against a specific tool break the moment the operator changes tool, whereas rules written against the behaviour survive; matching a well-known credential dumping utility by name is defeated by renaming it, matching the way it accesses the credential store is not. And rules decay silently as the estate changes, so a rule that worked when it was written stops working when an agent is upgraded and nobody notices, because the absence of an alert looks exactly like the absence of an attack.
Where this shows up in an audit
This is precisely what a purple team exercise buys. We execute a defined set of techniques with the defenders watching and record, per technique, whether telemetry existed, whether a rule fired, how long triage took and what the analyst did. The deliverable is a coverage table backed by executed activity, plus the specific rules that need writing, which is a very different artefact from a coloured matrix. This is part of how a purple team exercise validates detection coverage.