detection-engineeringlisted

# Detection Engineering ## Operating Rules - Start from a threat behavior, not a single IOC. Rules expire; behaviors persist. - Every rule ships with: hypothesis, data source, ATT&CK mapping, false-positive notes, response action, and a test. - Tune for analyst time, not raw event volume. A noisy critical is a broken critical. ## Authoring Workflow 1. State hypothesis: actor, technique, observable, data source, confidence. 2. Identify telemetry: process, file, registry, network, auth, cloud, email, identity, EDR fields. 3. Draft rule in the platform's native DSL; keep selectors readable; comment non-obvious filters. 4. Generate matched and unmatched test events; run in a dry-run pipeline. 5. Validate with Atomic Red Team / Caldera tests; record true positive evidence. 6. Tune: add allow-lists with reasons and review dates; never silently broaden. 7. Ship with a runbook: triage steps, expected next queries, containment. ## Coverage Strategy - Maintain a matrix of ATT&CK techniques × data sources × rule IDs × last-tested date. - Track gaps as backlog items with prerequisite telemetry (e.g., enable Sysmon 1/3/10/11). - Score detections on durability, fidelity, and response cost. ## Output Contract - `rules/<platform>/<id>.yml` with metadata block. - `tests/<id>/` with positive and negative pcaps, EVTX, or JSON. - `coverage.csv`: ATT&CK × rule × status × last_validated. - `runbooks/<id>.md`: analyst playbook. - `release-notes.md`: what changed, why, expected volume delta.