MITRE ATT&CK Mapping Without Theater

MITRE ATT&CK mapping goes wrong the moment it becomes theater: a wall-sized heatmap glowing green, a coverage percentage in a board deck, and no actual improvement in what you can detect. Useful mapping does the opposite — it is quiet, honest, and drives decisions. It tells you which adversary behaviors you can see, which you cannot, and what to build next. This guide is how to map ATT&CK so it produces a backlog, not a scoreboard.

MITRE ATT&CK is a knowledge base of adversary techniques, and its value to a defender is as a shared language for coverage. The failure mode is treating the map as the goal. The map is a means: prioritize gaps, build validated detections, and measure honestly.

What is MITRE ATT&CK mapping, really?

ATT&CK mapping associates your detections, incidents, and threat intelligence with techniques in the ATT&CK matrix. The point is to answer a single question honestly: which adversary behaviors can we detect, and which can’t we? Everything else — the heatmaps, the percentages — is presentation. If the mapping does not change what you build, it is theater.

It is the connective tissue of the detection engineering workflow: a hypothesis maps to a technique, the technique shows whether it fills a real gap, and the resulting detection carries the technique ID for tracking. The mapping is in service of coverage, not coverage in service of a slide.

What does ATT&CK theater look like vs. honest mapping?

The dividing line is validation and relevance. Theater counts intent; honest mapping counts proven detections against the threats you actually face.

How to map ATT&CK without theater

A workflow that produces decisions, not decoration:

1. Scope to your threats. Use threat intel to identify the techniques used by adversaries relevant to your industry and stack — not all 600+ techniques equally.
2. Overlay current detections. Mark only validated detections (proven to fire on real attack telemetry).
3. Gate on data. A technique you cannot collect telemetry for is a data-source gap, not a detection gap — fix the data first.
4. Rank the gaps by threat likelihood × impact × data feasibility. That ranked list is your backlog.
5. Build, validate, and tag. Each new detection carries its technique ID, so coverage updates automatically and honestly.

Every detection on darkpwn — from SQL injection (T1190) to Kerberoasting (T1558.003) — carries its technique ID for exactly this reason.

title: Encoded PowerShell Command Execution
id: 1f7c3a92-darkpwn-illustrative
status: stable
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: [' -enc ', ' -EncodedCommand ']
  condition: selection
falsepositives:
  - Some legitimate deployment scripts
level: medium
tags:
  - attack.execution
  - attack.t1059.001

The sub-technique problem

Here is the most common way an honest-looking coverage map still overstates reality, and it is structural rather than dishonest.

ATT&CK Enterprise contains roughly two hundred techniques and well over four hundred sub-techniques. Coverage claimed at the technique level treats a parent as covered when a rule exists for any one of its children — and the children frequently require entirely different telemetry.

Take T1055, Process Injection. It has a dozen sub-techniques. A rule detecting remote-thread injection covers T1055.001 and T1055.002 reasonably well, and it is structurally blind to process hollowing, thread hijacking, and APC injection, which create no remote thread at all. Three of the sub-techniques are Linux-only and need a different data source entirely. One rule turns the parent cell green, and the actual coverage is a minority of the children.

This repeats across the matrix wherever a parent groups mechanically different behaviours.

Three corrections:

• Map at the sub-technique level wherever sub-techniques exist. It produces a less impressive heatmap and a truthful one, which is the entire premise of this guide.
• Colour a parent by the proportion of its children covered, not by whether any child is. A parent at 2 of 12 should not look identical to one at 12 of 12.
• Record which sub-techniques you deliberately deprioritised, and why. “T1055.011 is rare and needs EDR telemetry we do not have” is a legitimate decision. An unmarked gap is indistinguishable from an oversight, and next year nobody will remember which it was.

Not all detections are equally robust

Two rules can both map to the same technique and have very different lifespans. The mapping alone does not capture that, and it is usually the more important property.

David Bianco’s Pyramid of Pain is the original framing: indicators differ in how much they cost an adversary to change. A file hash costs nothing — recompile. An IP address costs little. Tools cost more. Behaviours and TTPs cost the most, because changing them means changing how the adversary operates.

MITRE’s own “Summiting the Pyramid” research extends this into a scoring method for analytics specifically — rating a detection by how tightly it is coupled to the technique rather than to a particular implementation of it. That distinction is what separates a rule that survives the attacker changing tools from one that breaks on the next release.

