MITRE ATT&CK detection coverage: rule exists vs. validated.

Why coverage numbers mislead

Most security teams can produce a MITRE ATT&CK heatmap on request. The SIEM has a coverage page, the detection content vendor ships a matrix, and the board pack shows a percentage that grows every quarter. The trouble is what that percentage usually counts: techniques with at least one rule mapped to them. A mapped rule proves that somebody wrote a detection and tagged it. It does not prove that the rule is switched on, that the data it reads is arriving, or that it would fire if an attacker used the technique tomorrow.

The gap between those two ideas, a rule that exists and a rule that works, is where incidents hide. A disabled rule looks the same on a heatmap as an enabled one. A rule whose log source stopped sending last month still colors its cell. A rule that matches on a field your parser no longer populates will never fire, and nothing reports it. When the number on the slide does not separate these cases, it measures effort, not protection.

SOC Prime made the same point in a September 2026 analysis of coverage measurement: a catalog of rules, rules deployed in your SIEM, rules whose data is collected and healthy, and rules proven to fire are four different numbers, and only the last one describes what the SOC actually detects (S01).

The four levels of coverage

A useful coverage model treats each detection as a funnel. Every level is a gate the detection has to pass before it counts at the next one. SOCGenX reports every detection at one of these four levels.

Level 1. Rule exists

A detection is written and mapped to one or more ATT&CK techniques. This is the level most heatmaps report. It is worth knowing, because a technique with no rule at all is the clearest gap you have, but it says nothing about whether the rule runs.

Level 2. Rule enabled

The rule is deployed and switched on in the SIEM. This is where many built-in coverage views stop. Elastic's documentation, for example, notes that its MITRE ATT&CK coverage page shows installed and enabled rules, and that custom rules without a mapping do not appear (S02). Google SecOps offers a comparable MITRE ATT&CK matrix of the rules you have (S03). They are good inventories, and they answer the level 2 question.

Level 3. Data healthy

The log source the rule depends on is sending events, on time, with the fields the rule matches on populated and parsed correctly. A rule at level 2 with a silent source is dead weight. Frameworks such as DeTT&CT score data quality on device completeness, field completeness, timeliness, consistency and retention (S04), and MITRE's Center for Threat-Informed Defense maps which sensors and events reveal which behaviors (S05). Our SIEM health check guidecovers how to test this level in practice.

Level 4. Validated

The rule has been shown to fire against a real or simulated execution of the technique, in your environment, on your data. Validation is the only level that turns a claim into evidence. We also test the other side: a benign activity that looks similar must stay silent, so a validated rule is one that fires when it should and stays quiet when it should not.

A technique with only a disabled rule is not covered. Report it at the level it reached.

State the denominator

Every coverage percentage is a fraction, and the denominator matters as much as the numerator. A percentage of the whole ATT&CK matrix rewards adding easy detections for techniques that rarely matter to you, and it hides the handful that attackers in your sector actually use. SOC Prime recommends computing validated techniques divided by a prioritized set of techniques, and stating that denominator next to the number (S01).

A practical way to build the denominator:

1. Start from the threat groups and campaigns that target your industry and region, as described in ATT&CK (S06) and your threat intelligence.
2. List the techniques they use, plus the techniques behind recent critical vulnerabilities in software you run.
3. Add techniques your own incident history and red team findings point to.
4. Agree the list with the people who will be judged on it, and version it.

One counting rule avoids a common argument: a technique that sits under two tactics is counted once per tactic, which is the ATT&CK Navigator default (S01). Whatever rule you choose, write it down and keep it stable between reports.

ATT&CK versions change the maths

ATT&CK is not static, and two recent releases change how coverage is calculated. ATT&CK v18 replaced the per-technique data sources with detection strategies, analytics and data components, which gives a cleaner way to connect a technique to the telemetry that reveals it (S01). ATT&CK v19, released on 28 April 2026, split the Defense Evasion tactic into two tactics, Stealth and Defense Impairment (S01, S02).

The practical consequence: a coverage percentage computed before v19 cannot be compared with one computed after it. If your trend line crosses a version change, recompute the earlier points on the new model or mark the break. A jump that comes only from re-mapping is not an improvement in detection.

How to measure it, step by step

You can run this process with spreadsheets and open-source tools, or have it measured for you. The steps are the same.

1. Inventory the rules. Export every detection from the SIEM with its ATT&CK mapping, its enabled state and its schedule. Unmapped custom rules belong in the inventory too; map them or record why they are unmapped.
2. Inventory the data. For every rule, list the log sources and fields it needs. Check that each source is sending, on time, with those fields populated.
3. Place each rule on the funnel. A rule reaches level 3 only if it is enabled and all of its required data is healthy.
4. Validate the rules that matter. For the prioritized techniques, execute the behavior safely, for example with atomic tests such as Atomic Red Team or an emulation framework such as MITRE Caldera, and record whether the rule fired (S01). Run the benign twin as well and record that it stayed silent.
5. Roll up per technique. A technique takes the highest level reached by any of its rules. Report the count of prioritized techniques at each level.
6. Rank the gaps. Order the fixes by how many prioritized techniques each one moves up a level. A missing log source that unblocks ten rules outranks a new rule for one technique.
7. Repeat on change. Re-run the measurement after rule edits, parser or schema changes, SIEM upgrades and ATT&CK releases, because each one can silently move a rule down the funnel.

How to report it

A coverage report that survives scrutiny from an auditor, a regulator or a sceptical board member has a few properties:

• Four numbers, not one. Show the prioritized techniques at each level. The drop from level 1 to level 4 is the most useful number on the page.
• A stated denominator and the ATT&CK version the mapping uses.
• Evidence per validated rule: when it was tested, how, and the alert it produced.
• A dated gap list ranked by impact, with an owner for each item.
• A trend that only moves on evidence. A technique moves up a level when a test shows it, and down a level when a check fails.

This is the shape of the SOCGenX assessment. The free snapshot covers levels 1 to 3 read-only through your SIEM's API, and the full assessment adds validation at level 4. After that, the Proof Loop on the SOCGenX platform keeps checking every agreed log source and detection, so the report you hand over next quarter is measured, not remembered.

This guide describes a measurement method. It is not a statement about any particular organization's coverage, and it quotes no industry-wide coverage figures, because none of the published ones measure validated coverage on a stated denominator.