# 01 — Detection Engineering as a Discipline

Detection engineering is the practice of treating security detections as
engineered, maintained software artifacts with a lifecycle, tests, owners, and
metrics — not a pile of rules someone wrote once. Read this when standing up the
discipline, writing detection specs, mapping coverage, or auditing whether a
team *practices* detection engineering or merely accumulates rules.

## 1. The detection lifecycle

Detections are living things. Run them through a loop, not a one-shot:

```
hypothesis → build → test → deploy → tune → retire
     ▲                                          │
     └──────────── coverage gaps ───────────────┘
```

- **Hypothesis.** A falsifiable statement about adversary behavior in *your*
  environment: "An adversary with a stolen OAuth token will register a new MFA
  device (T1556.006) to persist." Name the technique, the actor capability, and
  the telemetry that witnesses it. No hypothesis → no detection.
- **Build.** Express the logic in the right engine (rules/03), scoped tightly,
  with allowlist context for known-benign.
- **Test.** Validate it fires on the real technique (adversary emulation,
  rules/06) and stays quiet on a benign baseline. Capture both as regression
  fixtures.
- **Deploy.** Ship through CI to the SIEM/engine, with a runbook and an owner.
- **Tune.** Watch FP/TP rates for a burn-in window; adjust scope, add
  corroboration, set suppressions with expiry.
- **Retire.** Delete detections that no longer map to a live threat, fire on
  decommissioned systems, or have lost the team's trust. Stale detections are
  liabilities: they generate noise and create false coverage confidence.

Audit smell: a rule repo where the newest commit is a year old and nobody can
say which detections are trusted. That's accumulation, not engineering.

## 2. Detection-as-Code (DaC)

Apply software engineering rigor to detections. Non-negotiable practices:

- **Version control.** Every detection in git. History tells you who changed
  what scope and why. Diffs are reviewable.
- **Peer review.** Detections merge via PR with a second reviewer who checks the
  ADS doc, the FP analysis, and the test. A detection one person understands is
  a bus-factor risk.
- **CI testing.** On every PR: lint/syntax-validate the rule (e.g. `sigma check`
  via sigma-cli, `yr check` for YARA-X, `falco --validate`), run it against a
  known-malicious sample (must alert) and a benign corpus (must not), and gate
  the merge on both.
- **Automated deployment.** A pipeline compiles/converts and pushes detections
  to the engine — no hand-editing rules in the SIEM console. The console is a
  read path; git is the write path.
- **Metadata as schema.** Enforce required fields (id, ATT&CK technique, owner,
  severity, data source, FP notes, test reference) via a CI schema check.

Good detection PR contents:

```
detections/identity/new_mfa_device_after_suspicious_login.yml   # the rule
tests/identity/new_mfa_device_after_suspicious_login_pos.json   # must fire
tests/identity/new_mfa_device_after_suspicious_login_neg.json   # must not
docs/ads/new_mfa_device_after_suspicious_login.md               # ADS spec
```

## 3. The ADS framework (Palantir)

The **Alerting and Detection Strategy** framework is the canonical detection
spec. Write it *before* the rule; it forces the thinking that low-FP detections
require. Sections:

- **Goal** — what malicious/anomalous behavior this detects, in plain language.
- **Categorization** — ATT&CK tactic/technique IDs (and ATLAS for AI systems).
- **Strategy abstract** — how it works at a high level: what data, what logic,
  what triggers.
- **Technical context** — the detail an analyst needs: log fields, data source
  quirks, environment specifics.
- **Blind spots & assumptions** — how an adversary defeats this, what it assumes
  is true. This is the section that separates engineers from rule-copiers.
- **False positives** — known benign triggers and how triage distinguishes them.
- **Validation** — exactly how to prove it works (the emulation test).
- **Priority** — severity and why.

(Source: github.com/palantir/alerting-detection-strategy-framework.) If a
detection has no ADS doc, in AUDIT mode that's a Medium finding: no blind-spot
analysis means no one knows how it fails.

## 4. The Pyramid of Pain

David Bianco's model ranks indicators by how much pain detecting them inflicts
on the adversary. Detect high, supplement low:

```
            ▲ TTPs ................. tough! (rewrite their playbook)
            │ Tools ................ challenging
            │ Network/Host Artifacts annoying
            │ Domain Names ......... simple
            │ IP Addresses ......... easy
            ▼ Hash Values ......... trivial (one rebuild defeats it)
```

- **Hashes/IPs/domains (IOCs):** trivially rotated. Useful for *enrichment* and
  *retro-hunting*, worthless as a primary strategy. A detection portfolio that
  is mostly hash/IP feeds is brittle by design.
- **TTPs:** behaviors the adversary must perform to achieve their goal
  (e.g. dumping LSASS, creating an IAM admin key, `kubectl exec` into a prod
  pod). Detecting these forces the adversary to change *how they operate* —
  expensive. Aim your engineering budget here.

Rule of thumb: for every IOC feed you subscribe to, ask "what TTP detection
would catch the *behavior* this IOC is a symptom of?" Build that instead.

## 5. Coverage mapping: MITRE ATT&CK + Navigator

- **ATT&CK** is the shared taxonomy of adversary tactics and techniques.
  Verify the current version at attack.mitre.org/resources/versions/ — as of
  mid-2026 the current Enterprise release is **v19** (April 2026), which split
  the former Defense Evasion tactic into **Stealth (TA0005)** and **Defense
  Impairment (TA0112)**. Pin to a version in your tooling; ATT&CK changes
  technique IDs and structure between releases, and a coverage map built on an
  old version silently misrepresents gaps.
- **Map every detection to technique IDs** in its metadata. This is what makes
  coverage measurable.
- **Use ATT&CK's structured detection objects.** v18 (Oct 2025) retired the
  free-text Detections/Data Sources in favor of machine-readable **Detection
  Strategies (DETxxxx)** and **Analytics (ANxxxx)** objects, extended to Mobile
  in v19. Map detection metadata to DET/AN IDs where applicable, and mine the
  Analytics as hypothesis fuel and a coverage cross-check.
- **ATT&CK Navigator** renders coverage as a heatmap layer (JSON). Generate it
  from your detection metadata automatically — a hand-maintained layer rots
  instantly. Color by confidence (validated vs. unvalidated vs. none), not mere
  existence; a rule that's never fired is not coverage.
- **Threat-informed prioritization.** Don't chase 100% of the matrix. Prioritize
  techniques used by adversaries who actually target your sector (threat intel,
  rules/05) and the techniques that the *other SOTA skills* tell you matter for
  your stack: cloud/K8s/identity attack paths. MITRE CTID's **INFORM** maturity
  model (updated Jan 2026) and the Center for Threat-Informed Defense's
  resources (ctid.mitre.org) give a structured way to measure and grow.

Coverage anti-pattern: optimizing for matrix cells colored green rather than for
detecting the techniques in your top threat scenarios. A green Navigator with
no validated detections of your crown-jewel attack path is a vanity metric.

## 6. Maturity & metrics

Measure the program, not activity. Useful metrics:

- **Coverage** — % of in-scope ATT&CK techniques with at least one *validated*
  detection. Distinguish "have a rule" from "proved it fires."
- **Precision (1 − FP rate)** — of alerts from a detection, how many were true.
  Low precision = noise = the detection is a defect regardless of recall.
- **MTTD (mean time to detect)** — from adversary action to alert. Measure it
  with emulation, not by waiting for real incidents.
- **MTTR / time-to-triage** — how fast an alert reaches disposition.
- **Detection-as-code health** — % of detections with tests, ADS docs, owners;
  age distribution; retirement rate.

Beware vanity metrics: total rule count, alert volume, "events processed." None
correlate with catching adversaries; high alert volume usually means the
opposite.

Maturity progression (rough): ad-hoc rules → version-controlled detections →
ATT&CK-mapped + tested → CI/CD detection-as-code with regression → continuous
validation (purple teaming, BAS) feeding the hypothesis backlog.

## 7. Concurrent siblings & owned boundaries

- **sota-observability** owns the telemetry pipeline. Detection logic consumes
  its output. Reference rules/01 (structured logging) for the schema you query
  and rules/04 (alerting/SLO) for the *plumbing* that routes your security
  alerts — you own the security *content*, not the pipe.
- **sota-threat-modeling** rules/03 (threat catalogs, STRIDE/ATT&CK/ATLAS)
  enumerates threats at design time; turn each high-priority threat into a
  detection hypothesis here.
- **sota-kubernetes** (K8s audit-log detections, admission events),
  **sota-network-security** (network IDS, DNS-exfil, flow logs), and
  **sota-identity-access** (auth anomaly, impossible-travel, MFA-fatigue) own
  the domain-specific detections; this skill owns the *discipline* that produces
  and validates them.
- **sota-code-security** rules/08 (LLM/AI security) defines the prompt-injection
  / excessive-agency threats; detecting them at runtime (and ATLAS coverage) is
  yours.

## 8. Provenance: where the detection came from, and what in the source was scaffolding

