Coverage Matrix — Turning Emulation Results into a Detection Gap Report

Running emulation tests produces raw data — which tests fired alerts, which didn’t, which had no telemetry. The coverage matrix turns that data into a structured report that tells you exactly where your detection program’s gaps are and which gaps matter most for your specific threat model.

The Three Coverage States

Technique × Detection Outcome

┌─────────────────┬─────────────────────────────────────────────┐
│                 │              Detection State                │
│   Technique     ├───────────┬──────────────┬─────────────────┤
│                 │  Covered  │  Miscovered  │      Gap        │
├─────────────────┼───────────┼──────────────┼─────────────────┤
│ Rule exists?    │    YES    │     YES      │  NO (or untested)│
│ Telemetry?      │    YES    │     YES      │  NO or unknown  │
│ Alert fires?    │    YES    │     NO       │  NO             │
│ What to fix?    │  Nothing  │  Rule logic  │  Telemetry or   │
│                 │           │  or mapping  │  write new rule  │
└─────────────────┴───────────┴──────────────┴─────────────────┘

Critical distinction: Both Miscovered and Gap result in no detection. But:

Miscovered: You have logs. The data is there. The rule is broken. Fix = debug the query.
Gap: Either no logs (deploy Sysmon/agent), or no rule (write one). Fix = data pipeline or authoring.

Treating a Miscovered technique as a Gap leads to wasted effort writing new rules for data that’s already present. Treating a Gap as Miscovered leads to debugging non-existent logs.

Building the Matrix

Step 1: Define the scope

Pick a threat actor or technique set relevant to your organization:

Ransomware (LockBit, BlackCat): focus on T1490, T1486, T1059, T1021
Nation-state (APT29, APT41): use MITRE ATT&CK Navigator group pages
Industry-specific (CISA advisories for your sector)

Or use the full ATT&CK matrix and prioritize by technique frequency (Red Canary Detection Report, Verizon DBIR).

Step 2: Inventory your rules

# If using a detection-as-code repo:
# Extract all ATT&CK technique tags from your Sigma rules
grep -r "attack\.t" rules/ | grep -oP 'attack\.t\d{4}(\.\d{3})?' | sort -u

Map each technique to: rule file(s), status (experimental/test/stable), last modified date.

Step 3: Run emulation tests

For each technique in scope:

Find the Atomic Red Team test: Invoke-AtomicTest T1003.001 -ShowDetails
Run the test: Invoke-AtomicTest T1003.001 -TestNumbers 1
Check raw events (±5 min window)
Check alert (fired Y/N)
Run cleanup: Invoke-AtomicTest T1003.001 -TestNumbers 1 -Cleanup

Step 4: Populate the matrix

| Technique      | Name                      | Rule exists | Telemetry | Alert fired | State       | Priority fix |
|----------------|---------------------------|-------------|-----------|-------------|-------------|-------------|
| T1059.001      | PowerShell Encoded Cmd    | YES         | YES       | YES         | Covered     | —           |
| T1003.001      | LSASS Memory Dump         | YES         | YES       | NO          | Miscovered  | HIGH        |
| T1218.010      | Regsvr32                  | YES         | NO        | NO          | Gap (telem) | HIGH        |
| T1490          | VSS Deletion              | YES         | YES       | YES         | Covered     | —           |
| T1547.001      | Registry Run Key          | NO          | YES       | NO          | Gap (rule)  | MEDIUM      |
| T1055.001      | DLL Injection             | NO          | NO        | NO          | Gap (both)  | LOW*        |

*Low because the technique requires kernel exploit to succeed in a hardened environment.

ATT&CK Navigator Integration

MITRE ATT&CK Navigator (mitre-attack.github.io/attack-navigator/) is a web-based tool for visualizing coverage:

Color coding convention:

Green: Covered (tested, fires)
Yellow: Miscovered (rule exists, doesn’t fire)
Red: Gap (no rule or no telemetry)
Gray: Out of scope / not applicable

