/sota-detection-engineering

name: sota-detection-engineering
description: >-
  State-of-the-art detection engineering, SOC, threat hunting, and incident
  response (2026). Use when BUILDING detective controls or SOC capability —
  Sigma/YARA/Falco/Tetragon/Suricata rules, detection-as-code, MITRE ATT&CK
  coverage, SIEM detections, alert triage and SOAR, threat hunts,
  threat-intel, deception, IR playbooks, or adversary emulation — AND when
  AUDITING detection & IR posture (can we detect this? does this alert fire?).
  Owns DETECTIVE controls, SOC workflow, hunting, and IR (sota-observability
  owns the telemetry pipeline). Trigger keywords: detection engineering,
  detection-as-code, Sigma, YARA, YARA-X, Falco, Tetragon, Suricata, SIEM,
  KQL, SPL, EQL, ATT&CK, Pyramid of Pain, threat hunting, threat intel, TIP,
  STIX, TAXII, IOC, IOA, TTP, SOC, alert fatigue, tuning, SOAR, runbook,
  incident response, IR playbook, NIST 800-61, PICERL, forensics, chain of
  custody, purple team, honeypot, honeytoken, canary, OCSF, MTTD, false
  positive, Active Directory, Kerberoasting, DCSync, golden ticket, ADCS,
  RBCD.

SOTA Detection Engineering, SOC & Incident Response

Purpose

Assume prevention fails. This skill builds and audits the layer that *notices*: detective controls, the SOC that triages them, the hunts that find what alerts miss, and the IR process that contains what hunts surface. One question defines success:

> **When a real adversary acts inside your environment, does a high-fidelity > signal fire, reach a human (or automation) with the context to act, and drive > a bounded response — fast enough to matter?**

Detection is engineering, not art. Detections are **code**: version-controlled, peer-reviewed, CI-tested, ATT&CK-mapped, FP-budgeted, and retired when stale. The dominant failure mode is not missing rules — it is **alert fatigue**: noise that buries the one true positive. Optimize signal-to-noise relentlessly.

**Ownership boundary.** [`sota-observability`](../sota-observability/SKILL.md) owns the telemetry pipeline (logs, metrics, traces, SLOs, log shipping, retention plumbing). This skill owns turning that telemetry into *security* detections, the SOC workflow, hunting, and IR. [`sota-threat-modeling`](../sota-threat-modeling/SKILL.md) owns design-time threat enumeration (STRIDE/ ATT&CK/ATLAS catalogs); this skill owns catching those threats at runtime. If you find yourself designing the logging schema, that's observability [rules/01](../sota-observability/rules/01-structured-logging.md); if you find yourself enumerating threats on a DFD, that's threat-modeling.

BUILD mode

Run the detection lifecycle as a loop, not a one-shot. Hypothesis → build → test → deploy → tune → retire. Workflow:

1. **Start from a threat hypothesis, not a tool.** Name the ATT&CK technique or abuse case, the adversary behavior, and the telemetry that would witness it. Use the **ADS framework** (Palantir): goal, categorization (ATT&CK), strategy abstract, technical context, blind spots/assumptions, false positives, validation, priority. Write this *before* the rule. 2. **Confirm the log source exists first.** You cannot detect what you do not collect. Map the hypothesis to a concrete data source (EDR, cloud audit, K8s audit, network/flow, identity, app). If it's missing, the deliverable is a *logging gap*, not a rule. See [rules/02](rules/02-telemetry-siem-data-layer.md). 3. **Detect behavior over artifacts.** Climb the **Pyramid of Pain**: prefer TTP/behavioral logic over brittle hashes/IPs/domains. IOC matches are cheap and disposable; TTP detections cost the adversary real money to evade. 4. **Pick the right engine** ([rules/03](rules/03-rule-languages-engines.md)): Sigma for log detections (vendor- agnostic, compiled to your SIEM), YARA-X for file/memory/malware, Suricata for network, Falco/Tetragon for eBPF runtime/container/K8s, SIEM-native (KQL/SPL/EQL) for correlation the portable formats can't express. 5. **Engineer for low FP from the start** ([rules/04](rules/04-alerting-triage-soc-soar.md)): scope tightly, add allowlist context, require corroboration for noisy signals, set a severity honestly. Every detection ships with a runbook (link to observability [rules/04](../sota-observability/rules/04-slos-alerting.md) alerting plumbing) and an owner. 6. **Test before deploy.** Validate with adversary emulation — Atomic Red Team (endpoint), Stratus Red Team (cloud), Caldera (campaigns). Confirm the detection fires on the real technique and stays quiet on benign baselines. No detection merges without a passing test. See [rules/06](rules/06-incident-response-validation.md). 7. **Map coverage and find gaps.** Track every detection against ATT&CK with the Navigator. Coverage heatmaps reveal blind spots — feed them back to step 1. 8. **Tune and retire.** Review FP rates, suppress with *expiry* (never forever), delete detections nobody trusts. A muted alert is worse than none.

For hunting and deception, see [rules/05](rules/05-hunting-intel-deception.md); for IR, see [rules/06](rules/06-incident-response-validation.md).

AUDIT mode

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

Assess an existing detection/SOC/IR posture adversarially. Read [rules/06](rules/06-incident-response-validation.md) (IR & validation) and [rules/04](rules/04-alerting-triage-soc-soar.md) (SOC/triage) first. Sample real detections, real alerts, and real incidents — do not trust a coverage dashboard or a wiki runbook that has never fired. The cardinal test: pick three ATT&CK techniques relevant to the environment and prove, end to end, that each would be caught.

**Severity:**

| Severity | Meaning | Examples | |----------|---------|----------| | Critical | Blind to a primary attack p