Every few months someone on the team pulls up the ATT&CK Navigator heatmap, saturates a few dozen cells in crimson, and slides it into the board deck. The coverage looks solid. The CISO signs off. A quarter later, a tabletop exercise or an actual incident reveals that three of those covered techniques are covered in name only — the rules exist, the telemetry doesn't.
This gap between claimed coverage and observable coverage is one of the most persistent blind spots in enterprise SOC programs. Understanding why it happens requires pulling apart exactly what "coverage" means at each layer of the detection stack.
Coverage Is a Four-Layer Problem
When a detection engineer marks technique T1059.001 (PowerShell execution) as "covered," that claim sits on top of at least four things that can each fail independently:
- Data source availability — Is PowerShell script block logging (Event ID 4104) actually enabled on endpoints? Process creation logging at 4688? Sysmon deployed with the right configuration profile?
- Telemetry ingestion — Is that log source forwarding to your SIEM? If Splunk's forwarder queue depth exceeds its default threshold, events drop silently. No error, no alert, no indication you missed anything.
- Rule logic correctness — Does the Sigma rule or KQL query actually fire on the technique as performed in your environment? Many rules are written against generic examples; the actual adversary variant evades them via encoding, alternate execution paths, or LOLBins.
- Rule activation state — Is the rule enabled, or was it disabled three months ago to stop a 2am false-positive flood and never re-enabled?
Most ATT&CK coverage dashboards only measure layer 3 — rule existence. They don't validate layers 1, 2, or 4. This is why the dashboard lies.
The Silent Data Source Problem
Consider a realistic scenario: a growing financial services firm in the mid-Atlantic region runs Splunk Enterprise with Universal Forwarders deployed across 1,400 Windows endpoints. Their detection engineer has Sigma rules mapped to 73 techniques. But when the team runs an Atomic Red Team exercise for T1003.001 (LSASS Memory dumping via procdump.exe), the detection rule doesn't fire.
The investigation reveals: Windows Defender Credential Guard is active on newer hosts, but the Sysmon deployment template was never updated to capture process access events (Event ID 10) for LSASS. The rule fires correctly in the lab — where Sysmon was configured properly — but not on production hosts where the configuration drifted three patch cycles ago.
This is data source drift. It happens because configuration management for log sources rarely receives the same attention as the detection rules themselves. The SIEM shows "data incoming," but it's the wrong events.
Mapping Data Sources in ATT&CK v14
ATT&CK v14 made this problem more tractable by formalizing data source objects. Each technique now lists specific data sources — not just "process monitoring" but "process: process creation," "process: process access," "network traffic: network connection creation." If your coverage claim doesn't trace back to specific data source components, it's incomplete.
A practical verification approach: for each technique your team claims to cover, build a two-column audit. Left column: the ATT&CK-documented data source components required. Right column: the actual log source enabled, its collection method, and the last time you verified events appear in your SIEM at expected volume. Any right-column cell that's empty or unverified is a gap — regardless of what the heatmap shows.
Rule Decay and the False Positive Loop
Detection rules degrade over time. This is rule decay — not a metaphor, a real engineering problem. An environment changes: new cloud services get onboarded, a new EDR platform is deployed, an application team switches from .NET Framework to .NET 6. Rules written against the old baseline generate noise in the new environment. The alert queue fills with false positives at 3am. Someone disables the rule. It never gets re-enabled.
We're not saying false-positive suppression is wrong — managing alert volume is necessary work. The problem is when the suppression action isn't tracked in a detection-as-code workflow with a ticket, an expiry date, and a re-evaluation reminder. When rule state isn't version-controlled, disabled rules become invisible gaps. Your heatmap still shows the technique as covered.
The detection-as-code discipline addresses this directly: every rule lives in source control (Sigma YAML or vendor-native), every state change is a commit with a reason, and CI/CD pipelines can report on rules that are deployed-but-disabled. Without this infrastructure, rule decay is undetectable from the outside.
ATT&CK Coverage vs. ATT&CK Observability
There's a sharper distinction to make here: coverage means you have a detection rule targeting a technique. Observability means you would actually see the technique if an adversary executed it in your environment today.
Observability requires regular purple-team validation. The Atomic Red Team project (from Red Canary) provides open-source atomic tests for most ATT&CK techniques — small, contained payloads that exercise a specific technique variant and confirm whether your detection fires. Running atomics against production telemetry (in a controlled window) is the only way to close the gap between coverage claims and real observability.
Teams that run quarterly atomic validation cycles consistently find that 20–40% of their claimed covered techniques have some form of data source or rule failure. That's not a criticism of those teams — it's a structural problem with how ATT&CK coverage is measured and reported.
Coverage Gap Analysis: A Practical Framework
For SOC teams that want to build a credible ATT&CK coverage picture, a structured gap analysis has four outputs:
1. Prioritized technique list. Not all techniques matter equally. Use threat intelligence about the adversary groups most likely targeting your industry and geography to weight your coverage priorities. A federal contractor in Northern Virginia prioritizes techniques used by APT groups known to target DoD supply chains. A regional bank prioritizes techniques used in financial fraud and ransomware campaigns. Your ATT&CK Navigator heatmap should reflect real threat prioritization, not just "whatever rules came with the SIEM."
2. Data source inventory. Document which log sources are deployed, which events are actually collected, and at what fidelity. Map each to ATT&CK data source components. Gaps in data source coverage are often cheaper to fix than rule gaps — enabling Sysmon event ID 10 across the fleet is an infrastructure change, not a detection engineering problem.
3. Rule validation results. Run atomic tests or custom adversary simulations quarterly. Log the results: fired/did-not-fire, and why. This creates an audit trail that lets you distinguish "we chose not to cover this" from "we thought we covered this but don't."
4. Residual gap acceptance. Some gaps are intentional. Some techniques are covered by compensating controls rather than detections. Document the rationale. A CISO presenting to the board should be able to say "we have a documented gap in T1134 (Access Token Manipulation) because our privileged access management controls make that technique impractical in our environment, and we validated that assumption in our last red team exercise." That's a defensible position. An undocumented gap that surfaces in an incident is not.
What Your Dashboard Should Actually Show
The Navigator heatmap is a useful communication tool, but it shouldn't be the source of truth for coverage state. A more honest coverage dashboard has three layers of color:
- Validated coverage — technique has a rule, data source confirmed active, atomic test passed in the last 90 days
- Claimed coverage — rule exists, data source assumed active, no recent validation
- Gap — no rule, or rule disabled, or data source known to be missing
Most SOC teams, if they were honest with themselves, would see their heatmap shift from mostly-covered to a mixed picture of validated, claimed, and gap. That mixed picture is more useful than a falsely confident red grid, because it drives the right conversations about where to invest next in detection engineering.
The board wants to see the heatmap turn red. The adversary doesn't care about the heatmap. Building observable detection coverage — not just claimed coverage — is the work that actually reduces dwell time when it matters.