// Navigator layer export format (simplified):
{
  "name": "Detection Coverage 2026-Q2",
  "versions": { "attack": "14" },
  "techniques": [
    { "techniqueID": "T1059.001", "color": "#44b678", "comment": "Covered - tested 2026-05-20" },
    { "techniqueID": "T1003.001", "color": "#ffc000", "comment": "Miscovered - GrantedAccess mismatch" },
    { "techniqueID": "T1218.010", "color": "#ff0000", "comment": "Gap - Sysmon not on servers" }
  ]
}

Upload this JSON to Navigator to get a visual heatmap of your coverage. Share it with security leadership to communicate the detection program’s current state.

Prioritizing Gaps

Not all gaps are equal. Score each gap by:

Factor	Weight	Rationale
Technique frequency in threat intel	High	Common techniques are more likely to be used against you
Threat actor relevance	High	Techniques used by actors targeting your sector
Blast radius	High	Detection gap for a technique that enables domain compromise > one that enables one workstation
Pyramid level of existing coverage	Medium	If L1 exists but L3 doesn’t, partial coverage exists
Remediation effort	Medium	Easy wins (deploy Sysmon) → quick coverage gains

Priority score = frequency × relevance × blast_radius / effort

The highest-priority gap is: common technique, used by actors targeting your sector, enables high-impact outcomes, and easy to fix.

The Coverage Report

A coverage report summarizes the matrix for detection leadership and stakeholders:

# Detection Coverage Report — Q2 2026

## Summary
Techniques tested: 47
Covered: 31 (66%)
Miscovered: 8 (17%) — rule exists, doesn't fire
Gap (telemetry): 5 (11%) — no telemetry source
Gap (rule): 3 (6%) — no detection rule

## Top Priority Fixes (this sprint)

### Miscovered — Fix rule logic
| Technique | Issue | Estimated effort |
|-----------|-------|-----------------|
| T1003.001 | GrantedAccess values incomplete | 2h |
| T1059.001 | Missing -ec/-e abbreviations | 1h |

### Gap — Deploy telemetry
| Technique | Missing source | Estimated effort |
|-----------|---------------|-----------------|
| T1218.010 | Sysmon not on servers | 1 day |
| T1546.003 | WMI subscription logging disabled | 4h |

### Gap — Write new rule
| Technique | Next action | Estimated effort |
|-----------|------------|-----------------|
| T1547.001 | Author Sigma rule for registry_set | 3h |

## Threat Actor Coverage
APT29 (Cozy Bear) relevant techniques: 18 tested, 12 Covered, 4 Miscovered, 2 Gap
LockBit relevant techniques: 12 tested, 9 Covered, 2 Miscovered, 1 Gap

ATT&CK Navigator— MITRE Red Canary Threat Detection Report— Red Canary

Retrieval Practice

Your coverage matrix shows T1021.002 (SMB/Windows Admin Shares lateral movement) as 'Covered' — a rule exists and was tested 8 months ago. A new tool appears in a threat report that uses T1021.002 via a different mechanism (direct SMB share mounting rather than PsExec). Should you update the coverage state to Miscovered? What test would give you a definitive answer?

Reveal answer

Don't change the state without testing first — the existing rule may or may not cover the new mechanism. Run the test: find or write an Atomic Red Team test for the specific new mechanism (direct SMB share mount), execute it against your test environment, and check if the alert fires. If the alert fires: state stays Covered, but add a note that coverage was re-validated for this variant. If the alert doesn't fire: update state to Miscovered and add the specific gap to the fix backlog. The coverage matrix state should always reflect tested reality, not theoretical assumptions about what your rules do or don't cover.

Retrieval Practice

A detection program manager says: 'Our coverage went from 60% to 85% this quarter — great progress.' You're skeptical. What question do you ask, and what answer would change your assessment?

Reveal answer

'What percentage of the new coverage was tested by emulation, and what percentage was just rules added to the library?' An increase from 60% to 85% by writing 100 new untested rules is not progress — it's assumption accumulation. The number that matters is detection confidence (tested, fires) not detection coverage (rule exists). A follow-up that changes the assessment: 'All 25 new techniques were validated by emulation within 2 weeks of rule deployment, and 23 of 25 confirmed firing — 2 are in the fix queue for field mapping issues.' That's defensible progress. 'We wrote rules for all the NIST CSF required techniques' is not.