Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
A MITRE ATT&CK detection coverage map is a structured inventory that answers one question for every technique and sub-technique in the framework: if an adversary did this in our environment today, would we generate a detection? It is built by cross-referencing the ATT&CK Enterprise matrix against your actual telemetry (what log sources exist and are ingested), your actual detection content (which Sigma rules, SIEM correlation searches, or EDR analytics exist and are enabled), and validation evidence (whether those rules have ever actually fired against a real or simulated event). The output is usually visualized as an ATT&CK Navigator heat-map layer, but the real value is the underlying spreadsheet or JSON that a detection engineering team uses to plan work.
Coverage mapping matters because detection engineering budgets and analyst attention are finite, while ATT&CK Enterprise now documents on the order of 600+ techniques and sub-techniques. Without a map, teams tend to over-invest in whatever generated the last incident and under-invest in adjacent, equally-likely techniques. A coverage map turns “we have good detection” into a falsifiable, technique-by-technique claim, lets a CISO show a board which tactics are weakest, and gives detection engineers a prioritized backlog instead of an ad-hoc one.
Attack Prerequisites
Building a credible coverage map requires several inputs to already exist; without them the exercise produces a map of wishful thinking rather than reality:
- An up-to-date ATT&CK dataset — the STIX bundle or ATT&CK Navigator layer file for the current Enterprise matrix version, since technique IDs and sub-techniques are revised release to release.
- A telemetry inventory — a list of every log source actually flowing into the SIEM/EDR (Sysmon, Security log, EDR process/network events, DNS, proxy, cloud audit logs) and its retention, not just what is theoretically collectible.
- A rule/analytic inventory — every detection rule, correlation search, or vendor-built analytic, ideally already tagged with the ATT&CK technique ID it targets (most Sigma rules carry
tags: [attack.credential_access, attack.t1558.003]). - Validation evidence — atomic test results (e.g. Atomic Red Team runs) or purple-team findings showing a rule actually fired, not just that it exists.
- Threat-informed priorities — group/software profiles from ATT&CK relevant to your sector, so gaps are weighted by adversary relevance rather than treated uniformly.
How It Works
ATT&CK Enterprise is organized as tactics (the adversary’s objective, e.g. Credential Access) containing techniques and sub-techniques (the specific method, e.g. T1558.003 Kerberoasting). Since ATT&CK v10, MITRE also publishes data sources and data components as first-class objects — for example T1558.003 lists data components such as “Logon Session Creation” and “Active Directory Object Access” that indicate which log types could theoretically expose the technique. A coverage map scores each technique against three independent axes: is the underlying data source *collected*, does a *detection analytic* exist for it, and has that analytic been *validated*. Conflating these three — a common mistake — produces false confidence: log availability is not detection, and an untested rule is not a validated one.
The Navigator layer JSON format is the de facto interchange format for coverage maps: a techniques array of objects each carrying a techniqueID, a numeric score (used to drive a color gradient), a color, and a free-text comment. Because it is just JSON, it is trivial to generate programmatically from a rule repository’s ATT&CK tags and diff between two points in time to show progress. The open-source DeTT&CT framework (originally built by Rabobank’s CSIRT / the Dutch financial sector) formalizes this scoring with explicit visibility and detection quality scales and ships CLI tooling (dettect.py) to generate Navigator layers directly from YAML data-source and technique-administration files.
MITRE’s own CAR (Cyber Analytics Repository) and the ATT&CK Evaluations program (adversary emulations of APT29, APT3, Wizard Spider/Sandworm, and others) are useful inputs at this stage too: CAR provides pseudo-code analytics per technique that can seed your rule inventory, and the Evaluations’ emulation plans show which specific procedures (not just techniques) real detection content needs to catch.
Practical Example / Configuration
A minimal coverage-map row set, exported as a flat table before being turned into a Navigator layer. Each row ties a technique to the data source that would expose it, the internal rule ID that claims to detect it, and a coverage status:
tactic,technique_id,technique,data_source,rule_id,status,last_validated
Credential Access,T1558.003,Kerberoasting,"Sysmon 1 / Security 4769",SIG-4769-RC4,covered,2026-06-02
Credential Access,T1558.004,AS-REP Roasting,Security 4768,SIG-4768-NOPREAUTH,covered,2026-06-02
Credential Access,T1110.003,Password Spraying,Security 4625,SIG-4625-SPRAY,covered,2026-04-11
Lateral Movement,T1021.002,SMB/Admin Shares,"Security 5140/5145, Sysmon 3",SIG-PSEXEC-SVC,partial,2025-11-20
Lateral Movement,T1021.006,WinRM,"Sysmon 1 (wsmprovhost)",-,none,-
Execution,T1047,WMI,"Sysmon 1 (WmiPrvSE)",SIG-WMIEXEC,covered,2026-01-15
Defense Evasion,T1027,Obfuscated Files,EDR static/behavioral,-,none,-
The corresponding ATT&CK Navigator layer snippet that renders this as a heat map (green = covered, yellow = partial, red = none):
{
"name": "Q3-2026 Detection Coverage",
"versions": {"attack": "15", "navigator": "5.1.0", "layer": "4.5"},
"domain": "enterprise-attack",
"description": "Generated from rule repo ATT&CK tags",
"techniques": [
{"techniqueID": "T1558.003", "score": 100, "color": "#4caf50",
"comment": "SIG-4769-RC4, validated 2026-06-02"},
{"techniqueID": "T1021.006", "score": 0, "color": "#f44336",
"comment": "No rule; WinRM logon events not yet parsed"}
],
"gradient": {"colors": ["#f44336", "#ffeb3b", "#4caf50"],
"minValue": 0, "maxValue": 100}
}
Walkthrough / Exploitation
Building the map end to end, from a cold start:
# 1. Pull the current ATT&CK STIX bundle and DeTT&CT skeleton files
git clone https://github.com/rabobank-cdc/DeTTECT.git
cd DeTTECT && pip install -r requirements.txt
# 2. Populate data-source administration (what you actually collect)
python dettect.py editor # opens the YAML editor UI for data sources
# 3. Grep your Sigma rule repo for ATT&CK tags to seed technique coverage
grep -rhoE 'attack\.t[0-9]{4}(\.[0-9]{3})?' sigma-rules/ | sort -u
# 4. Generate a visibility layer from data sources, then a detection layer
python dettect.py generic -f data_sources.yaml -o visibility_layer.json
python dettect.py generic -f techniques.yaml -l visibility_layer.json \
-o detection_layer.json
# 5. Load both layers into Navigator, overlay a threat-actor layer
# (e.g. the FIN7 or APT29 group page's technique list) to prioritize gaps
Treat step 3 as the recurring, automatable part: every new Sigma rule merged into the repository should carry tags: with its technique ID, and a CI job can regenerate the Navigator layer on every merge so the map never drifts from what is actually deployed.
Note: A green cell means “a rule targeting this technique is enabled,” not “we will catch every procedure of this technique.” ATT&CK techniques are broad; a single Sigma rule for one Kerberoasting variant does not cover every possible encryption-downgrade or ticket-request pattern. Track coverage at the *analytic* level internally even if you report at the *technique* level externally.
Opsec: Coverage maps are sensitive documents — they are a precise list of where an attacker who obtained them would go first. Restrict distribution and never publish a live map externally; publish only high-level tactic rollups if sharing with the board or auditors.
Detection and Defense
A coverage map is itself a defensive control insofar as it drives what gets built next. Operationalize it with:
- Mandatory ATT&CK tags on every rule — enforce via CI lint (
sigma checkplus a custom rule requiring atags:field matchingattack.t\d{4}). - Scheduled atomic validation — run Atomic Red Team tests mapped to each “covered” technique on a recurring cadence and flip status to “stale” if a rule hasn’t fired in N days.
- Threat-intel overlay — recompute priority using ATT&CK group/software pages relevant to your industry rather than treating all 600+ techniques as equally likely.
- Coverage as a KPI — track percentage “covered and validated” per tactic over time; a shrinking red band in Credential Access and Lateral Movement is a concrete, board-reportable metric.
Real-World Impact
ATT&CK-based coverage mapping is now standard practice across mature SOCs and MSSPs; DeTT&CT is publicly maintained and used by financial-sector CSIRTs to report visibility and detection maturity to regulators. MITRE Engenuity’s ATT&CK Evaluations (rounds emulating APT29, APT3, Wizard Spider/Sandworm, Turla, and others) are widely used by vendors and buyers precisely because they expose technique-level detection gaps that generic marketing claims hide, and many enterprise security teams re-run those same emulation plans internally to validate their own coverage maps rather than trusting vendor results alone.
Conclusion
A detection coverage map converts a vague sense of “we’re probably fine” into a technique-by-technique, evidence-backed inventory that can be diffed, prioritized, and reported. The mechanics are simple — tag rules with ATT&CK IDs, track what telemetry actually exists, validate rather than assume — but the discipline of keeping the map current, tied to real rule and log inventories rather than a one-time slide, is what separates teams that actually close detection gaps from teams that produce a pretty heat map once a year.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments