MITRE ATT&CK Mapping and Honest Coverage Claims
Learn how ATT&CK v19 organizes adversary behavior and defensive knowledge, map a detection honestly, and distinguish a technique mapping from proven coverage.
In this lesson, you will learn to:
- By the end of this lesson, learners will be able to map a detection to the behavior it observes, relate it to ATT&CK v19 defensive objects, and describe coverage with explicit scope, telemetry, and validation evidence.
MITRE ATT&CK Mapping and Honest Coverage Claims
This lesson teaches students how to use the current MITRE ATT&CK defensive model as a design and review aid. They learn how techniques relate to Detection Strategies, Analytics, and Data Components, how to map the behavior a detection actually observes, and how to make bounded coverage claims supported by local evidence.
ATT&CK Describes Behavior and Defensive Approaches
MITRE ATT&CK is a knowledge base of observed adversary behavior. It gives detection engineers a shared vocabulary, but it does not decide which behaviors matter in a particular organization or prove that those behaviors can be detected locally.
The adversary side
ATT&CK organizes behavior into tactics, techniques, and sub-techniques. A tactic expresses an adversary objective. A technique describes a way to pursue an objective. A sub-technique provides a more specific form of that behavior. Procedures describe how reported actors or software used the behavior in practice.
ATT&CK v19 split the former Defense Evasion tactic into Stealth and Defense Impairment. This change is a useful reminder that framework mappings are versioned knowledge. Store the ATT&CK version with important coverage records and review them after major releases.
The defensive side
Since ATT&CK v18, the defensive model uses three related objects:
- A Detection Strategy describes a high-level approach for detecting a technique.
- An Analytic describes platform-relevant logic and the evidence needed for part of that strategy.
- A Data Component describes a type of collected information that can support an analytic.
These objects help move from a broad behavior to candidate evidence. They are starting points. A local team must still confirm that the relevant telemetry exists, fields have the expected meaning, entities can be related, timing supports the analytic, and a consumer can use the output.
Use ATT&CK to ask better questions
A technique mapping should prompt questions: Which variation do we observe? On which platforms? Through which observation point? Which tested scenario supports the claim? What remains invisible? ATT&CK becomes valuable when it improves those engineering decisions, not when it merely adds a label to a rule.
How to Map a Detection Correctly
Mapping starts with the behavior represented by the detection result. Read the implemented logic and its required data. Then describe what a successful match means before looking for an ATT&CK label.
A reliable mapping process
- Identify the action, state change, or relationship the analytic observes.
- State the platforms, identities, assets, and behavior variations in scope.
- Select the most specific ATT&CK technique or sub-technique that describes that behavior.
- Record supporting Detection Strategies, Analytics, and Data Components when they add useful design context.
- Store the ATT&CK version, mapping rationale, owner, and review date.
If an analytic matches a process creating a scheduled task, it may observe one implementation of Scheduled Task/Job. It does not cover every scheduler, platform, creation method, or use of that technique. Write the mapping as a bounded claim.
Common mistakes
- Over-mapping: adding every technique that might appear somewhere in a scenario.
- Tool mapping: treating a tool name as though it were the adversary behavior.
- Tactic-only reasoning: assuming one rule provides broad coverage because it maps to a tactic.
- Versionless mapping: failing to record which ATT&CK model informed the claim.
- Missing local evidence: copying an ATT&CK Analytic without verifying fields, timing, entity keys, and benign behavior.
Honest mapping makes limitations visible. That is a strength. It lets engineers see which variations have evidence, which require better telemetry, and which remain accepted risk.
Using Coverage Mapping to Find Gaps
Coverage mapping is useful when every mark carries evidence. A count of rules or colored ATT&CK cells hides the differences between a brittle string match, a tested behavior analytic, and a disabled rule whose source stopped arriving.
Build an evidence-backed coverage record
For each claim, record:
| Question | Example evidence |
|---|---|
| What behavior variation is covered? | Scheduled task creation through a managed Windows endpoint |
| Where does it work? | Corporate Windows 11 devices with the endpoint sensor healthy |
| Which data is required? | Process creation and scheduled-task change events with user and host IDs |
| How was it tested? | Authorized creation, update, remote creation, and benign administration scenarios |
| What remains uncovered? | Unmanaged hosts, disabled sensor, alternate platform schedulers |
| When was it reviewed? | Date, ATT&CK version, detection version, and owner |
Prioritize meaningful gaps
A gap matters when the behavior is relevant, harmful, feasible in the environment, observable enough to support action, and not adequately addressed elsewhere. Missing a fashionable technique may be less important than weak visibility into a critical identity path.
Use coverage views to direct investigation, not to award a maturity score. “Unknown” is a valid state when testing has not established coverage. “Partial” should name the covered variation. “Degraded” should show a telemetry or operational problem. These states give leaders a truer picture than red, amber, and green cells without definitions.
The goal is not to fill the matrix. The goal is to understand which important behaviors the organization can detect, under which conditions, with what evidence and confidence.