A detection derived from a paper, a vendor write-up, a conference talk or another team's rule
arrives with two things mixed together: the **mechanism** of the attack, and the
**instrumentation** its author used to demonstrate it. Keying on the second is the easy
mistake, and it produces a rule that fires perfectly in the lab and never in production.

Field-reported: a paper said, in its own limitations section, that its `.payload` filename and printed marker were
*demo scaffolding*. A rule keyed on those **detects the demo, not the attack** — and it would
have passed every test, because the test corpus is the demo.

- **Record the source on the rule**, in the rule: citation, version or SHA, and the date you
  read it. A detection whose origin is folk memory cannot be re-checked when the source is
  corrected, retracted, or turns out to describe a different variant.
- **Separate mechanism from instrumentation before writing anything.** Ask of every literal
  you are about to match: *would the attacker need this, or did the author choose it?*
  Filenames, marker strings, ports, user-agents, sleep durations and output banners are
  usually the author's. The syscall sequence, the API misuse, the ordering constraint, the
  privilege transition are usually the mechanism.
- **A rule that cannot fail on the demo corpus has not been tested.** Pair it with a variant
  that keeps the mechanism and changes every one of the author's choices; if the rule stops
  firing, it was keyed on scaffolding (`sota-code-security` rules/15 §2.1 — a probe that
  exercises a neighbouring property).
- **Enforce the citation the way a runbook link is enforced** — a rule with no source field
  does not load. Provenance that is optional is provenance that is absent by the time anyone
  needs it.
- **Record what the detection *cannot* see, beside what it catches.** Sources usually tell
  you: the same paper that supplied the technique described a wrapper variant producing a
  structurally ordinary binary that evades all three of its own signals. Writing that down is
  what stops the rule being credited with coverage it does not have — the counting discipline
  in `sota-code-security` rules/14 §6, applied before anyone asks.
- **Re-read the source when the rule misbehaves.** "It worked in the paper" and "it works
  here" are claims about different corpora; §2's benign baseline is what turns the second
  into a number.

## Audit checklist

- [ ] Are detections in version control, with PR review and CI tests, or edited
      directly in the SIEM console?
- [ ] Does each detection carry required metadata (ATT&CK ID, owner, severity,
      data source, FP notes, test ref)? Enforced in CI?
- [ ] Is there an ADS (or equivalent) doc per detection, including a blind-spots
      / assumptions section?
- [ ] Pick 5 detections: how many are validated against the real technique vs.
      "written and hoped"? (`grep -L "validation" docs/ads/` to find specs with
      no validation section.)
- [ ] Is the portfolio TTP-weighted, or dominated by hash/IP/domain IOC feeds?
      (Count rules whose only condition is an IOC match.)
- [ ] Is ATT&CK pinned to a known version, and is the Navigator coverage layer
      generated from metadata (not hand-maintained)?
- [ ] Does coverage prioritization follow threat intel for the org's sector, or
      chase matrix completeness?
- [ ] Are coverage, precision, and MTTD measured? Or only vanity metrics (rule
      count, alert volume)?
- [ ] Is there a retirement process? When did a detection last get deleted?
- [ ] Hunt query for stale detections: in the rule repo, list detections whose
      last meaningful edit predates the last ATT&CK version bump and that target
      systems still in the asset inventory.
- [ ] **Does every derived detection record its source, and separate the attack's mechanism
      from the author's instrumentation?** (§8) Filenames, markers, ports and banners are
      usually the demonstrator's choices; a rule keyed on them detects the demo. Test with a
      variant that keeps the mechanism and changes all of them. Is the source field
      **enforced** (a rule without one does not load), and is **what the rule cannot see**
      recorded beside what it catches?

# 02 — Telemetry Coverage & the SIEM/Data Layer

**You can't detect what you don't collect.** Log-source coverage is the #1 gap
in every real detection program. A perfect Sigma rule against a log you never
ship detects nothing. Read this when deciding what telemetry to collect,
choosing a SIEM/data lake, normalizing schemas, sizing retention, or auditing
whether the data foundation can even support detection and IR.

Boundary: **sota-observability owns the telemetry *pipeline*** — how logs are
emitted, structured, shipped, and stored, plus retention plumbing and cost. This
rule owns it from the *security* angle: which sources are non-negotiable for
detection, what fidelity detections require, and how to size data for *IR and
hunting* (a different requirement than ops debugging).

## 1. Log-source coverage: the security floor

Before writing detections, inventory sources against your attack paths. The
non-negotiable categories:

| Source | Detects | Without it you are blind to |
|---|---|---|
| **Endpoint / EDR** | process exec, injection, credential dumping, persistence | most host TTPs; the largest single coverage source |
| **Cloud audit** (CloudTrail / GCP Audit / Azure Activity) | IAM abuse, persistence, exfil, resource hijack | cloud control-plane attacks (the modern breach path) |
| **K8s audit log** + admission | `exec`/`attach`, RBAC changes, secret reads, privileged pods | container/orchestrator attacks (see sota-kubernetes) |
| **Network / flow** (NetFlow, VPC flow, Zeek) | C2 beaconing, lateral movement, exfil volume | east-west movement, DNS exfil (see sota-network-security) |
| **Identity / auth** (IdP, MFA, directory) | impossible travel, MFA fatigue, token theft, new-device | account takeover (see sota-identity-access) |
| **Application** | business-logic abuse, app-layer attacks, agent/LLM abuse | abuse only your app can see (auth flows, prompt-injection) |
| **DNS** | DGA, exfil over DNS, C2 resolution | a huge fraction of malware behavior |

Map each to its **enabled** state, not its *available* state. CloudTrail data
events (S3/Lambda object-level) are off by default and are exactly where exfil
shows up. K8s audit logging requires an explicit policy file — many clusters ship
with it effectively disabled. The audit finding is "data event logging not
enabled," not "no S3 detection."

Coverage assessment, concretely: take your top 5 attack scenarios (from threat
modeling), and for each ATT&CK technique in the chain, name the log that would
witness it and confirm it is collected, parsed, and queryable. Gaps are findings
*before* any rule is written.

## 2. Detection data quality

Collection isn't enough; the data must be detection-grade:

