Measuring ATT&CK coverage without fooling yourself

Every detection team gets asked the same question: how much of ATT&CK do we cover? The honest answer takes more than a heat map. Most coverage views count rules with a tag. A tag says a rule claims a technique. It says nothing about whether the rule runs, whether it has data, or whether it would fire.

A tag is a claim, so count claims separately from evidence

Start by naming what you are counting. There are four numbers, and they shrink as you go.

Tagged: rules that carry a technique ID. Enabled: tagged rules that are switched on. Healthy: enabled rules whose last runs succeeded and whose data source is flowing. Tested: healthy rules with a passing test and a replay result. Report all four. The gap between the first and the last is your real exposure.

Sigma shows why this matters. Each Sigma rule carries ATT&CK tags in a tags field, per the rules specification (Sigma specification, read 2026-11-03). Import 3,000 community rules and your tagged count jumps. Your tested count does not move. The Sigma README states more than 3,000 rules in the main repository (SigmaHQ README, read 2026-11-03). That is a library, not a coverage statement.

Each platform's coverage view measures something different

Read the legend before you screenshot.

Microsoft Sentinel's MITRE page shows a recommended coverage ratio of active detections to available templates, and the page is in preview, aligned to ATT&CK v18 (Sentinel MITRE coverage, read 2026-11-04). So the ratio is against Microsoft's own templates, not against the technique list. A full ratio would mean you turned on what Microsoft ships.

Elastic's MITRE ATT&CK coverage page maps rules to techniques and describes identifying gaps through light or empty cells (Elastic ATT&CK coverage, read 2026-11-03). The gap is inferred from shading. Check for yourself whether a disabled rule still colours a cell.

Panther's dashboard marks each technique Covered, Partially Covered or Not Relevant (Panther framework mapping, read 2026-11-03). Not Relevant is a useful state. It lets you remove techniques that do not apply to your estate instead of carrying a permanent gap.

Hunters draws a Threat Coverage map on ATT&CK v14 and shows a gray technique as currently not covered. The docs add that gray cells can reflect missing telemetry as well as missing detectors (Hunters threat coverage, read 2026-11-03). That is the right instinct: a gap can be a data problem.

Sekoia builds a Security Profile matrix from rule tags, with cells coloured by rule count, and leaves gaps to be read from empty cells (Sekoia rules catalog, read 2026-11-03). Colour by rule count rewards quantity. Ten weak rules shade darker than one good one.

Vendor claims about coverage are not coverage

Anvilogic's product page describes Maturity Scoring that measures ATT&CK coverage, highlights gaps and recommends what to build next, with Validated, Deployed and Gap states (Anvilogic detection engineering page, read 2026-11-03). The states are a good model. The page gives no method for what Validated means, so treat it as a vendor claim. Mate Security shows coverage bars by ATT&CK tactic on its platform page (read 2026-11-04), which is tactic level only and also a vendor claim. Mate ranks eleventh of fourteen on the proposed scores, with coverage one of the criteria.

Splunk's research site maps each detection to ATT&CK, and when the pages were read its coverage figures showed placeholder dashes (Splunk research, read 2026-11-04). The gap view is described on a Detection Studio product page, not in reference docs.

Weight techniques by your threat model

An even grid treats every technique the same. Yours are not the same. Pick the 20 to 30 techniques your sector's actors use most, from your own incident history and threat intelligence, and score those first. The number 20 to 30 is a working size, not a standard. The point is a short list you can actually test.

For each technique on the list, write down the data source it needs. A rule for LSASS access needs endpoint telemetry. If that telemetry is missing on 15 percent of hosts, coverage is 85 percent at best, and you can only know that if your coverage view is tied to log source health. Splunk's use case library shows status icons for the sourcetypes and data models each detection search uses, which is one of the few documented links between rules and sources (Splunk use case library, read 2026-11-03).

Go below the technique level

Technique level coverage hides depth. Credential dumping has several sub-techniques and a dozen implementations. One rule for one tool covers a corner. Count sub-techniques where ATT&CK defines them, and for your priority techniques, list the procedures you have tested.

Run an adversary emulation or a purple team test per priority technique once a quarter and record the result next to the rule. A rule that was tested in January and has not run successfully since March is not covered.

How to report it

Give the board one sentence and one table. The sentence says how many of your priority techniques have a tested, healthy detection. The table lists the four numbers per technique: tagged, enabled, healthy, tested. Put the date on it. Coverage is a snapshot, and a snapshot with no date is marketing.

Checklist

• Define covered as tagged, enabled, healthy and tested, and write it down.
• Report the four counts, not one percentage.
• Pick a priority list of techniques from your own threat model.
• Record the data source each priority rule needs and check it is flowing.
• Remove techniques that do not apply, with a reason, instead of leaving a permanent gap.
• Read the legend of each platform's coverage view before quoting it.
• Test priority techniques with emulation at least quarterly.
• Date every coverage report.