The practical implication for a coverage map: record the robustness level alongside the technique ID. A technique covered only by a tool-specific signature is meaningfully less covered than one detected by the behaviour the technique cannot avoid, and a map that cannot express that difference will rate them the same. When a vendor’s default C2 profile changes and half your green cells go dark simultaneously, that is what happened.

How do you score the data, not just the rules?

The guide says to gate on data. Doing that rigorously needs more than “do we have this log source,” because a log source can be present and useless.

DeTT&CT is the open-source tool built for exactly this. It scores data sources against ATT&CK along dimensions that determine whether a detection is actually possible:

• Device completeness — what proportion of relevant systems actually send this data. A Sysmon configuration deployed to 60% of endpoints supports a detection that is wrong 40% of the time, and reports clean.
• Data field completeness — whether the specific fields a rule needs are present. Process creation without command lines supports far fewer detections than process creation with them.
• Timeliness — how quickly the data arrives. Minutes is fine for detection and useless for automated response.
• Consistency — whether it arrives reliably or drops under load, which is precisely when it matters.
• Retention — how far back you can hunt. A detection window shorter than your dwell time means the investigation has no data for the period that matters.

Scoring those turns “we have EDR” into a defensible statement about what you can detect. It also reliably surfaces the uncomfortable finding that a substantial part of your detection library sits on a data source with partial coverage — which is a better thing to discover in a review than in an incident.

Separate visibility from detection in the map. A technique where you have the data and no rule is a detection backlog item, measured in days. A technique where you lack the data is an engineering project, measured in quarters. Colouring both the same colour makes the roadmap unplannable, and it is why “we need more detections” is so often the wrong conclusion drawn from an honest map.

ATT&CK changes underneath you

The framework is versioned and revised roughly twice a year. Techniques get added, deprecated, renamed, split into sub-techniques, and occasionally renumbered — the introduction of sub-techniques in 2020 restructured large parts of the matrix at once.

A coverage map built against one version and never revisited drifts silently:

• Deprecated techniques stay green forever, covering something that no longer exists as a concept.
• Newly added techniques appear as gaps you were never told about, because nothing in your process watches for them.
• Split techniques turn one honest mapping into several partly-wrong ones.

Two mitigations, both cheap:

• Record the ATT&CK version in your coverage artifacts, so a map’s age is visible rather than inferred.
• Review the release notes each version and diff your mappings against the changes. It is an hour or two, twice a year, and it is the difference between a living map and a snapshot that everyone still treats as current.

Keep detection tags in version control with the rules themselves, so the mapping changes travel through the same review as the logic. A coverage map maintained in a spreadsheet separate from the detections it describes diverges within a quarter, every time.

What should you actually report?

The coverage percentage is the artifact that causes the theatre, so replace it rather than defending it.

A defensible report has four numbers and a trend:

1. Techniques in scope — those used by threat actors relevant to your sector and stack, not all of ATT&CK. This number should be justifiable from threat intelligence.
2. Validated detections — techniques where a detection has been observed firing on real or simulated attack telemetry. Not rules that exist.
3. Data gaps — in scope, no telemetry. These are engineering projects with cost estimates.
4. Detection gaps — in scope, telemetry present, no rule yet. These are the backlog, and this is the number that should move most between reports.

Then the trend across quarters, which is the only part that demonstrates a functioning programme.

Say plainly that 100% is neither achievable nor the goal, and say it early, because the alternative is being asked why the number is not higher every quarter forever. Some techniques are irrelevant to your environment, some are prohibitively expensive to detect, and some are better addressed by prevention than detection. ATT&CK’s own guidance is explicit that the matrix is not a checklist. A programme that reports 45% against a threat-scoped subset with a rising validated count is in far better shape than one reporting 90% against the whole matrix on untested rules — and the second is much easier to produce.

The detections that do not map

A closing honesty point, because forcing this ruins good work.

Some of your most valuable detections do not correspond to an ATT&CK technique. Impossible travel, anomalous data volume, a first-ever certificate authentication for a privileged account, an allowlisted beacon going silent — these are anomaly detections that catch many techniques imprecisely rather than one technique precisely. Forcing an ATT&CK tag onto them produces a mapping that is wrong and a coverage claim that is misleading.

