Building a MITRE ATT&CK Detection Coverage Map Your Team Can Act On

ATT&CK coverage maps overstate detection capability for four reasons.

Binary coverage representation. Mapping a technique as covered or not covered collapses the difference between a tuned, high-fidelity detection that fires on real activity and a broad rule that fires on everything. Both show as "covered." The binary representation makes 50 high-fidelity detections look the same as 200 noisy rules -- and leads teams to believe they have better coverage than they do.

No data source quality assessment. Many teams mark a technique as covered if any data source for that technique is available, even if no detection rule exists that uses that data source. If Windows Sysmon is deployed, then process creation events are available -- but "data source present" is not the same as "we detect malicious process creation." The technique may be theoretically detectable from the available data, but if there is no rule that detects it, the technique is not detected.

No maintenance process. A coverage map built in January reflects January's detections. Rules are added, modified, broken, and removed throughout the year. Without a maintenance process, the coverage map drifts from the actual detection state within weeks.

Technique coverage vs. sub-technique coverage. ATT&CK has both techniques (T1078, Valid Accounts) and sub-techniques (T1078.001, Default Accounts; T1078.002, Domain Accounts; T1078.003, Cloud Accounts). Claiming technique-level coverage when you only have sub-technique coverage for one of four sub-techniques significantly overstates the actual detection depth.

Replace binary covered/not covered with a three-level quality scale that reflects the actual state of detection for each technique.

Level 1: Data source present, no detection rule. The log source that would enable detection of this technique is available and ingested into the SIEM, but no rule exists that uses this data source to detect the technique. Example: Windows Security Event Log 4688 (process creation) is ingested, which could detect T1059.001 (PowerShell execution), but no PowerShell-specific detection rule exists. This is potential coverage, not actual coverage. Color in ATT&CK Navigator: light yellow.

Level 2: Behavioral detection, not tuned. A detection rule exists for this technique, but the rule has not been tuned against the actual environment. False positive rate is not documented. The rule may fire frequently on benign activity, requiring analyst triage that degrades the signal-to-noise ratio. Example: a rule that alerts on any PowerShell execution with encoded arguments -- technically detects a T1059.001 sub-technique, but fires on legitimate management scripts at a rate that overwhelms the alert queue. Color: orange.

Level 3: High-fidelity detection, tuned. A detection rule exists, has been tuned against the environment (exclusions for known-good activity, threshold adjustments), has a documented false positive rate below 10%, and has a runbook that enables consistent analyst triage. Example: a rule that alerts on PowerShell encoded commands where the parent process is not a known management tool and the encoded payload contains download-related keywords -- fires infrequently and with high precision. Color: green.

Use this three-level scale when building or updating the coverage map. The resulting heatmap accurately reflects detection quality, not just detection presence, and reveals where investment in tuning existing detections produces more value than adding new detections.

Build the coverage map bottom-up, starting from what data you actually have, rather than top-down from the technique list.

Step 1: Inventory data sources. Document every log source ingested into the SIEM: Windows Event Log, Sysmon, network flow, DNS logs, proxy logs, cloud trail logs, endpoint telemetry (EDR), identity logs. For each data source, record: what systems generate it, what percentage of the environment is covered, and how far back data is retained.

Step 2: Map data sources to ATT&CK data source objects. MITRE ATT&CK provides a data source taxonomy (Process, Network Traffic, File, Registry, etc.) with component-level detail. Map your data sources to the ATT&CK data source objects: Windows Security Event Log 4688 maps to "Process: Process Creation." Sysmon Event ID 3 maps to "Network Traffic: Network Connection Creation." This mapping reveals which ATT&CK data sources you have coverage for.

Step 3: Identify techniques covered by each data source. Each ATT&CK technique lists which data sources can be used to detect it. From your data source inventory, determine which techniques are theoretically detectable (Level 1). This produces the "potential coverage" layer.

Step 4: Map existing detection rules to techniques. For each existing detection rule, identify which ATT&CK technique it addresses. Rules frequently address a specific sub-technique or a specific instantiation of a technique. Document whether the rule is tuned (Level 3) or not yet tuned (Level 2).

Step 5: Build the navigator layer. In ATT&CK Navigator or DeTT&CT, assign each technique a score based on the quality level: 1 for data source only, 2 for behavioral detection, 3 for tuned detection. Generate the heatmap. The resulting visualization accurately reflects actual detection state.

A coverage gap in a technique that no relevant threat actor uses is lower priority than a gap in a technique that actors targeting your industry use in most campaigns. Threat profile alignment makes the coverage gap prioritization list actionable rather than exhaustive.

