CF-002 · Mapping Detections to ATT&CK Coverage

Mapping Detections to ATT&CK Coverage

A methodology case file: how observed adversary behaviour becomes an honest technique coverage map — and how the gaps in that map decide which detections get built next.

RoleSecurity Operations Analyst

ContextEnterprise SOC estates

ToolingSplunk · Defender · Sentinel

FrameworkMITRE ATT&CK Enterprise

InputSandbox findings + SOC telemetry

Period2021 — present

01 Briefing

Ask a SOC "are we covered against this threat?" and the honest answer is usually a feeling, not a fact. Detection coverage tends to live in tribal knowledge: rules exist, dashboards exist, but nobody can point at a technique an adversary actually uses and say tested, detected, here's the alert.

This case file documents the method I use to replace that feeling with a map: start from adversary behaviour that has actually been observed, normalise it to MITRE ATT&CK, and score what the existing telemetry and rules would really catch.

02 Threat model

The input isn't a wishlist of every ATT&CK technique — it's the behaviours with evidence behind them, from two directions:

Adversary-side evidence — techniques observed first-hand in sandbox analysis (the 30 techniques of CF-001: process injection, AMSI tampering, obfuscation, sandbox evasion, and the rest).

Defender-side evidence — what alert queues in Splunk, Defender for Endpoint, Sentinel, and CrowdStrike actually surface day to day, and what they stay silent about.

The asymmetry that matters — defence evasion is where adversaries invest hardest, so it's exactly where coverage claims need the most scrutiny.

03 Method

Collect observed behaviour — sandbox findings and incident telemetry, each with the evidence attached.

Normalise to ATT&CK — every behaviour becomes a technique ID, so lab work and SOC alerts speak the same language.

Score coverage per technique — for each technique: is the telemetry even collected, and does a rule fire on it? "Logged" is not "detected".

Rank the gaps — uncovered techniques ranked by observed adversary use, not by how easy the detection is to write.

Build, tune, re-measure — new or tuned rules go back through the same scoring, so the map stays honest.

Exhibit A — techniques observed per tacticsource: CF-001 sample set

Defense Evasion · TA00059
Execution · TA00024
Discovery · TA00074
Command & Control · TA00113
Persistence · TA00032
Credential Access · TA00062
Collection · TA00092
Impact · TA00402
Privilege Escalation · TA00041
Exfiltration · TA00101

Density of observed techniques by tactic — defence evasion (red) carries triple the weight of any other tactic, so it anchors the coverage review.

04 Findings

Key Finding Coverage claims not anchored to observed techniques produce false confidence — the map only earns trust when every "covered" cell can point to the telemetry and the rule that fires.

Coverage follows telemetry, not intent. The strongest cells sat where endpoint telemetry is richest — process creation, registry writes. The weakest sat where collection was assumed but never verified.

Defence evasion demands behavioural rules. Signature-led detections aged out fastest exactly where adversaries iterate hardest (T1027 obfuscation, T1562.001 tampering) — tamper-behaviour rules held up.

The "not observed" cells are a to-do list. Techniques adjacent to observed ones (service execution, token manipulation) became the prioritised backlog, ranked by adversary use rather than implementation convenience.

05 Impact

A defensible answer to "are we covered?" — technique by technique, with evidence, instead of a feeling.

A ranked detection backlog — engineering effort goes to the gaps adversaries actually exploit, and tuning work in Splunk and Defender is justified by the map rather than by alert-volume complaints.

A shared language with the business — ATT&CK IDs translate SOC work into risk conversations: this is what we'd catch today, this is what we wouldn't, and this is what closing the gap costs.