Let them exist unmapped. Track them as a separate category in the same library, with the same validation standard. A detection programme measured only by ATT&CK coverage will quietly deprioritise anomaly detection, because it does not move the number — and anomaly detection is frequently what catches the technique nobody had a rule for, which is the situation the whole exercise exists to prepare for.

How to use ATT&CK for defense, not just offense

ATT&CK catalogs attacker techniques; MITRE D3FEND maps defensive countermeasures to them. Use them together: ATT&CK shows the gap, D3FEND suggests the control or detection that addresses it. And validate coverage by generating the technique safely — Atomic Red Team and purple-team exercises prove a detection fires rather than assuming it.

How do you scope the matrix to your threats?

“Scope to your threats” is the first step in the workflow above and the least specified. Here is how to do it without a threat-intelligence team.

1. Start from your sector and your stack. Public reporting on incidents in your industry names techniques. So do the joint advisories published by national cyber agencies, which include ATT&CK mappings in a usable form.
2. Add the techniques from your own incident history. What happened to you is the strongest available evidence about what will happen to you again, and it is the input organisations most consistently underweight in favour of external reporting.
3. Add the techniques your architecture makes cheap. If you run a large Active Directory estate, the AD techniques are relevant regardless of who is reportedly targeting your sector. If you are entirely cloud-native, most of them are not.
4. Add the commodity techniques everyone gets. Phishing, valid accounts, and the living-off-the-land binaries appear in nearly every intrusion irrespective of actor.
5. Explicitly exclude what does not apply, in writing. Techniques for platforms you do not run, or for an actor sophistication you are not a plausible target for, should be marked out of scope with a reason rather than left as permanent grey cells that everyone quietly ignores.

That produces a scoped set — usually a small fraction of the full matrix — that you can honestly claim to be working through. It also produces the artifact that makes the coverage number defensible, because the first question about any coverage figure is “of what?”

Revisit the scope annually, not the coverage. Coverage should change every quarter as you build detections. The scope should change when your threat landscape or your architecture changes, and treating it as stable is what lets the trend line mean something.

Common ATT&CK mapping mistakes

• Coverage theater. Counting untested rules inflates confidence and starves real gaps of funding.
• Mapping everything equally. Without threat weighting, the backlog has no priority.
• Ignoring data gaps. A detection gap you cannot collect data for is a data problem first.
• Vague mappings. A technique tag that does not match the rule’s actual logic is worse than no tag.
• Mapping at technique level where sub-techniques exist. One rule turns a parent green while covering a minority of its children, and the children often need different telemetry entirely.
• Recording the technique but not the robustness. A tool-specific signature and a behaviour-level detection score identically on a heatmap and have very different lifespans.
• Treating “we have the log source” as data coverage. Device completeness, field completeness, timeliness, consistency, and retention all determine whether a detection is actually possible.
• Colouring data gaps and detection gaps the same. One is a backlog item measured in days; the other is an engineering project measured in quarters, and conflating them makes the roadmap unplannable.
• Never re-checking against a new ATT&CK version. Deprecated techniques stay green forever and new ones appear as gaps nobody was told about.
• Keeping the coverage map separate from the rules. A spreadsheet maintained apart from the detections it describes diverges within a quarter, every time.
• Reporting a single coverage percentage. It is the artifact that produces the theatre; report in-scope, validated, data-gapped, and detection-gapped counts with a trend instead.
• Forcing an ATT&CK tag onto anomaly detections. Impossible travel and volume anomalies do not map cleanly, and a programme measured only by coverage will quietly stop building them.

MITRE ATT&CK mapping checklist

1. Scope to techniques used by threats relevant to your organization.
2. Overlay only validated detections onto the matrix.
3. Treat techniques you cannot collect data for as data-source gaps.
4. Rank gaps by likelihood × impact × data feasibility into a backlog.
5. Tag each new detection with its technique ID; update coverage from validated rules.
6. Use D3FEND to select countermeasures for prioritized gaps.
7. Validate coverage with Atomic Red Team / purple-team exercises.
8. Report coverage as validated detections, never as rules-that-exist.

The takeaway

MITRE ATT&CK mapping without theater means mapping to prioritize, counting only validated coverage, gating on the data you collect, and using the matrix as a backlog you work down. The heatmap is a byproduct, not the goal. Continue with the detection engineering workflow and the Sigma rule lifecycle, or browse the full Detection Engineering pillar.