Define your threat profile. Identify the threat actor groups most likely to target your organization. MITRE ATT&CK provides actor profiles (Groups) with the techniques each group has been observed using. Use sources including: your industry ISAC threat intelligence, vendor threat reports focused on your sector, and historical incident data if available.

Filter ATT&CK to your threat profile. In ATT&CK Navigator, use the layer comparison feature to overlay your coverage heatmap against the techniques used by your relevant threat actor groups. The intersection of "technique used by relevant threat actors" and "Level 1 or not covered" is your highest-priority gap list.

Prioritize within the gap list. Not all high-priority gaps are equally addressable. Rank by:

1. Techniques used by multiple threat actor groups relevant to your profile (higher frequency = higher priority)
2. Techniques in the attack phase most valuable to detect early (Initial Access and Persistence are higher priority than late-stage Impact techniques, where earlier detection prevents reaching that phase)
3. Techniques where a log source is already present (Level 1 gaps are cheaper to close than gaps requiring new data source onboarding)

Output: detection roadmap. The prioritized gap list, filtered by threat profile and sorted by addressability, becomes the detection engineering roadmap. Each quarter, the top five to ten items from the list become detection engineering sprints. This connects coverage map gaps to actual engineering work rather than leaving the map as a compliance artifact.

DeTT&CT (Detect Tactics, Techniques and Combat Threats) is an open-source Python tool that provides a structured methodology for ATT&CK data source and detection scoring, with output that generates ATT&CK Navigator layers.

DeTT&CT data source YAML. Document data sources in YAML format with quality scores for each:

data_sources:
  - data_source_name: Windows Security Event Log
    date_registered: 2024-01-01
    products:
      - Microsoft Windows
    available_for_data_analytics: true
    data_quality:
      device_completeness: 3
      data_field_completeness: 3
      timeliness: 3
      consistency: 3
      retention: 3

Quality scores (1-5) for device completeness (what percentage of the environment generates this log), data field completeness (are all relevant fields present), timeliness, consistency, and retention. DeTT&CT uses these scores to generate a data source coverage heatmap.

DeTT&CT technique YAML. Document detection rules for each technique with quality scores:

techniques:
  - technique_id: T1059.001
    technique_name: PowerShell
    detection:
      - applicable_to:
          - all
        location:
          - Microsoft Sentinel
        comment: Encoded command detection rule v2 -- tuned for mgmt exclusions
        score_logbook:
          - date: 2025-06-01
            score: 3
            comment: Tuned against Intune and SCCM baseline, FP rate below 5%

Scores use the same 1-3 scale (data source only, behavioral, tuned). The score logbook tracks changes over time.

Generating ATT&CK Navigator layers. Run dettect.py ds to generate the data source layer and dettect.py d to generate the detection layer. Import into ATT&CK Navigator for visualization. The output shows exactly which techniques have data source coverage, behavioral detections, or tuned detections -- the three-level quality scale in Navigator format.

Quarterly reviews keep the coverage map accurate and connect the map to the detection engineering roadmap.

Pre-review: automated detection inventory. Two weeks before the quarterly review, run a script that exports all active detection rules from the SIEM with their rule IDs, last-modified dates, last-triggered dates, and ATT&CK technique tags. Flag rules that have not triggered in 90 days (may be broken or not applicable to the current environment) and rules with ATT&CK tags that do not correspond to the technique documented in DeTT&CT (tag drift).

Review session agenda (2-3 hours):

1. Quality reassessments: for each technique with a Level 2 detection, review false positive rate data from the past quarter. Rules whose FP rate improved below 10% graduate to Level 3. Rules whose FP rate increased should be reviewed for tuning or demotion.
2. New detections: add any detection rules created since the last review to the DeTT&CT YAML with initial quality scores.
3. Retired detections: remove detections that were retired (rules deleted or disabled). Downgrade affected techniques' quality level accordingly.
4. Data source changes: document any new log sources onboarded or existing log sources that were decommissioned.
5. Threat profile update: review whether the threat actor profile needs updating based on new threat intelligence from the quarter.

Post-review: roadmap refresh. After the review, regenerate the DeTT&CT navigator layers, compare the current coverage map against the threat profile alignment filter, and produce the updated top 10 prioritized gap list for the next quarter's detection engineering sprint. Present the before/after coverage comparison in the quarterly security report to demonstrate progress.

Coverage improvement velocity. Track the number of techniques that improved quality level each quarter (from Level 1 to Level 2, or Level 2 to Level 3). This metric demonstrates detection engineering productivity and is more meaningful than coverage percentage, which can increase by adding low-quality detections.