Coverage Mapping Against ATT&CK
A single detection mapped to a single technique tells you something. Dozens or hundreds of detections, each mapped the same way, tell you something much more useful: where your program actually stands. This chapter is about turning a pile of individual technique tags into a coherent picture of coverage, where that picture lies to you if you build it carelessly, and how to use it to decide what to build next. The goal isn't a prettier spreadsheet. It's replacing "I think we'd catch that" with an answer you can defend.
Why Map Detections to ATT&CK
Individually, a technique mapping is a small piece of metadata. It tells whoever reads a detection's documentation what adversary behavior it's meant to catch, using a shared vocabulary instead of a one-off description that only makes sense to the person who wrote it. That alone is worth doing. But the real payoff shows up when those mappings stop being individual footnotes and start being aggregated.
What Aggregation Makes Possible
Once every detection in your environment carries a technique tag, you can ask a question that's almost impossible to answer any other way: across the full breadth of adversary behavior described in ATT&CK, which of it do we actually have eyes on? Not "which of it do we believe we'd catch," which is a question people answer from memory, gut feeling, and whatever incident happened to come up in the last team meeting. An aggregated view answers it from what's actually deployed and actually firing.
Why This Beats Institutional Memory
This distinction matters more than it sounds like it should. Ask an experienced analyst whether the team would detect a particular credential-dumping technique and they'll usually say yes, with real confidence, because they remember writing something related to it eighteen months ago. A coverage matrix built from live mappings answers it directly, because it only counts what's actually there.
- Whether that detection still exists
- Whether it still fires
- Whether it still matches the way the technique is actually executed today
- Whether it hasn't been quietly disabled for being too noisy
Building a Coverage Matrix
The Basic Grid
The basic structure is a grid. One axis lists ATT&CK tactics and the techniques (and sub-techniques) under them. The other axis is your own detection inventory. Where a detection maps to a technique, that cell gets marked. Read down any technique column and you can see, at a glance, whether it has one detection, several, or none at all.
Spreadsheet or ATT&CK Navigator
Built by hand in a spreadsheet, this works fine for a modest detection count and is a reasonable way to start: a list of techniques down the side, a column per detection or detection category, and a mark wherever a mapping exists. It's transparent, easy to audit, and doesn't require standing up any new tooling.
At larger scale, the tool most teams reach for is the ATT&CK Navigator, a free, publicly available tool built specifically for this. It renders the full ATT&CK matrix as a heat map: you assign each technique a score or a color based on how well it's covered, and the Navigator lays that out visually across the whole matrix, tactic by tactic.
The mechanics of producing the underlying scores are the same either way, a spreadsheet or the Navigator is just a different way of visualizing the same data.
- Your own coverage
- A threat actor's known technique list
- A red team exercise's scope
What Goes Into a Cell
At minimum, a cell needs to record that a mapping exists. In practice, a coverage matrix that stops there is only marginally useful, because it can't distinguish a technique with five overlapping, well-tuned detections from a technique with one narrow rule nobody has looked at since it was written. The next section is about why that distinction is the whole point.
| Matrix input | Where it comes from |
|---|---|
| Technique / sub-technique ID and name | The current ATT&CK framework version you're mapping against |
| Detection name and mapped technique(s) | Detection metadata, tagged at write time per chapter 3 |
| Detection status | Live, tuned-down, disabled, or retired, pulled from your detection inventory |
| Coverage depth rating | An assessed judgment, covered in the next section |
Coverage Is Not Binary: Depth and Confidence
Mapped Is Not the Same as Covered
The most common mistake in coverage mapping is treating "mapped" and "covered" as the same thing. They aren't. A technique in ATT&CK is often a broad category of behavior with several sub-techniques underneath it and, within each sub-technique, a range of tools, commands, and implementation details an adversary could use.
A single detection that fires on one specific command-line pattern used by one specific tool can legitimately be mapped to that technique. It is also, on its own, nowhere close to covering everything the technique represents.
A Concrete Example: T1059
Command and scripting interpreter abuse (T1059) is a useful example precisely because it's so broad: it spans PowerShell, cmd, bash, Python, and several other interpreters, each with its own sub-technique and its own near-infinite set of ways to invoke something suspicious. A detection tuned to one narrow PowerShell encoding pattern is a real, valid mapping to T1059.
It does not mean command-and-scripting-interpreter abuse is "covered" in any meaningful sense, and a matrix that marks that cell the same way it marks a technique defended by three overlapping detections across multiple interpreters and data sources is actively misleading.
The False-Confidence Risk
That's the false confidence this chapter's title warns about: a matrix full of checkmarks marked "covered" (a depth judgment, not a color judgment) that looks complete on a dashboard but represents wildly uneven actual protection underneath. Executives and auditors who see a mostly-filled grid will assume mostly-filled means mostly-safe. It doesn't, unless the ratings underneath account for depth.
A Simple Depth Scale
The fix isn't complicated: rate each covered cell on a small scale instead of just marking it present or absent. A common approach uses three levels.
| Rating | Meaning |
|---|---|
| None | No detection maps to this technique at all. |
| Partial | One or a few narrow detections exist, each tied to a specific tool, procedure, or data source. Plausible variations of the technique would likely slip past. |
| Broad | Multiple detections cover this technique across different data sources, tools, and known procedure variations, reducing single-point-of-failure risk. |
Some teams add a confidence dimension alongside depth, capturing how recently a detection was validated and how well it has held up against tuning. A broad rating on a detection nobody has revisited in over a year is worth less than the label implies. The scale doesn't need to be elaborate to be useful; it just needs to force a real judgment instead of a checkbox.
Finding Real Gaps
A finished matrix, even a depth-rated one, is still just an inventory. The point of building it is to decide what to work on next, and a matrix with forty "none" cells doesn't mean forty equally urgent projects. Some gaps matter far more than others, and prioritizing them well depends on weighing a few different factors together rather than picking whichever technique looks most alarming on a given day.
Relevance to Your Actual Threat Model
Not every technique in ATT&CK is equally likely to be used against your organization. Threat actors who target your industry, use tooling your existing telemetry would actually surface, or have shown up in your own prior incidents represent a very different priority than techniques that are theoretically possible but have never once been relevant to anyone resembling your environment.
This is where the Threat Intelligence module's coverage of actor profiling and technique tracking feeds directly into detection engineering: a gap tied to a technique your relevant threat actors actually use is a gap worth closing before one that only shows up in generic industry reporting.
Ease of Reliable Detection
Some techniques are inherently easier to detect well than others, independent of how dangerous they are. A technique that reliably produces a specific, low-noise log event is a better near-term investment than one where any reasonably competent detection would require correlating half a dozen weak signals and would still carry a high false-positive rate.
That doesn't mean the harder techniques get ignored forever, but sequencing the easier, higher-confidence wins first builds real coverage faster and avoids sinking early effort into a detection that will end up disabled within a month for being too noisy.
Blast Radius If Missed
Where a gap sits in the attack chain changes how expensive it is. A gap in an early-stage technique, something in initial access or early execution, is often less costly on its own, because there are usually several more stages downstream where the same intrusion could still be caught: lateral movement, credential access, command and control.
A gap in a late-stage technique like exfiltration or impact has far fewer remaining chances to be caught after it. The intrusion is essentially over by the time that technique executes. Weighing gaps by their position in the chain, not just by how severe the technique sounds in isolation, tends to produce a more defensible prioritization.
Coverage Mapping Pitfalls
A coverage matrix is only as honest as the mapping discipline behind it, and there are a couple of ways that discipline tends to erode over time.
Neither of these pitfalls has a purely technical fix. They're process problems, solved by scheduling matrix reviews the same way you'd schedule detection tuning reviews, and by treating the coverage percentage as a tool for finding gaps rather than a number to defend in a meeting.
Connecting Coverage Back to Chapter 3's Hypothesis Process
Where the Gaps Feed Back
Coverage mapping isn't a one-time audit that produces a report and then sits untouched. Its real value is as a feedback loop into the hypothesis process chapter 3 walked through in detail.
Chapter 1 named ATT&CK gap analysis as one of the standard sources for new detection hypotheses, and this is exactly what that meant: the matrix built in this chapter is where those gap-driven hypotheses come from in the first place, ready to feed straight back into the hypothesis-to-logic process chapter 3 laid out.
From Gap to Hypothesis
A ranked gap list from the prioritization work above isn't the end of the process, it's an input back into the start of it. Each high-priority gap becomes a candidate hypothesis: a specific claim about a technique, the data source that could reveal it, and the logic that would separate genuine adversary behavior from normal activity.
That hypothesis goes through the same validation and tuning process any other detection would, and once it's live and mapped, it updates the matrix, which changes what the next round of prioritization looks like.
Run that loop consistently and coverage mapping stops being a periodic exercise bolted onto the program from the outside. It becomes the mechanism that tells a detection team where to point its limited engineering time next, grounded in what's actually deployed rather than what everyone assumes must already be there.
Key Takeaways
- Aggregating individual ATT&CK mappings into a single matrix turns assumed coverage into verifiable coverage, built from what's actually deployed and firing.
- A basic matrix plots detections against ATT&CK tactics and techniques; the ATT&CK Navigator is a common free tool for visualizing this as a heat map.
- A binary covered/not-covered marking hides false confidence. Rate coverage depth (none / partial / broad) to reflect how much of a technique's real variation is actually caught.
- Prioritize gaps using three factors together: relevance to your actual threat model, how reliably the technique can be detected, and how much blast radius a miss carries based on its position in the attack chain.
- Avoid treating coverage percentage as a vanity metric, and keep the matrix current as detections change and ATT&CK itself is updated.
- Coverage mapping feeds back into the hypothesis process from chapters 1 and 3: prioritized gaps become the next round of detection hypotheses, closing the loop.
Knowledge Check
Click an answer to reveal the explanation.
A technique has exactly one detection mapped to it, tuned to a single narrow command-line pattern from one specific tool. In a depth-rated coverage matrix, how should that cell most likely be rated?
Why is a gap in a late-stage technique like exfiltration generally treated as higher priority than a gap in an early-stage technique like initial access, all else being equal?
A team reports "82% ATT&CK coverage" as a headline metric, and the underlying matrix hasn't been reviewed in over a year. What two pitfalls does this scenario most directly illustrate?