From STRIDE to MITRE ATT&CK
A Practitioner's Guide to Threat Modelling, Risk Scoring, and Ongoing Management
CyberCQR Technical Guide | July 2026 | 18 minutes reading time
Section 1: Board and Risk Committee Summary
Threat modelling answers a question every board should already be asking: if someone wanted to hurt this system, what would they actually do, and how likely is each route? Two frameworks do most of the work. STRIDE identifies the shape of the problem — is this a spoofing risk, a tampering risk, an information disclosure risk? MITRE ATT&CK then supplies the specific, real-world techniques attackers use to realise each of those risks, drawn from observed incidents rather than theory.
The output that matters to a board is not the diagram. It is the risk register: a short, prioritised list of findings, each with a score, an owner, and a date by which it will be treated. This guide shows how that register is built and kept current.
Why this matters at board level
- Regulators increasingly expect evidence of structured risk assessment, not a general assurance that "security is taken seriously" — DORA, FCA operational resilience rules, and ISO 27001 all reference formal risk treatment
- A risk register with owners and dates converts an abstract security posture into something the board can actually govern and hold management accountable for
- Threat modelling done before a system is built is materially cheaper than the same analysis performed as forensic work after an incident
Questions the Board Should Ask Management
- "Which of our systems have a documented threat model, and when was it last updated?"
- "Can you show me the risk register that came out of the last threat model, and who owns each open item?"
- "How do our findings map to techniques attackers are actually using, rather than theoretical risks?"
- "What is our process for re-scoring a risk when the environment changes — a new integration, a new regulation, a new attacker technique?"
Section 2: Technical Annex — The Six-Step Method
The method below takes a system from a blank page to a scored, owned risk register in six steps. Steps 1 and 2 use STRIDE to find the shape of the threats. Step 3 translates those findings into MITRE ATT&CK techniques. Steps 4 to 6 turn the technique list into a risk score and a managed register entry.
- Define scope and decompose the system — draw the boundary and the data flows
- Apply STRIDE per element — ask six threat questions of every process, data store, and flow
- Map each STRIDE finding to MITRE ATT&CK techniques — replace "what kind of threat" with "what an attacker would actually do"
- Build the attack path — chain techniques into a realistic sequence from initial access to objective
- Score the risk — combine likelihood and impact into a comparable number
- Enter it in the risk register and manage it — assign an owner, a treatment decision, and a review date
Step 1: Define Scope and Decompose the System
Before any threat can be identified, the system needs a boundary. Draw a data flow diagram showing:
- External entities — users, other systems, third-party services that interact with the system but are outside your control
- Processes — the pieces of code or services that do work (an authentication service, an API gateway, a background job)
- Data stores — databases, caches, log files, configuration stores
- Data flows — the arrows connecting the above, each one a potential attack surface
- Trust boundaries — the lines where privilege or trust level changes, such as the point where an unmanaged device meets a corporate application
Worked example: scope
The example carried through this guide is a Conditional Access policy granting a personal, unmanaged device access to a Microsoft 365 application via a web browser, gated on device compliance signals rather than MDM enrolment. The trust boundary of interest sits between the unmanaged device and the Entra ID authentication process.
Step 2: Apply STRIDE Per Element
STRIDE, developed at Microsoft, gives six questions to ask of every process, data store, and flow identified in Step 1. Each letter names a category of security property being violated.
| Letter | Threat category | Property violated | Question to ask |
|---|---|---|---|
| S | Spoofing | Authentication | Can someone claim to be a user or system they are not? |
| T | Tampering | Integrity | Can data or code be altered without authorisation? |
| R | Repudiation | Non-repudiation | Can an actor deny having performed an action, for lack of evidence? |
| I | Information disclosure | Confidentiality | Can data be exposed to someone not authorised to see it? |
| D | Denial of service | Availability | Can the system be made unavailable to legitimate users? |
| E | Elevation of privilege | Authorisation | Can an actor gain rights beyond what they were granted? |
Worked example: STRIDE findings
Applying STRIDE to the trust boundary between the unmanaged device and the Entra ID authentication process surfaces two findings worth carrying forward:
Finding 1 (Spoofing): A device condition check can be satisfied by an attacker who has obtained valid user credentials, without the device itself being compromised — the check authenticates the device state, not the person.
Finding 2 (Elevation of Privilege): A session token issued after successful Conditional Access evaluation can, if stolen after issuance, be replayed from a different device that never underwent the check — the compliance gate is checked once, not continuously.
Step 3: Map STRIDE Findings to MITRE ATT&CK Techniques
STRIDE tells you the category of the problem. It does not tell you how an attacker would actually exploit it. This is the gap MITRE ATT&CK closes. ATT&CK is a curated knowledge base of adversary tactics and techniques, built from observed real-world intrusions rather than hypothetical scenarios. Each technique carries a unique identifier (for example T1078), sits under one or more tactics (the attacker's immediate goal, such as Initial Access or Credential Access), and is documented with known detection and mitigation approaches.
The translation step asks, for each STRIDE finding: which documented ATT&CK techniques would an attacker use to realise this specific threat, in this specific environment?
| STRIDE finding | ATT&CK technique | Tactic | Why it applies here |
|---|---|---|---|
| Finding 1: Spoofing | T1078 — Valid Accounts | Initial Access, Defense Evasion | Credentials obtained via phishing or a breach elsewhere let an attacker present as the legitimate user during device evaluation |
| Finding 1: Spoofing | T1621 — Multi-Factor Authentication Request Generation | Credential Access | MFA fatigue attacks combined with valid credentials complete authentication without device compromise |
| Finding 2: Elevation of Privilege | T1550.001 — Application Access Token | Defense Evasion, Lateral Movement | A stolen session or refresh token is replayed from an attacker-controlled device, bypassing the original compliance check entirely |
| Finding 2: Elevation of Privilege | T1539 — Steal Web Session Cookie | Credential Access | Browser-based session theft via malware or an adversary-in-the-middle proxy is the practical mechanism for obtaining the token in the row above |
Why this step is the one most threat models skip: a STRIDE-only exercise typically stops at "spoofing is possible" and moves to a generic mitigation such as "improve authentication." Mapping to ATT&CK forces the specific question of mechanism — a stolen session cookie needs a materially different control (token binding, sign-in frequency) than a phished password needs (MFA hardening). Without this step, mitigations are generic and often miss the actual attack path.
Step 4: Build the Attack Path
Individual techniques rarely stand alone. Chain them into a sequence from initial access to the attacker's objective. This is where the ATT&CK tactic ordering (Initial Access → Execution → Persistence → Privilege Escalation → Defense Evasion → Credential Access → Discovery → Lateral Movement → Collection → Exfiltration → Impact) becomes useful as a spine.
Worked example: full attack path
- Initial Access: Phishing obtains the user's password (T1566, T1078)
- Credential Access: MFA request generation completes authentication (T1621)
- Defense Evasion: Session cookie stolen via an adversary-in-the-middle proxy sitting between the user and Microsoft 365, bypassing the device compliance check because the check already passed for the legitimate session (T1539)
- Lateral Movement: Stolen token replayed on an attacker-controlled unmanaged device to establish an independent, persistent session (T1550.001)
- Collection / Impact: Attacker reads mail and files with the same access as the legitimate user, undetected by controls that only check device state at initial sign-in
Step 5: Score the Risk
A documented attack path is not yet a prioritised finding. Scoring converts it into a number that can be compared against every other finding on the register, so that limited remediation budget goes where it does the most good first.
Two scoring approaches cover most needs. Pick one and apply it consistently across the register — mixing methods makes findings impossible to compare.
Likelihood × Impact (NIST-style)
Score likelihood and impact each on a scale of 1–5, multiply for a 1–25 risk score. Simple, board-friendly, and consistent with NIST SP 800-30 categories.
Best for: risk registers reviewed by non-technical stakeholders and board reporting.
CVSS-style vector scoring
Score attack vector, complexity, privileges required, and impact separately using the FIRST CVSS methodology, producing a 0–10 score with a documented vector string.
Best for: technical findings that will be compared against vendor CVEs, or fed into vulnerability management tooling.
Worked example: scoring the attack path
Using likelihood × impact on a 1–5 scale:
- Likelihood: 4 — adversary-in-the-middle phishing kits targeting Microsoft 365 sign-in are widely available and observed against comparable organisations in the same sector
- Impact: 4 — successful exploitation grants ongoing access to mail and files with no device-based containment available, and the affected data includes client-confidential material subject to FCA and GDPR obligations
- Risk score: 16 out of 25 — High
Step 6: Enter the Finding in the Risk Register and Manage It
A scored finding without an owner and a treatment decision is not being managed — it is being recorded. Every register entry needs four things beyond the score: a treatment decision, a named owner, a target date, and a review cadence.
| Treatment | Meaning | Applies to worked example when... |
|---|---|---|
| Mitigate | Reduce likelihood or impact through a control | Sign-in frequency and continuous access evaluation are enabled, reducing the window in which a stolen token remains valid |
| Transfer | Shift financial consequence, typically via insurance | Cyber insurance is confirmed to cover business email compromise arising from token theft |
| Accept | Formally accept residual risk, signed off at appropriate authority | After mitigation, residual score falls within the organisation's documented risk appetite |
| Avoid | Remove the capability or process causing the exposure | Unmanaged device access is withdrawn entirely for the highest-sensitivity data classifications |
Worked example: completed register entry
| Finding | Session token theft bypasses Conditional Access device compliance check (T1539, T1550.001) |
| Risk score | 16/25 — High |
| Treatment | Mitigate — enable Continuous Access Evaluation and reduce sign-in frequency for the affected Conditional Access policy |
| Owner | Identity and Access Management lead |
| Target date | 30 days from register entry |
| Review cadence | Quarterly, or immediately if a new ATT&CK technique targeting Entra ID token handling is published |
Keeping the Model Current
A threat model is a snapshot. Three triggers should prompt a re-run of Steps 2 through 6, not a wait for the next scheduled review:
- Architectural change — a new integration, a new trust boundary, a change in who can reach the system
- New published technique — MITRE ATT&CK is updated regularly; a technique added against your technology stack should trigger a targeted re-mapping of Step 3
- Regulatory change — a shift in what "impact" means for your sector changes Step 5 scores even when nothing technical has changed
Three Actions This Week
- Pick one system with a trust boundary you have not formally examined, and run Steps 1 and 2 — the data flow diagram and STRIDE questions — even in draft form
- Take your single highest-concern STRIDE finding and map it to at least two ATT&CK techniques before proposing a mitigation, so the control matches the actual mechanism rather than the general category
- Check whether your existing risk register has an owner and a target date on every open item — if any entry has neither, it is not being managed, regardless of its score
Glossary
ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge — MITRE's curated knowledge base of attacker behaviour, see also STRIDE.
CVSS: Common Vulnerability Scoring System — a standardised severity scale maintained by FIRST, see also risk score.
DREAD: An older risk-scoring mnemonic (Damage, Reproducibility, Exploitability, Affected users, Discoverability), largely superseded by likelihood/impact and CVSS-style methods in current practice.
Kill chain: An ordered sequence of attacker actions from initial access to objective, see also attack path.
MITRE ATLAS: The AI-specific sibling to ATT&CK, covering adversarial techniques against machine learning systems — referenced in CyberCQR's AI platform security guidance.
Risk register: A structured, owned record of identified risks, their scores, and their treatment status, see also risk score.
Risk score: A numeric value combining likelihood and impact, used to prioritise treatment across a risk register.
STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — Microsoft's threat categorisation model, see also ATT&CK.
Tactic: An attacker's immediate goal within ATT&CK, such as Initial Access or Credential Access, see also technique.
Technique: A specific, documented method of achieving a tactic within ATT&CK, identified by a code such as T1078, see also tactic.
Trust boundary: A point in a system where the level of trust or privilege changes, and therefore a natural focus point for STRIDE analysis.
References and Further Reading
- MITRE Corporation. "MITRE ATT&CK Framework" — attack.mitre.org
- Microsoft (2009). "The STRIDE Threat Model" — Microsoft Learn security documentation
- NIST (2012). "Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments"
- FIRST.org. "Common Vulnerability Scoring System version 3.1: Specification Document"
- MITRE Corporation. "MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems" — atlas.mitre.org
- OWASP. "Threat Modelling Process" — owasp.org
From One Model to Continuous Assurance
A single threat model is a point-in-time diagnosis. A CyberCQR retainer owns the register: re-running Steps 3–6 whenever MITRE publishes new techniques against your stack, re-scoring findings as your architecture or regulatory obligations change, and reporting movement to your board on a fixed schedule.
Gap diagnosis engagements typically surface 8–15 findings of this kind on a first pass through a single system — the register is what stops them being rediscovered a year later during an incident.
Discuss a Threat Modelling Engagement