hack3rs.ca network-security
/learning/frameworks :: mitre-attack-detection-gap-mapping

student@hack3rs:~/learning/frameworks$ cat mitre-attack-detection-gap-mapping.html

Using MITRE ATT&CK to Map Detections and Coverage Gaps

Threat-Informed Defense

The MITRE ATT&CK framework is most useful when it drives real detection engineering and gap analysis — not when it produces colored matrices for slide decks. This module teaches how to map observed behavior to ATT&CK techniques, document actual coverage, and identify gaps worth fixing.

Network Security Keywords: mitre attack mapping tutorial, detection gap analysis, threat informed defense training, attack techniques defenders, coverage mapping blue team

why-this-framework-exists

ATT&CK documents adversary tactics and techniques in a shared knowledge base so defenders can reason about behavior, detections, and gaps using a common language across teams, vendors, and organizations.

why-defenders-should-use-it

Use ATT&CK to improve detection engineering decisions, sharpen triage hypotheses, generate threat hunting angles, and accelerate post-incident learning. It is especially useful for demonstrating to leadership where detection coverage exists and where it does not — with specificity instead of vague claims.

real-life-example.scenario

After an intrusion, a team maps observed activity to ATT&CK techniques: phishing for initial access, script interpreter for execution, credential access indicators, lateral movement via remote services, and exfiltration over web protocols. The resulting map shows strong email filtering but almost no lateral movement detection — which drives the next quarter's detection engineering roadmap.

ATT&CK as a Mapping Tool, Not a Checklist

ATT&CK is most useful when it answers operational questions: what behavior did we observe, what telemetry supports it, what detections fired or failed, and what should we improve? Those are engineering questions, not compliance questions.

Trying to "cover all of ATT&CK" without considering your environment, your threat model, and your available telemetry produces shallow coverage across many techniques — which is less valuable than deep, validated coverage across the techniques that actually matter for your stack and your incidents.

Expert ATT&CK use focuses on behavior families and detection logic quality. Tagging an alert with a technique ID is the beginning of the mapping work, not the end.

How to Map Detections to ATT&CK Properly

Start from actual detections and the telemetry they rely on. For each alert, describe what behavior it detects, which evidence fields it depends on, and what assumptions it makes about environment configuration. Map to ATT&CK based on that behavior description — not based on a product marketing label or vendor tag.

Record confidence and scope explicitly. A DNS tunneling heuristic might map to an exfiltration technique, but only for monitored DNS egress paths. A PowerShell detection might apply only where script block logging or Sysmon process creation events are enabled. Coverage that depends on a log source that might be disabled is partial coverage at best.

Include failure modes in your coverage records. A detection that breaks when a field name changes, when a log source goes quiet, or when a new OS version changes behavior is not reliable coverage — and should be documented as such.

Gap Analysis and Validation (Where ATT&CK Creates Real Value)

Gap analysis should produce decisions: which techniques matter most given your environment and threat model, which ones you currently cannot see, and what telemetry or control changes would close the most important gaps fastest. ATT&CK is valuable when it drives roadmap decisions, not when it generates reports.

Pair ATT&CK gap analysis with authorized lab testing or purple-team exercises. Simulate the behavior, confirm that expected telemetry appears, verify the detection fires, and check that an analyst can triage the result correctly. Every coverage claim is more credible with a validation record behind it.

Use ATT&CK during post-incident reviews to identify both the techniques the attacker used and the detection or containment opportunities you missed. That analysis sharpens the next iteration of your coverage map.

how-to-use-it.step-by-step

  1. Select a recent alert, hunt, or incident and collect the underlying evidence.
  2. Describe the observed behavior plainly before assigning ATT&CK tags.
  3. Map behavior to ATT&CK tactics/techniques with notes on telemetry dependencies.
  4. Record whether coverage is preventive, detective, partial, noisy, or absent.
  5. Prioritize gaps by attack-path relevance and validation feasibility.
  6. Test or simulate key behaviors in an authorized lab and update mappings based on results.

lab-safe-workflows-and-cli-boxes

These examples are for authorized learning labs and defensive operations. The goal is to teach interpretation and workflow discipline, not blind command copying.

Build a simple ATT&CK mapping table for detections

printf "detection,technique,telemetry,status,notes\nSuspicious RDP from admin subnet,T1021.001,Firewall+Windows logs,partial,No east-west Zeek coverage\n" > attack-mapping.csv

example output

$ column -s, -t < attack-mapping.csv
detection                       technique   telemetry               status   notes
Suspicious RDP from admin subnet T1021.001 Firewall+Windows logs   partial  No east-west Zeek coverage

$ why-it-matters: Keeping ATT&CK grounded in actual detections, evidence, and coverage status is what turns it from slideware into engineering work. This format makes coverage claims auditable and gaps visible.

Find partial or missing coverage entries

awk -F, 'NR>1 && ($4=="partial" || $4=="missing") {print $0}' attack-mapping.csv

example output

Suspicious RDP from admin subnet,T1021.001,Firewall+Windows logs,partial,No east-west Zeek coverage

$ why-it-matters: Maintaining an explicit list of partial and missing coverage tied to real detection workflows is where ATT&CK pays off. Teams improve faster when gaps have names, owners, and backlog entries.

common-mistakes-and-failure-modes

  • $Tagging alerts with ATT&CK IDs without checking what behavior is actually detected.
  • $Claiming broad coverage without documenting telemetry dependencies and blind spots.
  • $Using ATT&CK as a reporting exercise rather than a validation and improvement tool.
  • $Ignoring analyst triage quality while focusing only on signature count.

what-you-should-be-able-to-produce

  • $A detection-to-ATT&CK mapping sheet with confidence and dependencies
  • $A prioritized coverage gap backlog tied to real attack paths
  • $A validation plan for technique-focused detection testing

references-and-related-learning