M01 · Threat Modeling and MITRE ATT&CK

Course: Microsoft Defender — Security Operations Fundamentals Module duration: 3.0 hours (including lab) Format: Instructor-led, hands-on

Currency note (as of June 2026): MITRE ATT&CK is versioned and updated roughly twice a year, and Microsoft renames portal surfaces frequently. Technique IDs are stable, but matrix contents, the current ATT&CK version number, and Microsoft portal paths change. Verify the live ATT&CK version at https://attack.mitre.org and product names against Microsoft Learn before relying on any specific detail below.

Learning objectives

By the end of this module you will be able to:

1. Explain the purpose of threat modeling and identify common methodologies (STRIDE, PASTA).
2. Describe the MITRE ATT&CK framework structure: tactics, techniques, and sub-techniques.
3. Map a sample attack scenario to ATT&CK techniques.
4. Use threat models and ATT&CK to prioritize detection coverage and response actions.

1. Why threat modeling matters

Threat modeling is the discipline of thinking like an attacker, on purpose and in a structured way, before an incident forces you to. Instead of asking “is our firewall patched?”, you ask: “If I wanted to harm this system, how would I do it, and what would stop me?”

Three reasons it matters for a Security Operations Center (SOC):

• Attacker perspective. Defenders naturally think in terms of assets they own and controls they bought. Attackers think in terms of paths: the cheapest route from outside to the data they want. Threat modeling forces the defender to trace those paths.
• Structured thinking beats intuition. A repeatable method ensures two analysts looking at the same system surface the same set of threats — coverage becomes auditable rather than dependent on who happened to be in the room.
• It drives prioritization. You cannot detect or mitigate everything. A threat model tells you which threats are most likely and most damaging, so limited SOC effort goes where it counts.

Key idea: Threat modeling answers four questions (the Shostack four-question frame): What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? Every methodology below is a structured way to answer those four questions.

Threat modeling vs. detection vs. response

These are distinct activities that feed each other:

• Threat modeling — predictive. Identifies what could happen and where you are exposed.
• Detection — observational. Builds the analytics that fire when a modeled threat is attempted.
• Response — reactive. The actions taken once a detection fires.

A good threat model makes detection and response deliberate rather than reactive: you decide in advance which adversary behaviors you most need to see and what you will do when you see them.

2. Common methodologies

There are many threat-modeling methods. This module focuses on the two named in the course objectives — STRIDE (component/asset-centric) and PASTA (risk-centric) — and briefly notes others you may encounter.

2.1 STRIDE — component/asset-centric

STRIDE was developed at Microsoft and organizes threats by the security property each one violates. The name is a mnemonic for six threat categories:

How you use it: Decompose the system into components and data flows (often as a data-flow diagram), then walk each element and ask “Could each of the six STRIDE threats apply here?” Because it is tied to concrete components, STRIDE is excellent for design-time analysis of a specific application or system and produces a thorough, checklist-driven enumeration.

Strengths: systematic, easy to teach, maps cleanly to controls. Limits: can produce long, undifferentiated threat lists; it does not, by itself, tell you which threats matter most to the business.

2.2 PASTA — risk-centric

PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric, seven-stage methodology. Where STRIDE starts from components, PASTA starts from business objectives and ends with a prioritized, evidence-backed view of risk. It explicitly ties technical threats to business impact, which makes it well suited to justifying SOC investment to leadership.

The seven stages:

1. Define Objectives — business goals, compliance drivers, and what “harm” means here.
2. Define Technical Scope — the application, infrastructure, and dependencies in play.
3. Application Decomposition — map components, data flows, trust boundaries, and entry points.
4. Threat Analysis — identify relevant threats using intelligence and observed attacker behavior.
5. Vulnerability & Weakness Analysis — find the weaknesses those threats could exploit.
6. Attack Modeling — simulate attack paths (e.g., attack trees) against the weaknesses.
7. Risk & Impact Analysis — quantify residual risk and recommend prioritized countermeasures.

Strengths: ties technical threats to business risk; produces prioritized, defensible output. Limits: heavier and more time-consuming than STRIDE; needs threat-intelligence input and stakeholder involvement.

2.3 STRIDE vs. PASTA at a glance

