Ask most security leaders how good their SOC's detection coverage is and they will point to their SIEM. It's active, it's generating alerts, the dashboards are green. What they rarely have is an answer to a more precise question: which MITRE ATT&CK techniques do we actually have behavioral detection for — not rules that could theoretically fire, but techniques we have validated against real adversarial behavior? In our experience, the gap between assumed coverage and actual coverage is rarely small. It is usually alarming.
Why "We Have a SIEM" Is Not an Answer
A SIEM is a log aggregation and correlation platform. Having one means you have telemetry. It does not mean you have detection coverage. A SIEM with 500 correlation rules, none of which map to the lateral movement techniques your adversary actually uses, provides zero detection value for that adversary's campaign.
The MITRE ATT&CK framework catalogs 14 tactic categories and over 600 individual techniques and sub-techniques observed in real intrusion campaigns. The average enterprise SIEM has meaningful behavioral detection for somewhere between 40 and 80 of those techniques — roughly 10 to 15 percent of the matrix. The rest? Unknown. Alert rules may exist, but without validation testing, you cannot know if they detect the actual adversarial behavior they claim to cover, or just similar-looking benign activity.
This is not a vendor problem. It is a calibration problem. Detection engineering is continuous, not a one-time deployment task.
The Coverage Measurement Framework
Measuring ATT&CK coverage is a three-step process: inventory, validate, prioritize. Skipping any step produces a coverage map that is technically complete but operationally misleading.
Step 1 — Inventory your current detections
Map every active detection rule in your SIEM and EDR to ATT&CK technique IDs. This includes correlation rules, behavioral analytics, and EDR machine-learning detections. Be specific: a rule labeled "credential dumping" should map to T1003 (OS Credential Dumping) and its sub-techniques (T1003.001 LSASS Memory, T1003.003 NTDS, etc.) individually. Lumping techniques together obscures which sub-techniques you actually cover.
Use the ATT&CK Navigator to visualize this. Color your matrix by coverage status: green for validated detection, yellow for a rule exists but is not validated, red for no detection. Most teams doing this exercise for the first time end up with substantially more red and yellow than they expected.
Step 2 — Validate with adversary simulation
A rule that exists is not a detection that works. Validation requires executing the technique — safely, in a controlled environment — and confirming the rule fires, generates a useful alert, and does not produce excessive false positives in your environment. This is adversary simulation, also called purple team exercise.
You do not need to simulate every technique to make progress. Prioritize by threat actor relevance. If your primary threat is financially motivated ransomware groups, focus validation on initial access, credential access, lateral movement, and impact techniques. If your threat model includes nation-state APTs, add collection, command-and-control, and persistence techniques used by those groups.
Automated validation tools can run hundreds of technique simulations in a day. The output is not just a coverage map — it is a list of confirmed gaps with technique IDs, ready to feed back into detection engineering.
Step 3 — Prioritize by threat actor TTP overlap
Not all gaps are equal. A gap in T1055 (Process Injection) sub-techniques is more urgent than a gap in obscure cloud-specific techniques if your environment is primarily on-premises Windows. Coverage gaps that overlap with techniques used by adversaries targeting your industry and region should be addressed first.
MITRE publishes group profiles showing which techniques each tracked adversary group has used. Cross-reference your coverage gaps against the technique set of adversaries known to target your industry vertical. That intersection is your priority backlog for detection engineering work.
The Tactic Coverage Distribution Problem
Most enterprise SOCs have uneven coverage across ATT&CK tactic categories. The distribution we see most often looks like this:
| ATT&CK Tactic | Typical Coverage Level | Why the Gap Exists |
|---|---|---|
| Initial Access | Moderate (email security, web proxy) | Covered by perimeter tools, not SOC detections |
| Execution | High (process creation rules) | EDR telemetry is rich; rules are well-documented |
| Persistence | Low-Moderate | Many sub-techniques; rules age out as TTPs evolve |
| Privilege Escalation | Moderate | Some coverage via identity tools; EDR gaps common |
| Defense Evasion | Low | Techniques are specifically designed to avoid detection |
| Credential Access | Moderate | LSASS rules common; Kerberoasting and DCSync gaps frequent |
| Lateral Movement | Low | Living-off-the-land techniques blend with legitimate admin activity |
| Collection / Exfiltration | Very Low | Volume-based rules miss slow exfiltration; DLP is separate tool |
Defense Evasion and Lateral Movement are consistently under-covered, yet they represent the middle of the kill chain where adversary dwell time accumulates. Initial Access and Execution get the most engineering attention because those are where alerts are most obvious. That imbalance is exactly what sophisticated threat actors exploit.
Coverage Debt: When Detections Go Stale
Detection rules degrade. Adversaries update their TTPs. A rule written to detect Mimikatz invocation patterns in 2022 may not detect the 2024 variants that have been updated to avoid those signatures. Detection engineering is maintenance work, not just development work, and most SOC teams do not have a systematic process for retiring or refreshing stale detections.
We recommend running a coverage audit at minimum quarterly — shorter cycle times for high-velocity threat actor groups. Each audit compares current rule set against the latest ATT&CK version and any newly published adversary group profiles relevant to your threat model. Techniques that have evolved since your last validation cycle should be re-validated.
Track coverage debt the same way software teams track technical debt: as a backlog item with priority, owner, and target completion date. Unacknowledged coverage debt is the mechanism by which dwell time silently increases without any observable change in your alert dashboard.
Behavioral Detection vs. Signature Detection
A critical distinction in coverage measurement: signature-based detections and behavioral detections are not equivalent coverage. A signature that matches a known malware hash provides zero coverage against the same malware recompiled to change its hash — a trivial operation for any adversary. Behavioral detections that identify the technique (e.g., credential dumping via LSASS memory access with specific handle types) provide coverage regardless of which tool executes it.
When mapping your coverage, mark signature-based detections separately from behavioral detections. A technique covered only by signatures should be treated as partially covered, not fully covered. Signature coverage is fragile; behavioral coverage is durable.
The goal is not 100% ATT&CK technique coverage — it is prioritized, validated coverage of the techniques your adversaries actually use, with behavioral detection that survives tool variation.
Putting It Together: A 90-Day Coverage Improvement Plan
- Days 1-30: Run ATT&CK Navigator inventory. Map all current detections to technique IDs. Produce your baseline coverage heatmap.
- Days 31-60: Select the top 20 highest-priority gap techniques (based on adversary TTP overlap with your threat model). Run adversary simulation for each. Document confirmed gaps vs. false-negative gaps.
- Days 61-90: Develop behavioral detection rules for the top 10 confirmed gaps. Validate each rule before deploying to production. Update coverage heatmap.
After 90 days, you will have a validated, quantified baseline — and a repeating process you can run every quarter. That is the foundation of a coverage program. It is not exciting. It is the work that determines whether your SOC can detect real adversaries or just generate alerts about benign events.
Coverage measurement is a practice, not a project. The teams that consistently catch adversaries early have not deployed better tools — they have built a discipline of continuous coverage validation that keeps their detection model calibrated to current adversary behavior. That discipline is what the framework is for.
