Threat modelling as design
By the end of this module you will be able to:
- Apply the STRIDE framework to categorise threats against a real system component
- Construct a basic attack tree for a login mechanism
- Use LINDDUN to surface privacy-specific threats
- Execute the four-step threat modelling process on a given architecture
Microsoft Exchange ProxyLogon, March 2021
ProxyLogon: when no one asked what could go wrong
In March 2021, four zero-day vulnerabilities in Microsoft Exchange Server were disclosed collectively as ProxyLogon. Within 72 hours of public disclosure, state-sponsored actors and opportunistic attackers had compromised tens of thousands of servers worldwide.
The four CVEs (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065) exploited server-side request forgery via the frontend, authentication bypass via a crafted cookie, and post-authentication arbitrary file write. Every one of these threat categories has a named entry in standard frameworks.
Organisations running formal threat models against their Exchange deployment would have asked: “Can an unauthenticated caller reach back-end services via the frontend?” That question surfaces the attack surface of CVE-2021-26855 before any exploit exists. Organisations that had never asked “what could go wrong?” had no playbook, no prioritised controls, and no architectural mitigations in place when the exploits arrived.
What threat modelling is and why it matters
A threat model is a structured representation of all information that affects the security of an application. It captures what an attacker might do, why they might do it, and which controls reduce the risk. It is a living document, not a one-time deliverable.
The OWASP Threat Modeling Cheat Sheet (2023 update) articulates four questions that every threat model must answer:
- What are we building?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
The sequence matters. Teams that skip question one jump straight to threat lists without understanding their own system. Teams that skip question three produce impressive threat inventories that no one acts on. Threat modelling is most valuable at design time but remains useful after deployment: a post-deployment model helps teams triage incoming vulnerability reports and assess the blast radius of a newly discovered CVE entry.
With an understanding of what threat modelling is and why it matters in place, the discussion can now turn to the stride framework, which builds directly on these foundations.
The STRIDE framework
Microsoft developed STRIDE in the late 1990s as part of the Security Development Lifecycle (SDL). Each letter names a threat category mapped to a violated security property:
- S: Spoofing violates authentication
- T: Tampering violates integrity
- R: Repudiation violates non-repudiation
- I: Information Disclosure violates confidentiality
- D: Denial of Service violates availability
- E: Elevation of Privilege violates authorisation
STRIDE is applied per element in a Data Flow Diagram (DFD). Each process, data store, data flow, and external entity is examined against all six categories. Consider a web login endpoint that issues a JWT and stores session state server-side. Spoofing: credential stuffing or phishing; mitigate with MFA and account lockout. Tampering: modifying the JWT payload to change user role; mitigate with RS256-signed tokens and server-side signature verification. Information Disclosure: error messages revealing whether a username exists; mitigate with generic error messages. Elevation of Privilege: manipulating the session to gain admin access; mitigate with server-side authorisation checks on every request.
STRIDE identifies threat categories, not specific vulnerabilities. "Tampering with the session token" is a threat. The specific vulnerability might be a weak signing algorithm or an insecure transmission channel. Confusing categories with vulnerabilities leads to shallow mitigations that address symptoms rather than root causes.
With an understanding of the stride framework in place, the discussion can now turn to attack trees, which builds directly on these foundations.
Attack trees
An attack tree is a hierarchical diagram where the root node represents the attacker's goal and child nodes represent means of achieving it. AND nodes require all children to succeed; OR nodes require only one. Attack trees were formalised by Bruce Schneier in a 1999 article in Dr. Dobb's Journal.
They complement STRIDE by showing how threats combine into attack paths rather than treating each threat in isolation. For a web login form, the attacker's goal of "authenticate as a victim user" branches into three independent paths: steal credentials (via phishing, credential stuffing, or keylogger), bypass authentication (exploit an auth logic flaw), or hijack an active session (via XSS token theft, network interception, or session fixation). Defence-in-depth means eliminating or raising the cost of every branch, not just the most obvious one.
With an understanding of attack trees in place, the discussion can now turn to linddun for privacy threat modelling, which builds directly on these foundations.
LINDDUN for privacy threat modelling
STRIDE is security-focused. LINDDUN, developed by researchers at KU Leuven and first published in 2014, applies the same element-by-element analysis to privacy threats. The seven categories are: Linkability (connecting data points to infer identity), Identifiability (determining who a record belongs to), Non-repudiation in the privacy context (inability to deny data was shared), Detectability (inferring that a data subject is in a dataset), Disclosure of information, Unawareness (users not knowing how their data is used), and Non-compliance (processing that violates applicable law).
In 2018, researchers demonstrated that anonymised transaction datasets from a major European bank could be re-identified with 90% accuracy using just four background facts. A LINDDUN analysis of the analytics pipeline would have flagged Linkability at the data export stage and prompted k-anonymity or differential privacy before releasing datasets. LINDDUN is especially relevant for teams working under UK GDPR Article 25 (Privacy by Design and Default).
With an understanding of linddun for privacy threat modelling in place, the discussion can now turn to the four-step threat modelling process, which builds directly on these foundations.
“A threat model is used to identify potential threats to an application and to determine what mitigations, if any, should be applied. The threat model should be created during the design phase of an application's development and updated whenever design changes are made.”
OWASP Threat Modeling Cheat Sheet (2023 update), Threat Modeling Process section - Step 1: Decompose the Application
“Threat modeling should be an integral activity performed during system design, not a remedial activity performed after deployment. Threat models should be updated when system components change, new threat intelligence emerges, or significant changes occur in the operational environment.”
NIST SP 800-154: Guide to Data-Centric System Threat Modeling, Section 1.2 (2016)
The four-step threat modelling process
The OWASP Threat Modeling Cheat Sheet (2023 update) and NIST SP 800-154 both endorse a four-step iterative process.
Step 1: Decompose the application. Produce a Data Flow Diagram showing all processes, data stores, external entities, and the data flows connecting them. Mark trust boundaries: the lines where data crosses privilege or network zones. Microsoft's Threat Modeling Tool automates DFD creation and suggests threats per element type.
Step 2: Identify threats. Apply STRIDE to each DFD element. For privacy-sensitive systems, run LINDDUN in parallel. Record every threat in a structured register with: threat ID, category, affected element, description, and current mitigations.
Step 3: Rank threats. Use a scoring method such as DREAD or CVSS Base Score to assign numeric severity. Prioritise by risk equals likelihood times impact. High-severity unmitigated threats become immediate backlog items. Avoid ranking threats by gut feel: two engineers examining the same threat list routinely reach different priority orderings without a scoring method.
Step 4: Mitigate and validate. For each ranked threat, select one response: eliminate the feature, mitigate with a control, transfer via contract or insurance, or accept and document. After implementing mitigations, re-run the model to confirm severity has reduced.
Common misconception
“A threat model is a one-time activity completed before development begins.”
Every material architecture change requires an incremental update to the model. A new integration, a data store migration, or a change in user privilege levels all require revisiting. The ProxyLogon case involved functionality that evolved across Exchange Server versions without a corresponding security review. Treat the threat model as a living architecture document.
Common misconception
“STRIDE threat modelling is only useful for large enterprise systems with dedicated security architects.”
STRIDE analysis scales to any system regardless of size. A two-person startup building a single API with user authentication has a threat model worth 30 minutes of STRIDE analysis: Spoofing (can an attacker impersonate a user?), Tampering (can request parameters be manipulated to change outcomes?), Information Disclosure (what does the API return to unauthenticated callers?). The value is proportional to the consequence of a breach, not the size of the team. Equifax had a large security team but no documented threat model for the Apache Struts component that was exploited. A small team that models its single API surfaces treats security as a design discipline rather than a retrofit.
A development team building a REST API notices that an authenticated patient could modify the record ID in the URL to retrieve another patient's medical records. Which STRIDE category best describes this threat?
A fintech organisation runs LINDDUN on its analytics pipeline and finds that anonymised records can be re-linked to individuals using publicly available merchant data. Which LINDDUN category applies, and which UK GDPR principle is most directly at risk?
A startup is building a healthcare API that allows GP practices to query patient records by NHS number. The system has: JWT authentication for GP practice systems; PostgreSQL backend; an admin portal for system administrators to manage practice access. Perform a partial STRIDE analysis. Which component presents the highest-priority threat, and what is the most critical STRIDE category for that component?
Key takeaways
- Threat modelling is a four-step iterative process: decompose, identify threats, rank, mitigate. It is most valuable at design time but must be updated with every material architecture change.
- STRIDE classifies threats by the security property violated: Spoofing targets authentication, Tampering targets integrity, Repudiation targets non-repudiation, Information Disclosure targets confidentiality, Denial of Service targets availability, and Elevation of Privilege targets authorisation.
- Attack trees show how individual threats combine into attack paths, making it easier to reason about defence-in-depth and the cost of composite attacks.
- LINDDUN extends threat modelling to privacy with categories such as Linkability and Unawareness that STRIDE does not address, essential for systems processing personal data under UK GDPR.
- Tools such as Microsoft Threat Modeling Tool, OWASP Threat Dragon, and pytm lower the cost of threat modelling and enable version-controlled, pipeline-integrated threat analysis.
You can now model threats before code is written. The next challenge is implementing the identity and access controls that your threat model identifies as necessary. How do OAuth 2.0, OpenID Connect, and JWTs actually work, and what goes wrong when they are misconfigured? Module 11 covers applied identity and access control.
Standards and sources cited in this module
OWASP Threat Modeling Cheat Sheet (2023 update)
Primary process reference covering the four-step model, STRIDE per element, and tooling.
Data-centric system threat modelling methodology with structured threat identification guidance.
STRIDE origin and DFD tooling reference from the Security Development Lifecycle.
Privacy threat categorisation framework and GDPR Article 25 alignment for privacy by design.
Legal basis for privacy threat modelling: data protection principles and privacy by design obligation.