NoorQureshi 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
- 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.
- 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.
- 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. - 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.
- Tune the funnel: measure alert volume; add
filter:for known-good; promote only high-signal rules to paging. Track FP rate per rule. - 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.