Mapping Sigma Rules to MITRE ATT&CK Coverage Gaps

A shaded ATT&CK cell proves only that a rule carries a tag, not that it will detect the mapped behavior in production. The gap between a tagged rule and a tested detection is the core problem with how most teams report MITRE ATT&CK coverage.

Security teams run into this when a coverage heatmap looks authoritative but doesn't say whether a rule fires, how many procedures it catches, or how cheaply an attacker evades it, which is exactly the gap that matters to anyone deciding how much to trust a vendor's reported coverage or their own program's numbers.

This article covers where ATT&CK coverage gaps come from, what a tagged Sigma rule can and can't prove on its own, and what to test before trusting a provider's or your own detection heatmap.

TL;DR:

• Some coverage grids count a technique as soon as one eligible rule is mapped to it. CardinalOps, KYRA MDR and Elastic's coverage page all use some form of this mapping-coverage approach, and none of them says anything about whether the rule fires, how many procedures it sees, or how cheaply an attacker evades it.
• v18, v19 and v20 have each moved the mapping target. Detection Strategies and platform-specific Analytics replaced per-technique detections, the v19 Defense Evasion split left remapping debt in Sigma libraries and vendor UIs that many haven't caught up on, and v20 (current since October 13, 2026) adds still more techniques, Detection Strategies and Analytics on top of that.
• Many coverage gaps come from broken plumbing, separate from missing rules entirely. Most techniques still have no rule at all, but vendor research attributes broken rules to misconfigured sources, missing fields, parsing errors and dropped logs, which a tag-built heatmap cannot show.
• Firing evidence has to be attributable to the intended behavior. A rule that passed review but was never run against the behavior it claims to catch, in the production pipeline, is a hypothesis, and a rule that fired without matching that behavior proves as little. The same standard applies to a provider's coverage heatmap.

The practical test is whether each cell connects to telemetry, a production rule, firing evidence and an investigation outcome. Mapping coverage, telemetry readiness, implementation coverage, correlated test results and operational outcomes are not the same thing, and neither a tag nor one successful test proves all of them.

Coverage heatmaps count tags, not detections

The coverage views from CardinalOps, KYRA MDR and Elastic all count a technique once at least one eligible rule is mapped to it. Mapping coverage is a count of tags, a different thing from proof of detection. CardinalOps defines coverage as the presence of at least one SIEM detection rule mapped to a MITRE ATT&CK technique.

KYRA MDR builds its detection rules on the MITRE ATT&CK framework, though its public documentation doesn't detail a specific coverage-percentage metric. Elastic's coverage cells darken "when a technique has more rules matching the current filters." One widely cited coverage critique objected that checking off a technique "is no indication of your ability to detect an adversary leveraging that technique."

The research inherits that definition. CardinalOps' research is vendor research from a company that sells detection posture management; it found enterprise SIEMs cover roughly 21% of ATT&CK techniques, with about 13% of existing detection rules non-functional due to issues like misconfigured data sources and missing log fields.

The academic baseline also shows substantial gaps: Virkud et al. at USENIX Security 2024 audited ATT&CK-tagged detection rulesets from Carbon Black, Splunk and Elastic and found that technique coverage drops by roughly half once low- and medium-severity rules are filtered out. The paper's broader point is that technique coverage does not show how many procedure-level threats a ruleset can detect, since individual rules operate at the procedure level, not the technique level.

Taken together, those findings suggest the low production figures partly reflect techniques that are not practically detectable as a rule at all. Red Canary, now part of Zscaler MDR, says it plainly: "Not everything in the ATT&CK matrix lends itself to detection or testability."

Jared Atkinson's capability abstraction work at SpecterOps shows Invoke-Kerberoast and Rubeus's kerberoast module sharing a layer that relies on a KerberosRequestorSecurityToken constructor overload. A rule keyed to one tool's artifacts, tagged Kerberoasting, turns the cell green without seeing the other tool.

CTID's Summiting the Pyramid project exists to measure the depth and quality of detection coverage beyond a simple ATT&CK heatmap, on the premise that many detection analytics are fragile against low-cost adversary evasion. A technique-tagged cell does not show how resistant the underlying rule is to that kind of evasion.

CTID followed with new material in September 2026 that introduces implementation coverage and detection quality as the measures that matter. Its calculator assesses analytic logic, implementation catalogs and telemetry mappings; it does not run production firing tests. Treat it as a shift in emphasis beyond simple tag presence, though CTID doesn't frame it as a formal replacement for any official MITRE coverage policy.

Sigma tagging and the remapping debt from v18 and v19

Sigma's ATT&CK mapping is a convention-based tag string, and that design is why libraries drift. The tags field is optional, namespaced with a dot, and lower-case: attack.t1234 for techniques plus tactic names such as command-and-control.

