ATT&CK Is a Map, Not a Verdict
MITRE ATT&CK is a knowledge base of observed adversary tactics and techniques. It helps teams use a shared language for behavior, compare telemetry, and build threat models. A technique mapping does not prove that malware is present, identify an actor, set severity, or show that a control works. Those conclusions require evidence outside the technique name.
This course pins mappings to ATT&CK content version 19.2 and records the review date. ATT&CK changes over time, so a production mapping must retain its original version and be reviewed against later releases. Never copy a technique identifier from an old report without confirming its current definition, platform, scope, and procedure examples on the official site.
Use a Defensible Mapping Contract
- State the evidence: quote the normalized event or artifact fact without claiming intent.
- Describe the behavior: explain the goal and action at the right level of abstraction.
- Select the narrowest supported mapping: prefer a sub-technique only when the evidence proves its distinguishing behavior.
- Record context: ATT&CK version, domain, platform, tactic, technique, data source, scope, and time.
- Record confidence and alternatives: say which evidence would raise, lower, or remove the mapping.
- Connect a defense: name the countermeasure, implementation point, owner, expected evidence, and validation method.
Map what the evidence supports, not everything a suspected family is known to do. If a synthetic case contains file-impact events but no evidence of an encryption method, map the observed impact behavior only. Do not infer credential access, persistence, propagation, or evasion from a family label.
Map Behavior Across Overlapping Labels
| Scenario evidence | Mapping question | Do not infer |
|---|---|---|
| Package provenance changes and an unexplained execution declaration | Which supply-chain and execution behavior is directly supported by the release and CI records? | That a second stage ran or that a named actor was responsible |
| Burst of destructive-looking file events in synthetic endpoint telemetry | Is impact observable, and is encryption, deletion, or another cause actually distinguished? | Ransomware family, key handling, initial access, or recovery interference |
| Trusted utility with unusual parentage followed by a sensitive change | Which interpreter or system-service behavior is visible, and which context makes it suspicious? | Fileless malware merely because a native utility appears |
| Server request, child process, and reserved outbound flow | Does the joined evidence support a server-side execution or web-shell-related behavior? | A command's content, persistence, or wider access without evidence |
| Long-lived process, TEST-NET socket, and synthetic high resource use | Which resource-hijacking or control-channel behavior is supported? | A miner, RAT, or bot label from one feature alone |
| Cross-view memory discrepancy and integrity failure | Which defense-impairing or hiding behavior is observed, and could collection failure explain it? | Rootkit or bootkit presence without trusted validation |
The same mapping discipline applies to browser permissions, mobile services, cloud control-plane events, container execution, and workload identities. Choose the correct ATT&CK domain and platform. Do not force every developer scenario into the Enterprise matrix when Mobile, ICS, or another model is the better scope.
Connect ATT&CK Behavior to D3FEND Countermeasures
D3FEND is a knowledge graph and vocabulary for cybersecurity countermeasure techniques. Use it to describe what a defense does to a digital artifact or behavior, not to decorate a control list. Start with the evidence object: process, file, credential, network traffic, configuration, image, package, or identity. Then select a current D3FEND countermeasure that acts on that object and verify its definition on the official site.
For each defensive relationship, record four things: where the countermeasure is implemented, what event proves it operated, what test demonstrates expected behavior, and what limitation remains. A package policy without an enforcement event is an aspiration. A network analytic without normal-traffic testing is an unmeasured hypothesis. A prevention control without recovery evidence is not a complete response plan.
Measure Coverage Honestly
A colored matrix can hide weak engineering. Separate visibility, analytic logic, prevention, response, and validation. A team may collect the right process data but have no analytic. It may alert but lack an owner. It may block one implementation while missing the same behavior in containers or managed code. Record these as different states.
Coverage should name the platform, data component, source, field quality, retention, analytic, test corpus, false-positive result, control owner, and last validation date. Count a technique as covered only for the behavior and environment actually tested. This produces a smaller but trustworthy coverage map that developers and responders can improve.
Suggested Study Plan (6 hours)
The published duration includes active practice, not video playback alone. Complete each block with the course-owned evidence and retain the stated deliverable so another reviewer can reproduce your reasoning.
| Study block | Time | Required evidence |
|---|---|---|
| Guided lesson and primary-source review | 1h 21m | Annotated notes that separate observations, hypotheses, limits, and version-sensitive facts. |
| Worked evidence walkthroughs | 1h 8m | Reproduce the lesson's tables or decision flow and challenge at least two assumptions. |
| Independent practice rounds | 1h 8m | Apply the method to two alternate records in the sanitized evidence pack and compare the conclusions. |
| Required lab | 1h 30m | A versioned ATT&CK mapping table, a D3FEND countermeasure table, a five-dimension coverage matrix, and three prioritized improvements with owners and validation evidence. |
| Knowledge check and review | 53 minutes | Answer the evidence check, review the rubric, and record one production follow-up. |
Evidence Check
Question: A synthetic case is labeled ransomware, but the evidence shows only rapid file changes. Should the mapping include credential access, persistence, and data encryption because those behaviors are common in ransomware incidents?
Reveal the defensive reasoning
No. Map only the behavior supported by the supplied evidence. Rapid file changes may support an impact hypothesis, but the analyst must distinguish encryption, deletion, synchronization, or another cause. Credential access and persistence need their own evidence. The case label is not evidence.
Primary References
Use these primary sources for the current standard or tool behavior. The course records framework versions so mappings can be reviewed when upstream guidance changes.