- **Completeness** — are all instances of the source shipping? One unmonitored
  subnet, region, or cluster is the one the adversary uses. Track expected vs.
  actual senders and alert on a source going silent (a dead sensor is an
  outage you must page on — adversaries kill logging: T1685 Disable or Modify
  Tools, formerly T1562, under ATT&CK v19's Defense Impairment tactic TA0112).
- **Timeliness** — ingestion lag directly inflates MTTD. A log that lands an hour
  late detects an hour late.
- **Fidelity** — does the event carry the fields the detection needs? Command
  lines truncated, user fields empty, or process ancestry missing make whole
  technique classes undetectable. Verify the *fields*, not just the event count.
- **Integrity** — can the source be tampered with or disabled by the very
  activity you're detecting? Ship logs off-host immediately; an attacker who
  owns the box owns its local logs.

## 3. Normalization: OCSF and ECS

Detections written against raw, per-vendor formats don't port and break on
vendor changes. Normalize:

- **OCSF (Open Cybersecurity Schema Framework)** — vendor-agnostic event schema
  (categories, classes, attribute dictionary), Apache-2.0, backed by a broad
  industry coalition. Verify the current version at schema.ocsf.io /
  github.com/ocsf/ocsf-schema (the schema repo tracks version in `version.json`;
  as of mid-2026 it is on the 1.x line, ~1.8 stable with 1.9 in development).
  AWS Security Lake and a growing set of tools emit/ingest OCSF natively.
- **Elastic ECS (Elastic Common Schema)** — the field-naming standard across the
  Elastic ecosystem; many Sigma backends and detection content assume ECS field
  names. ECS and OCSF are converging/mapping efforts exist; pick the one your
  primary platform speaks and map the rest to it.

Write detections against the normalized schema, not the wire format. This is
what lets one Sigma rule cover sources from three vendors and survive a vendor's
log-format change.

## 4. SIEM / data-lake choice

There is no universal right answer; choose on data volume, query model, cost,
and team. Patterns:

- **Classic SIEM** (Splunk, Microsoft Sentinel, Elastic Security) — strong
  correlation, mature detection content, rich query languages (SPL/KQL/EQL+ES|QL).
  Cost scales with ingest; volume discipline is mandatory.
- **Open-source / self-hosted** (OpenSearch, the Elastic stack, Wazuh) — control
  and cost predictability; you own the operational burden.
- **Security data lake** (e.g. lake + query engine over object storage, often
  OCSF-normalized) — decouples cheap long-term storage from compute, enabling
  long retention for hunting/IR at far lower cost; queries are
  higher-latency/batch. Increasingly the pattern for big environments.
- **Log/observability platforms** (Loki, etc.) — fine for ops, often weak for
  correlation-heavy security detection; know the limits before betting detection
  on them.

A common modern split: hot tier (recent data, real-time detections) in a fast
SIEM; cold tier (long retention) in a cheap data lake for hunting and IR
lookback. Detections run hot; hunts and investigations reach into cold.

## 5. Retention sized for IR and hunting

Ops retention (days–weeks) is far too short for security. Drivers:

- **Dwell time.** Industry median dwell time is *weeks to months*. If you retain
  30 days and the adversary was in for 90, your incident investigation hits a
  wall — you cannot reconstruct initial access or scope. Retain security-relevant
  sources (auth, cloud audit, EDR, DNS, network metadata) long enough to
  out-last realistic dwell — commonly **12 months** for the highest-value
  sources, longer where compliance dictates.
- **Retro-hunting.** When a new IOC/TTP from threat intel lands, you hunt it
  *backwards* across history. No history → no retro-hunt.
- **Forensics & legal.** IR and potential litigation need defensible retention
  with integrity (see rules/06 chain of custody).

Tier to control cost: short hot retention for high-volume/low-value sources,
long cold retention for the security-critical ones. Coordinate the *plumbing*
with sota-observability; you own the *security minimums*.

## 6. Volume & cost discipline

Ingest-priced platforms turn "collect everything" into a budget crisis that ends
with someone disabling sources — re-opening blind spots. Discipline:

- **Filter at the edge,** not by dropping sources. Drop known-noise event types
  (verbose health checks, debug chatter) before ingest; keep the security-
  relevant fields.
- **Tier by value.** Route high-value/low-volume (auth, cloud audit) to the
  expensive hot SIEM; route high-volume/low-value (verbose proxy logs) to the
  cheap lake.
- **Never silently drop a security source to save money.** That's a Critical
  finding waiting to be an incident. If a source must be trimmed, sample
  transparently and document the blind spot in the affected detections' ADS
  blind-spots section.

## Audit checklist

- [ ] Is there a log-source inventory mapped to attack paths, with *enabled*
      (not merely *available*) status per source?
- [ ] For the top 5 attack scenarios, can you name and confirm the collected log
      for every technique in the chain?
- [ ] Are cloud data events (e.g. CloudTrail S3/Lambda object-level) and K8s
      audit logging explicitly *enabled*, not left at insecure defaults?
- [ ] Is there alerting when a log source goes silent (dead sensor / T1685
      logging tamper, formerly T1562)? Hunt: per source, compare current ingest
      rate to a 7-day baseline and flag drops >50%.
- [ ] Do events carry the fields detections need (full command lines, user,
      process ancestry), or are they truncated/empty?
- [ ] Are detections written against a normalized schema (OCSF/ECS), or against
      raw per-vendor formats that won't port?
- [ ] Is security retention sized to out-last realistic dwell time (≥12 months
      for high-value sources), not ops retention (days)?
- [ ] Is there a hot/cold tiering that keeps long-history retro-hunting
      affordable?
- [ ] Has any security source been dropped or sampled purely for cost without
      documenting the resulting blind spot?
- [ ] Are logs shipped off-host promptly so a compromised host can't erase its
      own evidence?

# 03 — Rule Languages & Detection Engines

Pick the engine that matches the telemetry and the behavior, then write rules
that are specific, FP-resistant, and performant. Read this when choosing between
Sigma, YARA/YARA-X, Suricata, Falco, Tetragon, or SIEM-native query languages,
or when reviewing rule quality. Defensive framing throughout: these detect and
hunt; adversary emulation (rules/06) validates them.

## 1. Engine selection

| Engine | Domain | Use when |
|---|---|---|
| **Sigma** | log events (any source) | Portable, vendor-agnostic log detections you compile to your SIEM. The default for log-based detection. |
| **YARA-X** | files, memory, malware | Classifying/matching file or memory content (samples, dropped payloads, in-memory implants). |
| **Suricata** (or Snort/Zeek) | network packets/flows | IDS/IPS, protocol anomalies, C2 signatures, payload inspection on the wire. |
| **Falco** | eBPF/syscall runtime, K8s | Container/host runtime detection with a mature rules ecosystem; CNCF graduated. |
| **Tetragon** | eBPF runtime, K8s, in-kernel enforcement | Low-overhead runtime observability + in-kernel *enforcement* (kill/block); part of Cilium. |
| **SIEM-native** (KQL/SPL/EQL/ES\|QL/Lucene) | correlation in your platform | Multi-event correlation, joins, statistics, and sequence logic that portable formats can't express. |

Rule of thumb: write log detections in **Sigma** for portability; drop to
SIEM-native only when you need correlation/sequence/stats Sigma can't model.
Use runtime engines (Falco/Tetragon) for syscall/container behavior, network
engines for the wire, YARA for content.

## 2. Sigma (+ pySigma / sigma-cli)

Sigma is a YAML format describing log detections independent of any SIEM.
**pySigma** is the current conversion library (it replaced the legacy `sigmac`
toolchain); **sigma-cli** is the CLI front-end. Backends and processing
pipelines for each target query language live as separate plugins (see the
pySigma plugin directory) to keep the core vendor-neutral. Verify current
backend/pipeline support at sigmahq.io and github.com/SigmaHQ.

Workflow: write once in Sigma → `sigma convert` with the backend + a pipeline
that maps fields to your schema (OCSF/ECS, rules/02) → deploy the generated
query. CI-validate with `sigma check`.

**Bad** (brittle, over-broad, no context):

```yaml
title: PowerShell encoded command
detection:
  sel:
    Image|endswith: '\powershell.exe'
  condition: sel
# Fires on every PowerShell launch. Pure noise; no behavior, no ATT&CK mapping.
```

**Good** (behavioral, scoped, mapped, FP-aware):

```yaml
title: Suspicious Encoded PowerShell from Office Parent
id: 9b2e... (stable UUID)
status: stable
description: Office app spawning PowerShell with an encoded command — a common
  macro-to-payload handoff.
references:
  - https://attack.mitre.org/techniques/T1059/001/
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\outlook.exe'
    CommandLine|contains|all:
      - '-enc'
  filter_admin:                       # allowlist known-benign automation
    User|startswith: 'SVC_'
  condition: selection and not filter_admin
falsepositives:
  - Signed admin tooling launched from Office add-ins (rare; allowlisted above)
level: high
```

Quality rules: stable `id`; ATT&CK `tags`; real `logsource`; tight `selection`;
explicit `filter_*` allowlists in the `condition`; honest `falsepositives` and
`level`. Avoid single-field broad matches and regexes that are easy to evade by
trivial casing/spacing — anchor on behavior + parent/child + context.

## 3. YARA / YARA-X

YARA matches patterns in files and memory. **YARA-X** is the Rust rewrite and
the current standard: it reached **1.0 stable (June 2025)** and ships frequent
releases; legacy YARA is in **maintenance mode** (bug fixes
only, no new features). New rules target YARA-X; validate with `yr check` and
scan with `yr scan`. (Source: virustotal.github.io/yara-x, VirusTotal blog.)

**Bad** (one rotated byte defeats it; trivial Pyramid-of-Pain tier):

```
rule Bad_Hash_Only {
  condition: hash.md5(0, filesize) == "44d88612fea8a8f36de82e1278abb02f"
}
```

**Good** (structural — costs the author real rework to evade):

```
rule Suspicious_Packed_PE_With_RWX {
  meta:
    author = "soc"
    attack = "T1027.002"          // software packing
    description = "PE with RWX section and high-entropy body — likely packed"
  strings:
    $mz = { 4D 5A }
  condition:
    $mz at 0 and
    pe.number_of_sections > 0 and
    for any s in pe.sections : (
      s.characteristics & pe.SECTION_MEM_EXECUTE and
      s.characteristics & pe.SECTION_MEM_WRITE and
      math.entropy(s.raw_data_offset, s.raw_data_size) > 7.2
    )
}
```

Prefer structural/behavioral conditions (PE structure, entropy, string
combinations) over single hashes or single fixed strings. Keep conditions
performant — anchor cheap checks (`$mz at 0`) before expensive ones (entropy);
gate module use so the scan short-circuits.

## 4. Suricata / Snort (network)

Signature-based network IDS/IPS. Detail belongs to **sota-network-security**
(IDS tuning, DNS exfil, flow analysis); from a detection-engineering view:

- Prefer protocol/behavioral logic (TLS JA4 fingerprints, HTTP anomalies,
  beaconing intervals, DNS query patterns) over raw payload byte-strings, which
  encryption defeats.
- Treat `rev`/`sid` and rule metadata like code; version-control your ruleset.
- IPS (inline block) needs the same FP discipline as auto-containment (rules/04)
  — a false drop is an outage.

## 5. Falco vs. Tetragon (eBPF runtime / K8s)

Both observe kernel-level behavior via eBPF; choose by need.

- **Falco** — CNCF *graduated*; mature rules language and large community
  ruleset; rich syscall + container + K8s-audit detection; primarily *detect/
  alert*. Current line is v0.x (verify at falco.io); v0.44 removed the legacy
  (non-CO-RE) eBPF probe and gVisor engine support — older kernels need the
  kernel-module driver or an older Falco.
- **Tetragon** — part of **Cilium**; very low-overhead eBPF observability with
  **in-kernel enforcement** (it can *kill* a process or block an action in the
  kernel, not just alert), driven by `TracingPolicy` CRDs. Production-ready on
  the v1.x line (verify the current release at the Cilium/Tetragon repo).

Use Falco when you want a broad detect-only ruleset fast. Use Tetragon when you
want fine-grained process/file/network observability with optional kernel
enforcement and tight Cilium/K8s integration. They coexist.

**Falco** (good — specific behavior + exclusions, not "any exec"):

```yaml
- rule: Shell Spawned in Container by Web Server
  desc: Interactive shell launched by a web-server process inside a container —
    classic RCE-to-shell.
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh) and
    proc.pname in (nginx, httpd, node, python)
  output: "Shell in container (pod=%k8s.pod.name proc=%proc.cmdline parent=%proc.pname)"
  priority: WARNING
  tags: [container, mitre_execution, T1059]
```

**Tetragon** `TracingPolicy` (observe + enforce — kill on sensitive file read):

```yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-serviceaccount-token-read
spec:
  kprobes:
    - call: "security_file_open"
      syscall: false
      args:
        - index: 0
          type: "file"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/var/run/secrets/kubernetes.io/serviceaccount/token"
          matchActions:
            - action: Sigkill      # in-kernel enforcement; omit for detect-only
```

Enforcement actions (`Sigkill`/`Override`) are powerful and dangerous — pilot in
detect-only, scope by pod/namespace selectors, and treat enabling kill like
enabling IPS block (rules/04 auto-containment guardrails). K8s-specific runtime
detection content is shared with **sota-kubernetes**.

## 6. SIEM-native query languages

Use when correlation, sequencing, joins, or statistics exceed Sigma's model:

- **EQL** (Event Query Language) — sequence/ordered-event logic
  (`sequence by host.id [process where ...] [network where ...]`): ideal for
  multi-step behaviors.
- **KQL** (Sentinel/Defender), **SPL** (Splunk), **ES|QL/Lucene** (Elastic) —
  stats, joins, lookups, baselining (`| stats count by user | where count > N`).
- Keep these in version control with the same review/test rigor as Sigma. Their
  power is also their FP risk: a sloppy `join` or unbounded time window produces
  noise and crushes the cluster.

## 7. Rule quality principles (all engines)

- **Specific over broad** — anchor on behavior + context (parent/child, user,
  path, sequence), never a single broad field. "powershell.exe ran" is not a
  detection.
- **FP-resistant** — bake allowlists into the rule with comments explaining each;
  document residual FPs in the ADS doc.
- **Performant** — cheap predicates first; bounded time windows; no
  catastrophic regexes; profile expensive correlations.
- **Evasion-aware** — assume the adversary reads your rules. Don't anchor on a
  trivially changed string (a flag spelling, a filename). Anchor on the behavior
  they can't avoid.
- **Mapped & owned** — ATT&CK tags, stable ID, owner, test fixtures.

## Audit checklist

- [ ] Is each detection written in the right engine for its telemetry (Sigma for
      logs, YARA-X for files, network engine for the wire, Falco/Tetragon for
      runtime, SIEM-native only for correlation)?
- [ ] Are Sigma rules converted via pySigma/sigma-cli with a schema pipeline and
      CI-validated (`sigma check`), or hand-written per SIEM and copy-pasted?
- [ ] Are new YARA rules targeting **YARA-X** (not legacy YARA), and structural/
      behavioral rather than single-hash?
- [ ] Grep the ruleset for hash-only / single-broad-field detections — how many
      are pure IOC matches dressed as detections?
- [ ] Do Falco/Tetragon policies anchor on specific behaviors with exclusions,
      or fire on "any exec / any connection"?
- [ ] If Tetragon enforcement (`Sigkill`/`Override`) is enabled, is it scoped by
      selector and piloted in detect-only, with the same guardrails as IPS?
- [ ] Do SIEM-native queries bound their time windows and avoid unbounded
      joins/regexes that cause noise or cluster load?
- [ ] Is every rule evasion-aware (anchored on unavoidable behavior, not a
      trivially mutated string)?
- [ ] Does each rule carry ATT&CK tags, a stable ID, an owner, and test
      fixtures?

# 04 — Alerting, Triage, SOC & SOAR

A detection that fires is useless until a human (or trusted automation) acts on
it correctly and quickly. The SOC is where detections become outcomes — and
where most programs fail, by drowning analysts in noise until they stop looking.
Read this when designing alert flow, fighting alert fatigue, tuning, assigning
severity, enriching/correlating, writing runbooks, building SOAR automation, or
auditing SOC effectiveness.

Boundary: **sota-observability rules/04 owns the alerting *plumbing*** (routing,
paging, dedup transport, on-call rotation, SLO burn-rate alerts for ops). This
rule owns the *security* content riding that plumbing: which security signals
page, how they're triaged, and how the SOC stays sane.

## 1. Alert fatigue is the dominant failure

The single most common reason a SOC misses a real attack: the true positive was
one of 9,000 alerts that day and nobody looked. Treat signal-to-noise as the
program's primary health metric.

- **A chronically ignored alert is a Critical defect**, not a backlog item. If
  analysts mute, auto-close, or skip a detection, it is providing negative value
  (consuming attention, creating false confidence). Fix or retire it.
- **Precision over recall at the alert tier.** A detection at 5% true-positive
  rate trains analysts to ignore it — including the one time it's real. Move
  low-precision logic to *hunting* (rules/05) or add corroboration; don't page
  on it.
- **Measure it.** Alerts/analyst/shift, % auto-closed, % actioned, time-to-
  triage. Rising volume with flat true positives means the SOC is getting worse,
  not busier.

## 2. Tuning & suppression — always with expiry

Tuning is continuous, not a launch task.

- **Tune by adding context, not by deleting detections.** Scope tighter, add
  allowlists for known-benign (with comments), require corroboration. Preserve
  the detection's intent.
- **Suppressions MUST expire.** A permanent suppression is a silent blind spot
  that outlives the reason it was created. Every suppression carries an owner,
  a reason, and an expiry date; on expiry it's re-reviewed, not auto-renewed.

```yaml
# suppression with mandatory expiry — never "forever"
suppression:
  detection_id: 9b2e-...
  reason: "Backup job svc_backup triggers T1003 LSASS-read FP; ticket SEC-412"
  scope: { host: bkp-01, user: svc_backup }
  owner: alice
  expires: 2026-09-01        # re-review, do not auto-extend
```

Audit smell: suppressions with no `expires`, or a suppression list longer than
the detection list. Both mean the SOC is silencing rather than tuning.

## 3. Severity & priority

Assign severity honestly and consistently; inflation is as harmful as noise.

- Base severity on **impact × confidence × asset criticality**, not on how scary
  the technique sounds. A high-confidence detection on a crown-jewel system
  outranks a low-confidence detection on a sandbox.
- Reserve the top severity (page-a-human-now) for signals that are both
  high-confidence and high-impact. If everything is Critical, nothing is.
- Enrich severity dynamically: the same detection on a production identity-provider
  host is higher priority than on a test VM. Asset/identity context (below)
  drives this.

## 4. Enrichment

Every alert should arrive *pre-investigated* so triage is seconds, not a
research project. Auto-attach:

- **Asset context** — what is this host/account/resource, who owns it, how
  critical, is it internet-facing.
- **Identity context** — user role, privilege level, recent auth behavior,
  whether the account is service vs. human (feeds sota-identity-access
  anomaly detections).
- **Threat-intel context** — is this IP/domain/hash known-bad, and from which
  actor (rules/05 TI). TI is enrichment, not the detection.
- **Related signals** — other alerts on the same entity in the window.

Enrichment is what lets an analyst (or SOAR) decide in one screen. Unenriched
alerts force per-alert manual lookups — a hidden multiplier on triage time.

## 5. Deduplication & correlation

Raw detections produce many events per real incident. Collapse them:

- **Deduplicate** identical/near-identical alerts into one case with a count.
- **Correlate** related signals on the same entity/time window into a single
  incident (the "alert storm = one breach" pattern). EQL sequences or SIEM
  correlation rules (rules/03 §6) build these.
- **Aggregate to risk** where supported: many low-confidence signals on one
  entity crossing a risk threshold becomes one high-confidence alert (risk-based
  alerting) — turns noise into signal instead of suppressing it.

The analyst should see *incidents*, not a firehose of atomic events.

## 6. Runbooks — every alert, no exceptions

**No actionable alert reaches a human without a runbook.** The runbook answers:
what does this detection mean, what's the blast radius, how do I confirm TP vs.
FP, what are the first containment steps, who/when to escalate. Link it from the
alert payload.

- Wire the *delivery/linking* via sota-observability rules/04 (alerting +
  runbook plumbing); you own the *security content* of the runbook.
- A runbook that's never been executed is a draft. Validate runbooks during
  tabletops and after real incidents (rules/06).
- Audit: pick 5 firing detections; how many have a linked runbook with concrete
  triage and containment steps vs. an empty wiki stub?

## 7. SOAR & automation — with guardrails

Automate the repetitive, gate the dangerous.

- **Safe to automate:** enrichment (lookups, geo, TI, asset/identity), dedup/
  correlation, ticket creation, evidence collection, notifying the user "was
  this you?".
- **Auto-containment needs guardrails.** Isolating a host, disabling an account,
  revoking a token, or killing a process (Tetragon `Sigkill`, rules/03) can
  cause an outage if the trigger was a false positive. Guardrails:
  - High confidence only (corroborated/risk-threshold detections, not single
    noisy signals).
  - **Blast-radius limits** — never auto-isolate a production database primary or
    disable a break-glass/admin account; allowlist the untouchables.
  - **Reversibility & audit** — every automated action is logged, attributable,
    and reversible; prefer "quarantine" over "destroy."
  - **Human-in-the-loop for high-impact** — propose-and-approve, not auto-execute,
    above a blast-radius threshold.
- Automation that can take down production is itself an attack surface and an
  availability risk — threat-model it (sota-threat-modeling) and least-privilege
  its credentials (sota-secrets-management).

## 8. Case management & the FP lifecycle

- **One case per incident**, accumulating all correlated alerts, enrichment,
  analyst notes, and actions — the evidentiary spine for IR (rules/06) and the
  post-incident review.
- **Disposition every alert** (TP / FP / benign-true / duplicate). Undispositioned
  alerts mean you can't measure precision or know what to tune.
- **The FP feedback loop is mandatory:** an FP disposition feeds back to tuning
  (§2) — add the allowlist, file the suppression-with-expiry. FPs that are closed
  but never fed back guarantee the same FP tomorrow.

## 9. SOC metrics

- **Time-to-triage / time-to-disposition** — speed of the human tier.
- **Alert precision** per detection — drives tune-or-retire decisions.
- **Auto-close rate** — high rate = the detection shouldn't page.
- **Coverage of runbooks** — % of paging detections with a validated runbook.
- **Automation rate** — % of toil automated (without crossing into unsafe
  auto-containment).

Avoid the vanity trap: "alerts handled" rewards noise. Reward incidents resolved
correctly and fast.

## Audit checklist

- [ ] What's the alert volume per analyst per shift, and the % auto-closed/
      ignored? Is any detection chronically muted (a Critical defect)?
- [ ] Are low-precision detections paging humans, or moved to hunting/
      corroboration?
- [ ] Do all suppressions have an owner, reason, and **expiry**? Hunt the
      suppression config for entries lacking an `expires`/`ttl` field.
- [ ] Is severity based on impact × confidence × asset criticality, or inflated
      so everything is Critical?
- [ ] Do alerts arrive enriched (asset/identity/TI/related signals), or must
      analysts do manual lookups per alert?
- [ ] Are alerts deduplicated and correlated into incidents, or does the analyst
      face a firehose of atomic events?
- [ ] Pick 5 paging detections: how many have a linked, concrete, executed-at-
      least-once runbook?
- [ ] Does any auto-containment exist? If so: confidence gate, blast-radius
      allowlist of untouchables, reversibility, audit logging, and human-in-loop
      above a threshold?
- [ ] Is every alert dispositioned, and do FP dispositions feed back into tuning
      (suppression-with-expiry / allowlist)?
- [ ] Are SOC metrics outcome-based (precision, time-to-disposition, runbook
      coverage) or vanity-based (alerts handled, events processed)?

# 05 — Threat Hunting, Intelligence & Deception

Detections catch what you anticipated. Hunting finds what you didn't; threat
intel tells you what to look for and contextualizes what you find; deception
manufactures the highest-fidelity signals you'll ever own. Read this when
running hunts, building/operating a threat-intel capability or TIP, consuming
STIX/TAXII feeds, or deploying honeypots/honeytokens/canaries. (Especially
load-bearing if you operate a threat-intel platform or a deception zone.)

## 1. Hypothesis-driven hunting & the hunt loop

Hunting is the proactive, human-led search for adversary activity that evaded
existing detections. It is **hypothesis-driven** — not "go look at the data," but
"I believe X is happening; here's how I'd prove it."

The hunt loop:

```
1. Hypothesis      "An adversary who phished a dev is using their cloud creds
                    to enumerate IAM (T1087) from a new ASN."
2. Scope data      Which logs witness it? (cloud audit + identity, rules/02)
3. Hunt            Query/baseline/stack-count to find anomalies; pivot.
4. Findings        TP → incident (rules/06). FP/benign → understand baseline.
5. Operationalize  Turn a repeatable hunt into a *detection* (rules/01). A hunt
                    you run twice should become a rule.
```

The fifth step is what makes hunting compound: every successful hunt either
finds an intrusion or produces a new detection (and a tuned baseline). A hunt
program that never spawns detections is just expensive log-staring.

Where hypotheses come from: threat intel (a new actor TTP, §3), ATT&CK coverage
gaps (rules/01 — hunt the cells you can't yet detect), crown-jewel attack paths
(threat modeling), and anomalies analysts notice.

## 2. Structured analytic techniques & IOC vs IOA/TTP hunting

- Use **structured analytic techniques** to fight bias: state assumptions
  explicitly, consider alternative explanations (could this be benign admin
  activity?), seek disconfirming evidence. The brittle failure of hunting is
  confirmation bias — finding the "attack" you went looking for.
- **IOC hunting** (find this hash/IP/domain) is fast, retrospective, and brittle
  — best for *retro-hunting* a fresh intel indicator across history (rules/02
  retention). **IOA/TTP hunting** (find this *behavior*) is durable and is what
  catches novel and evasive actors. Weight your hunt program toward behavior, per
  the Pyramid of Pain (rules/01 §4).
- Useful behavioral techniques: **stack counting** (frequency-of-occurrence —
  rare parent/child pairs, rare process paths), baselining (deviation from an
  entity's own history), and **least-frequency analysis** (the one host doing
  the thing no other host does).

## 3. Threat intelligence: lifecycle, TIP, standards

Threat intel is a process, not a feed subscription. The lifecycle: **direction →
collection → processing → analysis → dissemination → feedback.** Without
direction (what decisions does this intel serve?) and feedback (did it help?),
a TIP becomes an expensive IOC landfill.

- **Tiers of intel:** strategic (who targets our sector, their objectives),
  operational (campaigns, TTPs), tactical (IOCs/atomic indicators). Tactical
  IOCs are the lowest-value, fastest-decaying tier — treat them as enrichment
  and retro-hunt fuel, not as your detection strategy (Pyramid of Pain again).
- **TIP (Threat Intelligence Platform):** ingests, deduplicates, scores, ages-out,
  and disseminates intel; the engine that turns feeds into *operationalized*
  detections and enrichment. Aging-out matters: a 2-year-old IP IOC is mostly
  noise. Score by confidence and source, and expire indicators.
- **Intel-driven detection:** the highest-value output is converting an actor's
  *TTP* (not their IOCs) into a durable detection (rules/03). When intel says
  "actor uses technique T1234," the deliverable is a tested detection, not an
  IOC import.

### STIX 2.1 / TAXII 2.1

- **STIX 2.1** — the OASIS standard data model for cyber threat intelligence
  (objects: indicators, attack-patterns, threat-actors, relationships, etc.).
- **TAXII 2.1** — the OASIS standard transport (collections + channels) for
  exchanging STIX over HTTPS.
- Both have been **approved OASIS Standards since 2021** (verify at
  oasis-open.org / docs.oasis-open.org/cti). Build the TIP to speak STIX 2.1 over
  TAXII 2.1 so it interoperates with ISACs, vendors, and sharing communities
  rather than locking into a proprietary feed format.

### Framing models

- **Diamond Model** (adversary–capability–infrastructure–victim) — pivot across
  the four vertices to expand from one indicator to a campaign.
- **Cyber Kill Chain / ATT&CK** — situate observed activity in the intrusion
  lifecycle to anticipate the next step and find earlier-stage evidence.

## 4. Deception: the highest-fidelity detection you own

Legitimate users have no reason to touch a decoy. So a triggered deception
asset has a **near-zero false-positive rate** — the inverse of every log-based
detection, where FPs are the dominant cost. Deception is force-multiplying
signal: cheap to deploy, expensive for the adversary to avoid (they can't tell
the decoy from the real thing).

- **Honeytokens / canary credentials** — fake AWS keys, API tokens, DB
  connection strings, service-account creds planted where an adversary who's
  inside will find them (config files, CI variables, a "secrets" doc, a
  honeypot's environment). *Any* use = compromise, full stop. Coordinate planting
  and alerting with **sota-secrets-management rules/04 (honeytokens)** — that
  skill owns the credential mechanics; you own detecting and responding to use.
- **Canary tokens** — tripwires beyond credentials: a watched URL, a tracked
  document, a DNS canary, a unique S3 object. Fired = someone is somewhere they
  shouldn't be.
- **Honeypots / deception zone** — decoy services/hosts (and, in K8s, decoy
  pods/secrets) that look real. Interaction = malicious by definition. The
  goal is to seed it across the paths attackers
  *must* traverse (lateral movement targets, credential stores, "admin" panels)
  so movement trips a wire early.
- **Placement is everything.** A honeytoken nobody encounters never fires; one in
  the adversary's natural path (the file they'll grep, the creds they'll spray)
  fires on first contact. Place decoys along real attack paths, not in a corner.
- **Detection wiring.** Every deception asset must alert with maximum severity
  and rich context (who/where/how) and route straight to IR — these are
  presumed-true-positive (rules/04 routes; rules/06 responds). Guard against the
  adversary detecting the decoy (timing, fingerprintable artifacts) where you
  can, but even crude deception yields high-value signal.

## Audit checklist

- [ ] Is hunting hypothesis-driven (stated, falsifiable hypotheses) or
      unstructured log-staring?
- [ ] Does every successful/repeatable hunt get operationalized into a detection
      (rules/01)? Or do findings evaporate after the hunt?
- [ ] Is the hunt program behavior/TTP-weighted, or mostly IOC sweeps?
- [ ] Are structured analytic techniques used to counter confirmation bias
      (alternative hypotheses, disconfirming evidence)?
- [ ] Does the threat-intel program have *direction* and *feedback*, or is the
      TIP an IOC landfill?
- [ ] Are indicators scored by confidence/source and **aged out**, or kept
      forever (decayed IOCs = noise)?
- [ ] Is intel converted into *TTP detections*, or only imported as IOC matches?
- [ ] Does the TIP speak **STIX 2.1 / TAXII 2.1** for interoperability with
      sharing communities?
- [ ] Are honeytokens/canaries/honeypots deployed along *real attack paths*
      (credential stores, lateral-movement targets), not in unused corners?
- [ ] Does every deception asset alert at max severity with context and route
      straight to IR? Hunt: enumerate planted canaries vs. those wired to an
      alert — any unwired decoy is a wasted tripwire.
- [ ] Are honeytoken mechanics coordinated with sota-secrets-management rules/04?

# 06 — Incident Response & Detection Validation

Detection without response is an alarm nobody answers; response without
validated detections is improvisation under fire. This rule covers both ends:
the IR lifecycle that turns an alert into a contained, learned-from incident,
and the adversary-emulation discipline that proves your detections actually fire
*before* a real adversary tests them for you. Read this when building IR
capability, writing playbooks, handling an incident, or setting up continuous
detection validation. Also the **AUDIT-mode entry point** alongside rules/04.

## 1. The IR lifecycle

The classic model is **PICERL** (Preparation, Identification, Containment,
Eradication, Recovery, Lessons learned). The current authoritative reference is
**NIST SP 800-61 Revision 3** (finalized April 2025), which reframes incident
response around the **CSF 2.0** functions — Govern, Identify, Protect, Detect,
Respond, Recover — emphasizing IR as continuous risk management woven into the
six functions rather than a standalone linear sequence (verify at
csrc.nist.gov). PICERL remains a fine operational mnemonic; map it onto the
CSF-aligned model:

- **Preparation / Govern+Identify+Protect** — the work done *before*: plan,
  roles, authority-to-contain, contacts, tooling, logging (rules/02), playbooks,
  tabletops. Most incidents are won or lost here.
- **Identification / Detect** — your detections, hunts, and deception (rules/03,
  /05) surface it; triage (rules/04) confirms scope and severity.
- **Containment / Respond** — stop the spread: isolate, disable, block, revoke.
  Short-term (stop bleeding) then long-term (sustainable lockdown).
- **Eradication / Respond** — remove the foothold: kill persistence, rotate
  compromised creds (sota-secrets-management), patch the entry vector.
- **Recovery / Recover** — restore to known-good, monitor for re-entry, validate
  the threat is gone before declaring done.
- **Lessons learned / Recover→Govern** — blameless PIR (§5) that feeds new
  detections and closes the loop back to Preparation.

## 2. Playbooks & severity classification

- **Playbooks per incident type** (account compromise, ransomware, cloud-key
  abuse, data exfil, K8s/container compromise, LLM/agent abuse) — concrete,
  step-by-step, with decision points and named roles. Distinct from a *runbook*
  (rules/04, per-alert triage); a playbook governs the whole incident.
- **Severity classification** drives the response tier (who's paged, how fast,
  whether leadership/legal/comms engage). Define levels by business impact +
  scope + data sensitivity, agreed in advance — not argued during the incident.
- **Declare incidents decisively.** Hesitation to call an incident is a common,
  costly failure. Err toward declaring; downgrading is cheap, lost early hours
  are not.

## 3. Forensic readiness, evidence & chain of custody

You cannot collect in the moment what you didn't prepare to collect.

- **Forensic readiness** — sufficient, integrity-protected, long-retained
  telemetry (rules/02) and the ability to snapshot volatile state (memory, disk,
  container/pod, cloud resource) before it's destroyed. Cloud/container
  ephemerality is the trap: a terminated pod or scaled-down instance takes its
  evidence with it — snapshot/preserve *before* containment kills it.
- **Evidence handling & chain of custody** — for anything that may support legal
  action or attribution: record who collected what, when, from where, and every
  subsequent handoff; hash evidence on collection and verify integrity; store
  read-only with access logging. A broken chain of custody can void the evidence
  entirely.
- **Order of volatility** — capture the most ephemeral first (memory, network
  state) before the durable (disk, logs).

## 4. Containment/eradication/recovery discipline

- **Contain before you eradicate, eradicate before you recover** — but preserve
  evidence first (§3). Pulling the plug destroys memory forensics; isolate
  (network-quarantine) instead where you need the box live.
- **Scope before you eradicate.** Eradicating one host while the adversary holds
  three others just tips them off. Use the incident's correlated entities
  (rules/04) and a hunt (rules/05) to size blast radius first.
- **Rotate all potentially exposed credentials** during eradication (assume the
  adversary took everything reachable) — coordinate with sota-secrets-management.
- **Recovery requires monitoring for re-entry** — heightened detection on the
  affected entities for a defined window; adversaries commonly return.

## 5. Blameless post-incident review (PIR)

- **Blameless** — focus on systemic/process gaps, not individual fault. Blame
  suppresses the honest disclosure that makes the review useful, and the next
  incident will be hidden longer.
- **Outputs that feed the loop:** for each "we didn't detect this early enough,"
  a new detection hypothesis (rules/01); for each "the runbook was wrong," a
  runbook fix (rules/04); for each "we couldn't get the evidence," a forensic-
  readiness gap (§3). A PIR that produces no detection/process changes was
  theater.
- **Track timeline metrics** (time to detect, contain, eradicate, recover) to
  measure whether the program is improving incident over incident.

## 6. Tabletop exercises

- Walk through realistic scenarios with the actual responders before a real
  incident. Tabletops find the broken phone tree, the missing authority-to-
  contain, the playbook nobody can locate — cheaply.
- Exercise the *decisions* (who can isolate prod? who calls legal? when do we
  notify?) and the *contacts* (are they current?). Run them regularly; rotate
  scenarios to match your top threats (threat modeling) and recent intel
  (rules/05).

## 7. Detection validation via adversary emulation (for defense)

**Validation is mandatory and defensive.** You run attacker techniques against
*your own* environment to prove your detections fire and your response works —
this is purple teaming and regression testing, not offense. A detection that's
never been triggered by the real technique is unproven.

Tools (verify current status at each project):

- **Atomic Red Team** (Red Canary) — a large library of small, ATT&CK-mapped
  "atomic" tests (~1,000+ tests across 200+ techniques). Run one atomic, confirm
  the mapped detection fires. The unit-test of detections; ideal for CI
  regression (rules/01 §2). github.com/redcanaryco/atomic-red-team.
- **MITRE Caldera** (now an Apache project, apache/caldera) — automated,
  campaign-style adversary emulation: chains techniques into an end-to-end
  operation to test detection *across the kill chain*, not just per-atomic.
- **Stratus Red Team** (DataDog) — cloud-native emulation (AWS/Azure/GCP/K8s);
  emulates cloud control-plane TTPs to validate cloud-audit detections (rules/02).
  github.com/DataDog/stratus-red-team. Pairs with the cloud/K8s/identity attacks
  the sibling skills prevent.
- **Breach-and-attack-simulation (BAS)** — continuous, automated emulation
  platforms for ongoing coverage assurance.

### Purple teaming & regression

- **Purple teaming** — red (emulate) and blue (detect/respond) work *together* in
  real time: run a technique, watch whether it's detected, tune on the spot,
  re-run. The fastest way to turn coverage gaps into detections.
- **Detection regression testing** — wire atomic tests into CI so a change that
  silently breaks a detection (a renamed field, a pipeline change, rules/02)
  fails the build, not the next incident. This is the test half of detection-as-
  code (rules/01 §2).
- **Continuous coverage assessment** — schedule emulation against the ATT&CK
  techniques in your threat model and update the Navigator layer (rules/01 §5)
  with *validated* (not merely *existing*) coverage. The honest coverage map is
  the one backed by a passing emulation.

### AI-system validation

For LLM/agent systems, validate detection of the threats in **MITRE ATLAS**
(the AI-system counterpart to ATT&CK; 16 tactics / 85+ techniques, growing
through 2026 agentic-AI updates — verify current counts at atlas.mitre.org) and sota-code-security rules/08: emulate
prompt-injection, tool/agent abuse, and model-exfil attempts against your own
agents and confirm runtime detections fire.

## Audit checklist

- [ ] Is there a written IR plan mapped to a current standard (NIST SP 800-61r3
      / CSF 2.0), with roles, severity tiers, and authority-to-contain defined
      *before* an incident?
- [ ] Are there incident-type playbooks (account compromise, ransomware, cloud-
      key abuse, data exfil, container, LLM/agent abuse) — concrete and current?
- [ ] Is forensic readiness real: can you snapshot a pod/instance/memory *before*
      containment destroys it, especially for ephemeral cloud/container workloads?
- [ ] Is there a chain-of-custody process (collector, time, hashing, read-only
      storage, access logging) for evidence that may be used legally?
- [ ] Does containment preserve evidence and scope blast radius before
      eradication, and rotate all exposed credentials?
- [ ] Are post-incident reviews blameless, and do they *produce* new detections/
      runbook fixes/forensic-gap closures (not just a doc)?
- [ ] Are tabletop exercises run regularly with the real responders, exercising
      decisions and verifying contacts are current?
- [ ] Are detections **validated against the real technique** via Atomic Red
      Team / Caldera / Stratus before they're trusted? Pick 5 — how many have a
      passing emulation test?
- [ ] Is detection regression testing wired into CI so a broken detection fails
      the build?
- [ ] Is coverage continuously assessed via emulation/purple-teaming, and does
      the Navigator reflect *validated* coverage?
- [ ] For LLM/agent systems, are ATLAS-class threats (prompt injection, agent
      abuse) emulated against your own agents to validate runtime detection?

# 07 — Active Directory Attack Detection

Detective controls for on-premises **Active Directory**: the Kerberos/NTLM
attacks (Kerberoasting, AS-REP roasting, golden/silver tickets, delegation
abuse), the domain-dominance techniques (DCSync, DCShadow), **ADCS** abuse, NTLM
relay, password spraying, and RBCD writes — plus the AD-specific deception that
catches them with near-zero false positives.

The **preventive** side — why these attacks work and how to design them out
(tiering, delegation hygiene, gMSA/dMSA, ADCS template hardening, KB5014754,
LAPS, `krbtgt` rotation) — lives in **sota-identity-access rules/07 (AD
hardening)**. Detect here; harden there. This file assumes the generic detection
discipline of rules/01 (ADS docs, detection-as-code, tuning with expiry) and the
telemetry principle of rules/02: **you cannot detect what you do not collect** —
so telemetry comes first.

## 1. Telemetry prerequisites

Domain-controller Security logs are the primary source; most AD attacks are
invisible unless **Advanced Audit Policy** subcategories are enabled and DC logs
are shipped centrally (local DC logs roll over fast and are the first thing an
attacker clears). Verify each event's meaning at
`learn.microsoft.com/.../auditing/event-<id>`.

| Event ID | Meaning | Why it matters |
|---|---|---|
| **4768** | Kerberos **TGT** requested (AS-REQ) | Ticket encryption type; account/host baselining; AS-REP roasting |
| **4769** | Kerberos **service ticket** requested (TGS-REQ) | **Kerberoasting** — RC4 (etype 0x17) TGS spikes; silver-ticket clues |
| **4770** | Kerberos service ticket **renewed** | Ticket-lifetime anomalies |
| **4662** | Operation performed on an AD **object** | **DCSync** — replication extended-rights GUIDs; sensitive-object access |
| **4624 / 4625** | Successful / **failed** logon | Password spray (4625 fan-out), lateral movement, logon-type anomalies |
| **5136** | A **directory-service object was modified** (with old/new value) | **RBCD** writes to `msDS-AllowedToActOnBehalfOfOtherIdentity`; ACL/attr tamper. Requires **DS Access → Directory Service Changes** auditing + SACLs |
| **8004** | **NTLM authentication** audit (NTLM Operational log, not Security) | NTLM usage/relay; requires *Restrict NTLM: Audit* policies |
| **4886 / 4887** | ADCS: certificate request **received** / **issued** | ADCS abuse (ESC1 requests, on-behalf-of enrollment). Requires CA "issue and manage" auditing |

**Baseline to enable on every DC:** Account Logon (Kerberos Authentication
Service + Service Ticket Operations, Credential Validation), Logon/Logoff, DS
Access (Directory Service Changes, with SACLs on tier-0 objects/OUs), and — where
NTLM/ADCS in scope — the NTLM Restrict-audit policies and CA object-access
auditing. Ship to the SIEM; **don't triage on the DC.** EDR/host telemetry
(LSASS access, `lsass` dumps, tool signatures) corroborates ticket-forgery and
credential-theft detections that the Security log alone can't confirm.

## 2. Detections (vendor-neutral logic sketches)

Sketches are Sigma-style pseudo-logic — compile to your SIEM (KQL/SPL/EQL) via
rules/03. Each carries an ATT&CK mapping (verify IDs at `attack.mitre.org`), the
dominant false positives, and triage/enrichment notes.

### Kerberoasting — T1558.003

```
source: Security 4769
where TicketEncryptionType == 0x17 (RC4)        # AES = 0x11/0x12
  and ServiceName not in (krbtgt, machine-accounts ending in '$')
  and TargetUserName is a real user account
detect: one principal requesting TGS for many distinct SPNs in a short window,
        OR any RC4 TGS for an account that normally negotiates AES
```

- **Signal:** RC4 (0x17) service-ticket requests — an attacker downgrades to the
  crackable etype — especially a **fan-out** of distinct SPNs from one account.
- **FPs:** legacy apps/appliances that genuinely negotiate RC4; scanners. Reduce
  by AES-hardening service accounts (identity rules/07) so RC4 becomes anomalous,
  then alert on RC4 at all.
- **Enrich:** requesting account, source host, count of distinct SPNs; a spike
  from a workstation (not an app server) is high-fidelity.

### AS-REP roasting — T1558.004

```
source: Security 4768
where PreAuthType == 0 (no pre-authentication)
  and TicketEncryptionType == 0x17 (RC4)
detect: AS-REQ for a preauth-disabled account, esp. many accounts from one source
```

- **Signal:** a TGT issued without pre-auth is the roastable AS-REP. In a hardened
  domain **no account should have pre-auth disabled** (identity rules/07), so any
  such 4768 is inherently suspicious. **FPs:** rare legacy accounts — enumerate
  and allowlist them (and fix them).

### DCSync — T1003.006

```
source: Security 4662
where Properties contains a replication extended-right GUID:
      1131f6aa-9c07-11d1-f79f-00c04fc2dcd2  (DS-Replication-Get-Changes)
      1131f6ad-9c07-11d1-f79f-00c04fc2dcd2  (…-Get-Changes-All)
      89e95b76-444d-4c62-991a-0facbeda640c  (…-Get-Changes-In-Filtered-Set)
  and AccountName is NOT a domain controller ('$' machine acct) and not AAD Connect
detect: replication request from any non-DC principal
```

- **Signal:** replication rights are used by **DCs only** — a non-DC principal
  invoking them is DCSync (credential theft, incl. `krbtgt`). **FPs:** DCs
  themselves, Entra Connect / AD sync accounts, some backup/monitoring tools —
  **allowlist the known replicators explicitly** and alert on everything else.
  High severity; pairs with a golden-ticket watch afterward.

### Golden & silver tickets — T1558.001 / T1558.002

- **Golden** (forged TGT with the stolen `krbtgt` key): anomalous **TGS (4769)
  without a preceding TGT request (4768)** for the same user/session; tickets with
  abnormal lifetimes (e.g. default 10-year forgeries) or accounts/RIDs that don't
  exist; RC4 tickets where the domain is AES. **Silver** (forged TGS for one
  service, signed with the service/computer key): **service access with no
  corresponding 4769 at the DC** — because a silver ticket never contacts the KDC.
  That absence is the tell: correlate service logons (4624 on the member server)
  against the DC's 4769 stream; a service session with no matching TGS is
  suspicious. **Enrich** with EDR ticket telemetry; these are forgery techniques
  so log *absence* and lifetime anomalies matter more than a single event.

### DCShadow — T1207 (Rogue Domain Controller)

```
detect: unexpected registration of a new nTDSDSA / server object or SPN
        (GC/E3514235-… replication SPN) on a non-DC computer  (5136/4742),
   then a replication push (4662 GetChanges) from that fake 'DC'
```

- A rogue-DC registration lets an attacker **push** malicious directory changes
  (e.g. SID history, ACLs) that bypass normal write auditing. **Signal:** a host
  that is not a real DC suddenly carrying DC-like objects/SPNs, followed by
  replication. **FPs:** legitimate DC promotion (`dcpromo`) — correlate with
  change tickets. Rare and high-severity.

### ADCS abuse — T1649 (Steal or Forge Authentication Certificates)

```
source: Security 4886/4887 (CA)  + 4768/4769 (subsequent auth)
detect (ESC1-style): certificate request on an auth-EKU template where the
        Requester != the Subject/SAN principal (enrollee-supplied SAN),
   OR a cert issued for a high-privilege principal to a low-priv requester,
   OR PKINIT TGT (4768) using a certificate right after an anomalous issuance
```

- **Signal:** the SAN/UPN in the issued cert **doesn't match the requester** (the
  ESC1 primitive), or a low-privileged account obtaining a cert that authenticates
  as an admin, then a **cert-based TGT (4768, PKINIT)** shortly after. **FPs:**
  enrollment agents legitimately enrolling on behalf of others (allowlist them),
  auto-enrollment. **Enrich** with the template name and EKU. See
  `sota-identity-access` rules/07 §3 for which templates are dangerous (ESC1/ESC4/ESC6/ESC8).

### NTLM relay & forced authentication — T1187

```
source: NTLM 8004 + Security 4624
detect: NTLM authentication where the *source* workstation and the account's
        home host disagree (relayed identity), NTLMv1 usage at all,
   OR a DC/computer account authenticating to an unexpected host right after a
      coercion trigger (EFSRPC/PetitPotam-class RPC)
```

- **Signal:** NTLM (esp. v1) where Kerberos was expected; a machine account
  authenticating outbound to an operator-controlled host (relay to LDAP/ADCS).
  **FPs:** legacy apps that only speak NTLM — inventory and allowlist, then treat
  new NTLM as anomalous. Pairs with the SMB/LDAP-signing hardening (identity
  rules/07 §2) that makes relay fail.

### Password spraying — T1110.003

```
source: Security 4625 (and 4768 failures with Kerberos error 0x18)
detect: one source (or few) → many distinct target accounts failing auth
        within a window, low attempts-per-account (below lockout threshold)
note: attackers prefer Kerberos/LDAP pre-auth failures (4768/4771) over SMB 4625
      to stay quieter — watch both surfaces
```

- **Signal:** horizontal fan-out (many accounts, few tries each) rather than
  vertical brute force. **FPs:** a misconfigured service with stale creds hitting
  many accounts; VPN/mobile reconnection storms. **Enrich** with source IP/ASN,
  time-of-day, and whether any attempt succeeded (pivot to 4624).

### RBCD / delegation-attribute writes — T1098 (Account Manipulation)

```
source: Security 5136
where AttributeLDAPDisplayName == 'msDS-AllowedToActOnBehalfOfOtherIdentity'
      (or msDS-AllowedToDelegateTo, servicePrincipalName on a user, userAccountControl
       delegation flags)  and OperationType == Value Added
detect: any write to the RBCD attribute by a non-tier0 principal
```

- **Signal:** writing `msDS-AllowedToActOnBehalfOfOtherIdentity` sets up
  resource-based constrained-delegation abuse; an SPN suddenly added to a *user*
  account enables Kerberoasting/targeted attacks. **FPs:** legitimate delegation
  configuration by admins — allowlist the tier-0 change process and alert on
  everyone else. Requires Directory Service Changes auditing + SACLs (§1).

### dMSA abuse / BadSuccessor — T1098 (where Windows Server 2025 DCs exist)

```
source: Security 5137/5136 + Directory Service 2946
detect: dMSA object (msDS-DelegatedManagedServiceAccount) created (5137) by a
        non-tier0 principal or in an unusual OU,
   OR a write (5136) to migration-link attributes
      msDS-ManagedAccountPrecededByLink / msDS-DelegatedMSAState,
   OR repeated dMSA TGTs / key-package fetches (2946) for one dMSA
```

- **Signal:** BadSuccessor (CVE-2025-53779, patched Aug 2025) links an
  attacker-created dMSA to a privileged account so the KDC merges that account's
  privileges and keys into the dMSA's tickets. The patch closes the direct
  escalation, but dMSA linkage still yields credential acquisition/lateral
  movement in already-compromised domains — the writes stay detection-worthy.
  **FPs:** genuine gMSA→dMSA migrations — allowlist the tier-0 migration
  process. Requires SACLs on dMSA objects/attributes (§1); event 2946 is in the
  Directory Service log, not Security.

Deception in AD yields near-zero-FP signals (identity attackers walk into it):

- **Honeytoken accounts / fake SPNs.** A decoy service account with an SPN (so it
  appears in any Kerberoast enumeration) and a **deliberately crackable-looking
  password**, but no real access. *Any* **4769 (TGS request) for that SPN** = an
  attacker enumerating/roasting — no legitimate service ever requests it. Similarly
  a decoy account with pre-auth disabled catches AS-REP roasters.
- **Canary AD objects.** A tempting-but-unused privileged-looking group or user,
  or an object with a **SACL** so any read/enumeration raises 4662. LDAP recon
  (BloodHound-style collection — neutral example) trips it.
- **Deceptive delegation / ACL bait.** An object that *looks* like a soft
  escalation path but is monitored; interaction is malicious by definition.
- **Wiring.** Every deception asset alerts at **max severity with full context**
  (source host/account) and routes straight to IR (rules/04 routes, rules/06
  responds). Place decoys **in the path attackers must traverse** — the SPN they
  will enumerate, the group they will target — not in an unused corner (see
  rules/05 §4 and **sota-secrets-management rules/04** for credential-honeytoken
  mechanics).

**Cross-reference:** enable/verify the underlying audit policy and log shipping
with rules/02; test every detection here against the real technique (Atomic Red
Team AD atomics, or purpose-built AD emulation) per rules/06 before trusting it —
an untested Kerberoasting rule is a hope, not a detection.

## Audit checklist

- [ ] Are DC **Advanced Audit Policy** subcategories enabled (Kerberos AS + Service Ticket ops, Credential Validation, Logon, **Directory Service Changes with SACLs on tier-0 objects**) and **DC Security logs shipped centrally** (not triaged on the DC)?
- [ ] Is **NTLM audit (event 8004)** and **CA issuance auditing (4886/4887)** enabled where NTLM/ADCS are in scope?
- [ ] Is there a **Kerberoasting** detection on **RC4 (0x17) 4769** with SPN fan-out, and is it meaningful (are service accounts AES-hardened so RC4 is anomalous)?
- [ ] Is there an **AS-REP roasting** detection on **4768 PreAuthType==0 / RC4**, with preauth-disabled accounts enumerated and allowlisted?
- [ ] Does a **DCSync** detection watch **4662 for replication GUIDs** (`…dcd2`, `…dcAll`, filtered-set) from **non-DC, non-sync** principals, with the legitimate replicators explicitly allowlisted?
- [ ] Are **golden/silver ticket** indicators covered — TGS (4769) without a preceding TGT (4768), abnormal ticket lifetimes/RIDs, and **service logons with no matching DC TGS** (silver)?
- [ ] Is **DCShadow** covered (rogue `nTDSDSA`/DC SPN registration on a non-DC, then replication)?
- [ ] Is **ADCS abuse (T1649)** detected — cert request where **requester != SAN principal (ESC1)**, privileged cert to low-priv requester, PKINIT TGT after anomalous issuance — with enrollment agents allowlisted?
- [ ] Is **NTLM relay / forced auth (T1187)** covered (NTLMv1 usage, relayed-identity mismatch, machine-account outbound auth after coercion)?
- [ ] Is **password spraying (T1110.003)** detected across **both 4625 and Kerberos 4768/4771 failures** (horizontal fan-out below lockout threshold)?
- [ ] Is there a **5136 detection on writes to `msDS-AllowedToActOnBehalfOfOtherIdentity`** (RBCD) and SPN-added-to-user, alerting on non-tier-0 writers?
- [ ] Where **Windows Server 2025 DCs** exist, is **dMSA abuse (BadSuccessor, CVE-2025-53779)** covered — dMSA creation (5137) by non-tier-0 principals or in unusual OUs, **5136 writes to `msDS-ManagedAccountPrecededByLink` / `msDS-DelegatedMSAState`**, and repeated dMSA TGTs (2946)?
- [ ] Are **honeytoken SPN accounts / canary objects** deployed (any 4769/4662 against them = high-fidelity alert) and **wired to IR at max severity**?
- [ ] Is each detection **ATT&CK-mapped, FP-documented, and validated against the real technique** (rules/06) before it is trusted?
- [ ] Does each detection carry known **false positives and an owner** (rules/01/04), with suppressions expiring rather than permanent?