Third-party material still mixes v2's attack.defense-evasion with the older attack.defense_evasion, a drift that matters at scale: the SigmaHQ README listed more than 3,000 detection rules at the r2026-07-01 release.

ATT&CK v18 replaced per-technique detections with Detection Strategies that point to platform-specific Analytics. Each Analytic carries a Log Source such as "wineventlog:security" and Mutable Elements for thresholds.

ATT&CK also deprecated Data Sources, so pipelines built on the old STIX (Structured Threat Information Expression) data-component relationships will break, and the restructuring kept expanding from there: by v19, Enterprise carried 697 Detection Strategies and 1,758 Analytics against 222 techniques.

MITRE's v19 release notes link transition guidance plus a human-readable and a machine-readable changelog for identifying affected mappings; some practitioners also recommend mapping to both the Technique ID and the Detection Strategy as an added safeguard.

v19, released April 28, 2026, created the more immediate mess. Defense Evasion was split into Stealth and Defense Impairment, two Detection Strategies for Impair Defenses were deprecated, and Elastic's migration docs say custom rules now offer only v19 tactics and techniques. Ad hoc migration audits have turned up rules that still use the retired attack.defense-evasion tag; SigmaHQ itself has not published an official count of how widespread that is. A deprecated tag is a metadata change. It can distort what a heatmap reports without ever touching whether the underlying rule still works.

Conversion adds a second failure layer on top of tagging. pySigma's Splunk Data Model pipeline fails category="proxy" rules whose fields fall outside the Common Information Model (CIM) mapping, and Datadog's pySigma backend maps fields automatically only for its supported cloud-provider pipelines (AWS CloudTrail, Google Cloud, Azure); everything else falls back to @-prefixed field names that still need manual mapping and validation. Treat a bulk import as a draft that still needs validation before it reaches production.

Where coverage gaps actually come from

Missing rules remain one source of coverage gaps. Other gaps come from rules that exist, carry the right tag, and stop firing because the pipeline underneath them changed.

Broken rules in production

CardinalOps attributes broken production rules to "misconfigured data sources, missing fields, and parsing errors." The rule stays tagged and visible in the heatmap even when its query no longer receives the fields it expects. A tag-count heatmap would still count it as coverage.

Telemetry that never reaches the rule

Telemetry can exist at the source and still never reach the rule meant to evaluate it. Picus, which simulates attacks against customer controls, documents two recurring failure paths in its Blue Report 2026: rules that run too slowly or noisily, and log-collection problems, including Improper Log Source Coalescing, that compress or drop events before any rule sees them.

Picus and CardinalOps both sell remediation, so their research should not stand alone as proof. The useful part is the documented mechanism: telemetry can exist at the source yet disappear through collection, parsing, coalescing or rule-execution failures before the detection pipeline evaluates it.

Visibility is not detection

DeTT&CT separates data-source administration from technique assessments, and scores visibility and detection independently within that technique-administration file. Recon InfoSec's warning holds: data-source mapping shows what could theoretically be detected, which says little about your actual detection capability. CTID's case study of 144 Sigma analytics on Windows Security log sources found a gap was "not exclusively a Sigma problem, a mapping problem, an analytic problem, or a telemetry problem" but a relationship problem between them.

What actually gets tested

An untested rule is a hypothesis, and a single passing test barely upgrades it. Atkinson's May 2024 post, "Why a Single Test Case is Insufficient," argues that a single passing test is close to meaningless, and that real confidence comes only from testing the same procedure through several different modalities. His companion point treats PowerShell as an execution modality, a framing that is the clearest statement of why a technique tag cannot carry test evidence.

Atomic tests and regression

Atomic Red Team tests are single procedures, which is their strength and their limitation. SCYTHE's regression model goes further: it pairs each rule with a known-good simulation, runs it against the production SIEM, checks firing, and keys the result by technique ID, test identifier and Sigma rule name. SCYTHE reports rules that failed in purple team engagements despite passing review, with telemetry present but logic that no longer matched.

A rule can also break after a routine log-source update, or after tuning scopes out the real attack path it was meant to catch. For detection-as-code, Elastic's detection-rules repo runs unit tests and schema validation, which check the rule's logic without confirming it fires; Splunk's Attack Range can generate attack data with Atomic Red Team once you configure the scenarios.

What MITRE's managed services evaluations test

Managed services Round 2 (released June 18, 2024) emulated menuPass and ALPHV/BlackCat across 11 providers. Per Sophos, a participant, the emulation ran 172 adversary sub-steps across 15 steps, of which only 43 deemed critical appear in results, and "The evaluation focused entirely on detection and reporting."

MITRE applies the same non-ranking policy across its evaluations program generally. Its December 2025 announcement for a separate Enterprise evaluation states that "The evaluations do not rank vendors." Participation in a managed services round tells you about reporting under a controlled emulation; it says nothing about response, remediation or noise in your environment.

