# Defense Detection Engineering

> Build detections as a repeatable pipeline, not one-off alerts. Load for "improve our detections", "detection as code", "reduce false positives", "measure ATT&CK coverage", or turning a red-team finding into durable blue-team coverage. Complements defense-detection-sigma (the rule format).

- Skill: `noorqureshi/defense-detection-engineering` (Agent Skill)
- Install (CLI): `npx skillmds@latest add noorqureshi/defense-detection-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/noorqureshi/defense-detection-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: NoorQureshi (https://skillmd.com/u/noorqureshi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/noorqureshi/defense-detection-engineering

---


# 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.