Detection engineering (the pipeline)

When it applies

You have alerts but no system: rules nobody trusts, unknown coverage, and detections that die on the next log-schema change. This is the lifecycle that turns "we should alert on X" into a tested, versioned, measured detection.

Why it works

Detections are software. Treating them as code — with a source of truth, tests, and a coverage metric — is what separates a SOC that improves from one that just accrues noise. ATT&CK gives a shared map so coverage and gaps are countable, not vibes.

Method

1. Start from a threat, not a log: pick an ATT&CK technique relevant to your org (threat model or a red-team finding), and write the hypothesis of what it leaves behind.
2. Find the telemetry: which data source actually records it (Sysmon 1/EDR process create, 4688, cloud audit log, Zeek). No telemetry → fix logging first; a rule on absent data is theatre.
3. Author as code: write the logic in Sigma (see defense-detection-sigma), store in git, one rule per behaviour, tagged with the ATT&CK ID.
4. Test both ways: fire the real behaviour (Atomic Red Team / a controlled repro) → it must alert; replay a benign baseline → it must stay quiet. Record both as the rule's test.
5. Tune the funnel: measure alert volume; add filter: for known-good; promote only high-signal rules to paging. Track FP rate per rule.
6. Measure coverage: map live rules to the ATT&CK matrix (DeTT&CT / a coverage sheet); the gaps are your backlog.

Gotchas

• Coverage counted by rule count lies — count techniques with a tested detection.
• Atomic tests that need cleanup can leave artifacts; run them in a lab, not production.
• A rule with no owner and no test is a future muted alert. Every rule needs both.

Verify success

Each detection has a passing "fires on attack / quiet on baseline" test, an ATT&CK tag, and an owner; the coverage map shows what's detected and what's a known gap.

References

MITRE ATT&CK & DeTT&CT; SigmaHQ; Atomic Red Team; Palantir "Alerting and Detection Strategy" framework.