Provider heatmaps

Zscaler MDR, formerly Red Canary, maintains an ATT&CK coverage heatmap built from custom detectors and third-party alerts mapped to ATT&CK. Relayed third-party alerts still carry value, since they extend coverage to tools a provider does not instrument directly.

For any provider, ask which detections in the heatmap are provider-written on raw telemetry versus relayed alerts, and what evidence shows they fire. SOC Prime's federal mapping lists firing proof and change history among the evidence artifacts it expects.

How to decide where to spend the next quarter on ATT&CK coverage

• Record your actual baseline. Record the ATT&CK version your platform supports, compare your mappings against the current v20 release and the relevant prior changelogs, and update stale mappings alongside risk-prioritized detection work. v18's Detection Strategies move and its deprecated Data Source relationships, plus v19's retired attack.defense-evasion tags, are the two changelogs most likely to have left mappings behind.
• Change what you report. If you report a technique percentage upward, add validation and telemetry status as first-class fields, pair them with case outcomes and alert noise, and show the trend rather than the total. Netwitness' advice to map only what you can prove is the right floor.
• Build production regression before adding more tooling. If you have no regression loop, use SCYTHE-style rule-to-simulation pairing before buying a breach-and-attack-simulation (BAS) platform: that pairing is what catches the review-passed, production-failing rules described above.
• Prioritize depth over matrix breadth. If you can test only a few techniques deeply, pick procedures with multiple modalities and test each one several ways, per Atkinson, instead of spreading single atomics across the matrix. Spreading test effort equally across every technique tends to produce shallow controls and a false sense of confidence.
• Evaluate the operating model behind the heatmap. If you are evaluating an MDR, ask which cells initiate investigations from provider-written rules on raw logs versus relayed alerts. Confirm that the provider owns investigation of the agreed-upon alerts through a clear verdict without shifting the work back to your team, and require firing history for rules it runs on your behalf. Of these four, remapping and regression likely pay back fastest, since they correct numbers you already report and expose rules that fail in the production path.

Why detection coverage is leaving the black box

Coverage is moving from a static tag count to operational data, under pressure from three directions. ATT&CK v18 made detection content platform-specific and tunable through Analytics and Mutable Elements. CTID's 2026 work reframes "covered" around implementation coverage and detection quality. And detection-as-code puts rules under version control with test results attached.

Once those three converge, the useful question about a rule becomes whether it fired, on what, with what outcome, and whether it overlaps with something else. The shift is from a Black Box coverage claim to a Glass Box model in which buyers can inspect firing history, case outcomes, noise and overlap.

Security operations use three operating models. Traditional MDR relies primarily on deterministic detections and provider-run investigation. In human-heavy operations, investigation quality may vary with staffing, including the assignment of junior analysts to night shifts. AI SOC tools automate work on alerts generated by other tools; customers operate the tool and retain responsibility for outcomes. AI-native MDR combines an AI-native platform for agentic investigation and response with contractual accountability. In each model, a heatmap is useful only when the operator can connect its cells to firing history and investigation outcomes.

Daylight is a MASS company, meaning it offers managed agentic security services for Security Operations. Its Detection Program Visibility feature reflects that same emphasis in its own MDR service: it maps detections to ATT&CK and adds operational context on top of that mapping, including alert volume, case outcomes, verdict statistics, overlap and coverage gaps.

Frequently asked questions about ATT&CK coverage and Sigma rules

What should I ask a vendor whose heatmap shows high ATT&CK coverage?

Ask for the evidence behind the number, not the number itself: how many of those cells have firing history from the last quarter, how many have a verified case outcome attached, and how the vendor defines "covered" in the first place. A vendor that cannot produce that evidence for its own heatmap cannot vouch for yours either.

How do Sigma rules map to MITRE ATT&CK techniques?

Sigma rules carry the mapping as an optional, convention-based tag string in the rule's metadata, such as attack.t1234 for a technique plus a lower-case tactic name. Because the convention isn't enforced, libraries drift: older rules can carry retired tactic names, and a rule written against one ATT&CK version may not reflect a later version's restructuring.

How often should detection coverage be retested?

At minimum, after every ATT&CK version update that touches a tactic or technique your rules reference, and after any change to the log sources, parsers, or SIEM pipeline those rules depend on. A rule that fired correctly six months ago can go silent after a parsing change with no change to the rule itself, so a one-time test at deployment doesn't hold.

What's the difference between visibility and detection in ATT&CK terms?

Visibility means the telemetry needed to spot a technique reaches your pipeline at all. Detection means a rule evaluates that telemetry and fires correctly. A technique can have full visibility and still have no working detection, and a tagged rule can exist with no visibility behind it; tracking the two separately is how frameworks like DeTT&CT avoid conflating them.

‍