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

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

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

1. Pick the right engine (rules/03): 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.

1. Engineer for low FP from the start (rules/04): 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 alerting plumbing) and an owner.

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

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

1. 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; for IR, see rules/06.

AUDIT mode

Assess an existing detection/SOC/IR posture adversarially. Read rules/06 (IR & validation) and rules/04 (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:

Finding format (one per finding):

file:line | rule | severity | effort (trivial/small/medium/large) | fix

Example:

detections/aws/iam.yml:14 | ioc-only-detection-of-ttp-behavior | High | medium |
  GuardDuty-finding-name match is brittle; rewrite as CloudTrail behavioral
  Sigma rule on CreateAccessKey+AttachUserPolicy by non-admin principal,
  test with Stratus Red Team aws.persistence.iam-create-admin-access-key.

Conclude with the verdict: for the top 3 techniques in scope, is detection PRESENT / PARTIAL / ABSENT end-to-end (signal → alert → human → response), and the shortest path to closing the worst gap.

Rules index

Top 10 non-negotiables

1. You can't detect what you don't collect. The #1 gap is telemetry, not

rules. Audit log-source coverage against your attack paths before writing a single detection.

1. Detections are code. Version-controlled, peer-reviewed, CI-tested,

ATT&CK-mapped, with an owner and an ADS doc. A detection that isn't tested isn't a detection — it's a hope.

1. Every detection is validated against the real technique. Atomic Red Team

/ Stratus / Caldera proves it fires; a benign baseline proves it stays quiet. No merge without both.

1. Climb the Pyramid of Pain. Prefer TTP/behavioral logic over hashes/IPs/

domains. IOCs are a supplement and an enrichment, never the strategy.

1. Signal-to-noise is the product. Alert fatigue is the dominant SOC

failure. Tune aggressively, suppress with expiry, and treat a chronically ignored alert as a Critical defect.

1. Every alert has a runbook and an owner. No actionable signal reaches a

human without next steps. Wire alerting plumbing via sota-observability rules/04; you own the security content.

1. Map coverage to ATT&CK and stare at the gaps. A Navigator heatmap that

nobody updates is theater. Coverage drives the next hypothesis.

1. Behavior-detect, then enrich. Correlate, deduplicate, and decorate alerts

with asset/identity/TI context so triage is seconds, not minutes.

1. An IR plan that's never exercised is fiction. Tabletop it, keep contacts

and authority-to-contain current, and run blameless post-incident reviews that feed new detections.

1. Deception is the highest-fidelity signal you own. A touched honeytoken

or honeypot has ~zero false positives. Deploy canaries in the paths attackers must traverse (see sota-secrets-management rules/04 honeytokens).