Mapping Your Detection Coverage to MITRE ATT&CK (Honestly)

The heatmap problem

Every SOC eventually produces an ATT&CK heatmap. A grid of techniques, colored green where "we have coverage," presented to leadership, and quietly wrong.

The usual failure is not dishonesty. It is that "covered" is a binary answer to a question of depth. One rule tagged attack.t1059 turns Command and Scripting Interpreter green, and the map now claims coverage of a technique with nine sub-techniques, dozens of documented procedures, and endless evasion variants. An attacker running wscript.exe sails past your one PowerShell rule while the dashboard glows reassuringly.

A coverage map is worth building. It is only worth building if it measures what it claims to measure.

Technique-level vs procedure-level coverage

ATT&CK has three levels of granularity, and coverage means something different at each:

The gap between the last two rows is where heatmaps lie. Techniques are abstractions; attackers execute procedures. T1003.001 alone spans direct handle access, handle duplication, MiniDumpWriteDump via rundll32 and comsvcs.dll, ProcDump and its renamed copies, and physical-memory readers that never touch LSASS handles at all. A rule catching one of those is real value and honest work. It is not "T1003.001: covered."

The practical resolution: score techniques, but count procedures. For each technique in scope, list the known procedures (ATT&CK's procedure examples, DFIR reports, Atomic Red Team tests are good sources), then record how many your rules address. "3 of 7 known procedures" is a claim you can defend in a purple team exercise. A green cell is not.

Scoring depth instead of existence

Replace the binary with a small ordinal scale. Four levels are enough:

Two rules make this scale honest.

First: telemetry gates everything. A rule over logs you do not collect scores zero, whatever the rule repository says. If Sysmon Event ID 10 is not deployed, every LSASS-access detection you imported is decorative. Audit the telemetry assumption per technique before scoring the rules; ATT&CK's own data source annotations tell you what each technique requires.

Second: untested rules cap at 1. A detection that has never fired against a real or simulated execution of the technique is a hypothesis. Replaying attack event logs or running Atomic Red Team tests moves it to 2. This single policy stops the most common form of heatmap inflation, which is counting imported community rules as coverage.

Resist the urge to average scores into one "coverage percentage." An average of 62% across 200 techniques compresses away the only information that matters: which techniques sit at zero.

Prioritizing gaps by threat model

You will find gaps. More gaps than engineering time. The wrong response is coloring the map left to right; ATT&CK contains hundreds of techniques and sub-techniques, and many will never be relevant to your environment (no macOS fleet, no need for macOS persistence rules).

Prioritize by intersecting three sets:

1. Techniques used by actors that target your sector and stack. This is where actor intelligence earns its keep. Pull the TTPs of the groups realistically aimed at you, not the whole matrix. The profiles on actors.mlab.sh map 500+ groups to their documented techniques, which turns "what should we detect next" into a lookup instead of a debate.
2. Techniques that appear early or repeatedly in intrusions. Initial execution, credential access and lateral movement techniques give you multiple detection opportunities per incident. A gap in T1021.001 (RDP) costs more than a gap in an exotic exfiltration variant you would catch three other ways.
3. Techniques where you already have the telemetry. A gap you can close with a rule this sprint beats a gap that needs a six-month logging project. Track the second kind separately as a telemetry roadmap, not a rule backlog.

Rank the intersection, take the top ten, and write procedure lists for those before writing any new rules. Frequency data like the ATT&CK sightings ecosystem and annual DFIR retrospectives can stand in for step 2 when your own incident history is thin.

Keeping the map alive

A coverage map decays like any inventory. Three habits keep it truthful:

• Tag at the source. Every Sigma rule carries attack.t* tags in its YAML; make those tags mandatory in review and generate the map from the rule repository, never by hand. A hand-maintained spreadsheet diverges from reality within a quarter.
• Demote on failure. When a purple team exercise or incident review shows a technique executed without an alert, the score drops that day. The map must be allowed to get worse, or it will never be true.
• Re-score on telemetry change. A log source dropped for cost reasons silently zeroes every rule that depended on it. Telemetry changes should trigger a coverage review the same way schema changes trigger a pipeline review.

If your rules live in hunt.mlab.sh, the coverage tracker does the generation step for you: it reads the ATT&CK tags across your YARA and Sigma rule sets and maintains the technique map (200+ techniques tracked) as rules are added, converted or retired. Pair it with validation before anything ships, so a rule counts toward coverage only after it parses and converts cleanly.

What to report upward

Leadership does not need the matrix. They need three numbers and a list:

• Techniques relevant to our threat model: N
• Of those, at robust or partial coverage: X, at minimal: Y, at zero: Z
• The top five gaps, each with the actor or incident pattern that makes it urgent, and the cost to close it (a rule, or a telemetry project)

That report survives a follow-up question. A wall of green does not.

An honest coverage map is smaller, redder and more useful than the one you wanted to show the board. Build that one. The green version only has to fool an auditor; the red one has to beat an adversary.