Choosing between them is not either/or. A common pattern is to use STRIDE to enumerate threats against a component thoroughly, then use PASTA-style risk weighting to decide which of those threats earn detection and response effort.

2.4 Others you may encounter (awareness only)

• DREAD — a scoring model (Damage, Reproducibility, Exploitability, Affected users, Discoverability). Largely deprecated for being subjective, but still seen in older documents.
• Attack Trees — a graphical decomposition of a goal into the steps needed to achieve it; often used inside PASTA’s attack-modeling stage.
• LINDDUN — a privacy-focused counterpart to STRIDE.
• OCTAVE / Trike / VAST — organizational- and process-oriented frameworks.

You are not expected to apply these in this course; recognize the names.

3. The MITRE ATT&CK framework

If threat modeling asks “what could go wrong?”, MITRE ATT&CK answers “here is the catalog of what attackers actually do.” It is a globally accessible, continuously curated knowledge base of real-world adversary behavior, observed and documented from incident reports and threat intelligence. ATT&CK stands for Adversarial Tactics, Techniques, and Common Knowledge.

Crucially, ATT&CK is behavior-based, not signature-based. It does not list malware hashes or IP addresses (those change constantly); it describes the behaviors an adversary must perform — behaviors that are far more durable and therefore far more useful for detection engineering. This is the foundation of threat-informed defense: aligning your detections to what adversaries do.

3.1 Structure: tactics → techniques → sub-techniques

ATT&CK is organized as a hierarchy. Read it as “the why, the how, and the specific how.”

• Tactics — the adversary’s tactical goal, the why of an action (e.g., “I need to maintain access” → Persistence). Tactics are the columns of the matrix. Each has an ID of the form TA#### (e.g., Persistence = TA0003).
• Techniques — how the adversary achieves a tactic (e.g., “create a scheduled task to re-run my code”). Each technique has an ID of the form T#### (e.g., Scheduled Task/Job = T1053).
• Sub-techniques — a more specific description of a technique (e.g., the Windows-specific “Scheduled Task” variant). IDs extend the parent with a dotted suffix: T####.### (e.g., T1053.005).

A single technique can serve multiple tactics. For example, a valid stolen account can provide Initial Access, Persistence, Privilege Escalation, and Defense Evasion — so the technique appears under several tactic columns.

Diagram alt text: A top-down tree. The top node is the tactic Persistence (TA0003), labeled “WHY: keep access.” It points down to a technique node, Scheduled Task/Job (T1053), labeled “HOW: schedule code to re-run.” That technique points to two sub-technique nodes: Scheduled Task (T1053.005) for Windows Task Scheduler, and Cron (T1053.003) for Linux cron jobs — illustrating that one technique has platform-specific sub-techniques.

3.2 The matrices

ATT&CK is published as several matrices for different technology domains. The one most relevant to SOC work is Enterprise (Windows, macOS, Linux, cloud, containers, network). Others include Mobile and ICS (industrial control systems). A matrix lays tactics across the top as columns, and lists the techniques that achieve each tactic down each column.

The Enterprise matrix is organized around these tactics, roughly in the order an intrusion unfolds (IDs shown; as of June 2026 — verify the live matrix):

Watch the ordering trap. The matrix columns suggest a left-to-right flow, but real adversaries do not march neatly through every column in order. They loop, skip, and repeat (e.g., escalate privileges, discover more, move laterally, escalate again). Treat tactics as a vocabulary for describing behavior, not a mandatory sequence.

3.3 Versioning — why it matters operationally

ATT&CK is versioned (e.g., “v1x”) and updated on a roughly twice-yearly cadence: techniques are added, renamed, split into sub-techniques, deprecated, or merged. Two practical consequences:

• Pin the version. When you record a threat model or detection mapping, note the ATT&CK version you used. A mapping built against one version may reference a technique ID that was later restructured.
• Re-baseline periodically. Coverage assessments drift as the framework grows; re-check your mappings when a new version ships.

As of June 2026, confirm the current version and changelog at https://attack.mitre.org/resources/versions/.

3.4 ATT&CK Navigator

The ATT&CK Navigator is a free web tool for annotating the matrix with colored, scored “layers.” Each layer is a saved view in which you highlight, score, and comment on techniques. Typical SOC uses:

• Coverage mapping — color techniques green where you have a working detection, red where you do not.
• Threat overlays — load a layer for a specific adversary group or campaign relevant to your industry.
• Gap analysis — overlay “what this adversary does” against “what we can detect” and the gaps become visually obvious (red cells the adversary uses).

Layers export and import as JSON, so they can be versioned and shared. As of June 2026, the hosted Navigator is at https://mitre-attack.github.io/attack-navigator/.

3.5 How ATT&CK shows up in Microsoft Defender

You do not consume ATT&CK only as a wall chart — Microsoft products are ATT&CK-aware. As of June 2026 (verify in-portal, as labels and paths change):

• Microsoft Defender XDR alerts are tagged with the ATT&CK tactics and techniques they represent, so an incident’s behaviors are already expressed in ATT&CK terms.
• Advanced Hunting and custom/analytics detection rules let you record the ATT&CK technique a detection is meant to catch, which is what makes coverage mapping (Section 5) possible.
• Threat analytics content references ATT&CK techniques for tracked threats.

This is why ATT&CK is taught early in this course: it is the shared language that ties together threat models, detections, incidents, and response across every Defender workload you will study in later modules.

4. Worked example — mapping an attack to ATT&CK

Below is a simplified but realistic intrusion. Read each step, then see how it maps to ATT&CK. This is the core skill the lab will assess.

Scenario (narrative):

An attacker sends a finance employee a convincing email with a malicious Excel attachment. The employee opens it and enables macros; the macro runs PowerShell that downloads a payload. The payload creates a scheduled task so it survives reboot, then dumps credentials from memory. Using a harvested admin credential, the attacker connects over SMB to a file server, collects sensitive documents into a single archive, and uploads them to an external cloud storage service over HTTPS.

Mapping (illustrative technique IDs — confirm against the live matrix, as of June 2026):

What this mapping gives you:

• A shared vocabulary: anyone reading “T1003.001” knows precisely which behavior occurred.
• A detection checklist: each row is a candidate detection. Can your tooling see PowerShell spawned by Office? Scheduled-task creation? LSASS access? SMB lateral movement?
• A response anchor: the chain shows where to contain (isolate the first host before lateral movement spreads) and what to hunt for elsewhere (other hosts with the same scheduled task).

Diagram alt text: A left-to-right chain of seven boxes showing the attack progression, each labeled with its ATT&CK tactic and technique ID: Initial Access (T1566.001) → Execution (T1204.002 / T1059.001) → Persistence (T1053.005) → Credential Access (T1003.001) → Lateral Movement (T1021.002) → Collection (T1560) → Exfiltration (T1567.002).

Mapping tip: Start from the behavior, not the tool. Ask “what did the adversary do?” (“ran a script,” “stole a credential”), find the matching tactic (the why), then narrow to the technique and sub-technique. Avoid forcing a one-to-one mapping — one observation can map to several techniques, and that is fine.

5. From ATT&CK gaps to detection priorities

Mapping is not the goal — better-prioritized detection and response is. This is where threat modeling and ATT&CK combine into a SOC workflow.

5.1 The gap-analysis loop

Diagram alt text: A six-step cycle that loops back to the start. Step 1: pick relevant threats (adversaries targeting your sector). Step 2: map their techniques in ATT&CK Navigator. Step 3: overlay current detection coverage. Step 4: identify gaps — techniques used but not detected. Step 5: prioritize gaps by likelihood times impact times effort. Step 6: build detections or controls for the top gaps. The arrow returns from step 6 to step 1, showing it is a continuous cycle.

5.2 Prioritizing the gaps

You will always have more gaps than capacity. Prioritize using factors such as:

• Likelihood / prevalence — how often is this technique actually used against organizations like yours? (Threat intelligence and adversary-group data inform this.)
• Impact — how much damage does success cause? A Credential Access or Impact technique usually outranks a low-value Discovery technique.
• Choke points — techniques that appear in many attack paths give the most coverage per detection. Credential dumping and lateral-movement techniques are classic high-value choke points.
• Detection effort / feasibility — do you already have the telemetry, or does closing this gap require new data sources?

A simple, defensible approach is to rank gaps by likelihood × impact, then break ties by lowest effort so you bank quick wins first.

