Detection Engineering

Detection engineering treats detection logic as a product you build, test, and maintain rather than a set of rules you write once and forget. An engineer takes a threat, such as a specific MITRE ATT&CK technique, and works out what evidence it leaves in logs, then writes an analytic that fires on that evidence. The output is a tested detection with a known true-positive rate, documented data requirements, and a clear response action.

The discipline matters because noisy or brittle detections are worse than none. A rule that floods analysts with false positives trains them to ignore it, and a rule tied to a log source nobody collects never fires at all. Detection engineering applies version control, peer review, and automated testing to detection content, the same rigor software teams use, so the rules a security operations center depends on stay accurate as environments change.

Detections run in a SIEM or similar analytics platform, and findings from threat hunting feed new rules: a hunt that uncovers a novel pattern becomes a permanent detection.

In an automated workflow, you store detection rules as code, run them against recorded attack data on every change, and track coverage against the ATT&CK matrix so gaps surface before an attacker finds them.