5.3 Connecting back to the threat model

The threat model (STRIDE/PASTA) tells you which assets and risks matter to your business; ATT&CK tells you how adversaries attack in general. Used together:

1. The threat model narrows the universe to your critical assets and most damaging outcomes.
2. ATT&CK enumerates the concrete techniques that lead to those outcomes.
3. Gap analysis shows which of those techniques you cannot currently see.
4. Prioritization turns the gaps into an ordered backlog for detection engineering and response playbooks.

That ordered backlog — not the wall chart — is the deliverable that makes a SOC measurably better.

6. Module summary

• Threat modeling is structured, attacker-perspective analysis that answers: what are we building, what can go wrong, what will we do about it, and did we do enough.
• STRIDE is component/asset-centric and enumerates threats by violated security property; PASTA is risk-centric and ties technical threats to business impact across seven stages. They complement each other.
• MITRE ATT&CK is a behavior-based knowledge base structured as tactics → techniques → sub-techniques, published as matrices (Enterprise is the SOC default) and versioned — pin the version you use.
• The ATT&CK Navigator turns the matrix into shareable, scored coverage layers.
• Mapping an attack means translating observed behaviors into tactic/technique IDs, which gives a shared vocabulary, a detection checklist, and a response anchor.
• Gap analysis (relevant threats → mapped techniques → coverage overlay → prioritized gaps) converts ATT&CK into a prioritized detection-and-response backlog. Microsoft Defender expresses alerts and detections in ATT&CK terms, so this language carries through the rest of the course.

Glossary (first-use acronyms in this module)

• ATT&CK — Adversarial Tactics, Techniques, and Common Knowledge (MITRE’s behavior knowledge base).
• CWPP / CSPM — introduced in later modules; not used here.
• DFD — Data-Flow Diagram (a common decomposition artifact in STRIDE).
• ICS — Industrial Control Systems (an ATT&CK matrix domain).
• IOC — Indicator of Compromise (e.g., a hash or IP); contrast with behavior-based ATT&CK.
• LSASS — Local Security Authority Subsystem Service (Windows process targeted for credential theft).
• MITRE — the non-profit organization that maintains ATT&CK.
• PASTA — Process for Attack Simulation and Threat Analysis.
• SMB — Server Message Block (Windows file-sharing protocol, used in lateral movement).
• SOC — Security Operations Center.
• STRIDE — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
• TA / T / sub-technique — ATT&CK ID prefixes for Tactic (TA####), Technique (T####), and Sub-technique (T####.###).

Sources

Citations recorded per CLAUDE.md. All MITRE/Microsoft pages are living documents; access dates and the “as of June 2026” stamps above indicate currency. Verify before reuse.

1. MITRE ATT&CK — Home and framework overview. https://attack.mitre.org/
2. MITRE ATT&CK — Enterprise Matrix (tactics and techniques). https://attack.mitre.org/matrices/enterprise/
3. MITRE ATT&CK — Tactics index. https://attack.mitre.org/tactics/enterprise/
4. MITRE ATT&CK — Versions of ATT&CK / changelog. https://attack.mitre.org/resources/versions/
5. MITRE ATT&CK Navigator (hosted tool). https://mitre-attack.github.io/attack-navigator/
6. MITRE Center for Threat-Informed Defense — threat-informed defense resources. https://mitre-engenuity.org/cybersecurity/center-for-threat-informed-defense/
7. Microsoft Learn — “Understand the MITRE ATT&CK framework” and Defender XDR ATT&CK technique tagging. https://learn.microsoft.com/ (search “MITRE ATT&CK Defender XDR”; verify exact path, as of June 2026).
8. Microsoft — STRIDE threat model (Microsoft Threat Modeling guidance / Microsoft Security Development Lifecycle). https://learn.microsoft.com/ (search “STRIDE threat modeling”).
9. UcedaVélez, T. & Morana, M. — Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis (PASTA), Wiley, 2015 (primary reference for the PASTA methodology).
10. Shostack, A. — Threat Modeling: Designing for Security (origin of the four-question frame).

M01 of 10 · Microsoft Defender — Security Operations Fundamentals · maps to curriculum.md → M01 learning objectives 1–4. Student handout — distribute freely to learners. No answer keys contained.