Threat Modelling Guide: STRIDE and PASTA

Design flaws are the most expensive security defects to fix later, and threat modelling is the cheapest way to find them before code exists. Yet many organisations treat it as a one-off document produced for an audit, drawn once and never read again. This guide explains how to run threat modelling as a repeatable engineering practice: the four questions, data flow diagrams and trust boundaries, STRIDE, PASTA, LINDDUN and attack trees, running a workshop, working in agile teams and at scale with threat models as code, using identity as a lens, and tracking mitigations to closure. It is written for application security engineers, architects and development leads, and for security managers who want threat modelling to change designs rather than fill folders.

Key takeaways

• Four questions are the whole method. What are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job; every named methodology is a way of answering them.
• Trust boundaries are where to look first. OWASP notes they "often represent possible attack points"; most serious findings sit where data, credentials or control cross one.
• Pick the method for the question. STRIDE for technical design, LINDDUN for privacy, attack trees for a high-value goal, PASTA when you need business risk, and do not stack techniques for appearance.
• A threat model is finished only when its mitigations are. Each threat needs a recorded response, an owner and a backlog item or test, or the model changes nothing.
• Model the machine identities. Service accounts, API keys, OAuth grants and signing keys cross trust boundaries in almost every system and are where attackers turn a design gap into access.

The four questions and when to threat model

The Threat Modeling Manifesto defines the practice as "analyzing representations of a system to highlight concerns about security and privacy characteristics", and frames it with four questions:

1. What are we working on? A model of the system: diagrams, data flows, assets and assumptions.
2. What can go wrong? Threats, found systematically with a framework and creatively by people who know the system.
3. What are we going to do about it? A response for each threat: mitigate, eliminate, transfer or accept.
4. Did we do a good enough job? Review the model, confirm mitigations were built and test them.

The Manifesto's values favour "a culture of finding and fixing design issues" over "checkbox compliance", "people and collaboration" over tools, and "continuous refinement" over "a single delivery". OWASP says threat modelling is "ideally performed early in the SDLC, such as during the design phase", and that it is not done once and never again. Microsoft lists "Perform security design review and threat modeling" as practice 3 of its ten SDL practices, and the OWASP Top 10 2025 category A06 Insecure Design states that "An insecure design cannot be fixed by a perfect implementation".

Triggers for a new or updated model: a new system or service; a new external interface, API or third-party integration; a change to authentication, authorisation or session handling; new sensitive data types; a move to a new hosting platform or cloud service; adding an AI model or agent; and after a security incident or significant penetration test finding.

Modelling the system: data flow diagrams and trust boundaries

Data flow diagrams (DFDs) are the most common way to answer question one. They have five element types, and STRIDE-per-element (used by the Microsoft Threat Modeling Tool) says which threat categories normally apply to each.

• Draw at the right level: a context diagram for the whole system, then a level-1 diagram per significant component. A model that tries to show every class becomes the Manifesto's "Perfect Representation" anti-pattern; several simple views beat one perfect one.
• Label flows with what crosses them: protocol, data classification and, critically, the credential used (user token, service account, API key, mTLS certificate). Most design flaws become visible once the credential is written on the arrow.
• Mark cloud and SaaS boundaries explicitly: OWASP's cheat sheet calls out shared responsibility, managed services, multi-tenancy and identity federation as cloud considerations.
• Record assumptions: "the queue is only reachable from inside the VPC" is a testable claim and often a finding.

Choosing a method

OWASP's advice is direct: "Do not add techniques only to make the model appear comprehensive." Choose by the question you need answered.

DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) is a scoring scheme rather than a method. Its scores vary widely between assessors, so most teams now use a simple likelihood and impact rating, or CVSS for concrete vulnerabilities, and spend the saved time on mitigations.

STRIDE in practice

OWASP describes each STRIDE category as "a violation of a desirable security attribute". The table pairs each with the property, a typical design-level mitigation and the identity form it most often takes.

Walk each element and each flow that crosses a boundary, ask the relevant questions ("How can an attacker change the authentication data?" is Microsoft's example), and record threats in a consistent format: actor, action, asset, impact. MITRE CAPEC, "a comprehensive dictionary of known patterns of attack" with 559 patterns, is a useful prompt list when a team runs out of ideas.

PASTA, LINDDUN and attack trees

PASTA

The Process for Attack Simulation and Threat Analysis, co-created by Tony UcedaVélez, is risk-centric. According to its author's firm VerSprite, it has seven stages:

1. Definition of objectives (business impact, compliance requirements).
2. Definition of technical scope (assets, components, dependencies).
3. Application decomposition (DFDs and trust boundaries).
4. Threat analysis (plausible adversaries and techniques, with MITRE ATT&CK as input).
5. Weakness and vulnerability analysis (mapping known weaknesses to those threats).
6. Attack modelling (attack trees, validated by testing).
7. Risk and impact analysis (translating attack paths into business risk).

Use PASTA for high-value systems where executives need risk in business terms; it is too heavy for every sprint. It pairs well with the Cyber Risk Quantification Guide and the Threat Intelligence Guide for stage 4 inputs.

LINDDUN

LINDDUN is the privacy counterpart to STRIDE, applied to the same DFD. Its categories are Linking, Identifying, Non-repudiation, Detecting, Data disclosure, Unawareness and unintervenability, and Non-compliance. LINDDUN GO is a lightweight card-based variant; LINDDUN PRO is the systematic, per-element version. Note that non-repudiation is a security goal in STRIDE but a privacy threat here: an audit trail that proves who did what can harm the person it describes. Feed findings into a data protection impact assessment; see the DPIA Guide: Running a Data Protection Impact Assessment and the Privacy-Enhancing Technologies Guide.

Attack trees

Bruce Schneier's 1999 attack trees put the attacker's goal at the root and the ways to reach it as children. OR nodes are alternatives; AND nodes need every child to succeed. Assign leaf values (possible or impossible, cost, special equipment needed) and propagate them up: an OR node takes its cheapest child, an AND node sums its children. Changing a leaf value then shows whether a proposed countermeasure actually moves the cheapest path. Attack trees are the right tool for questions like "how could someone obtain our production signing key?"

Where identity fits

Identity is a useful lens because almost every flow across a trust boundary is authenticated by something, and in modern systems that something is usually a non-human identity: a service account, workload identity, API key, OAuth client, certificate or signing key. Asking five questions per boundary finds a large share of design flaws:

• Who or what authenticates here, and with what? Static shared secrets on a boundary are a finding in their own right. See the NHI Authentication Guide.
• What can that credential do beyond this flow? Over-scoped service accounts turn a single compromise into elevation of privilege. See the Service Account Security Guide.
• Where does the credential live, and who can read it? Unsecured credentials (ATT&CK T1552.001, Credentials In Files) and stolen application tokens (T1528) are common follow-ons to a design that stores secrets in code or configuration.
• Is the token checked for audience, issuer and tenant? The Microsoft Storm-0558 Key Breach 2023 showed what happens when a signing key from one trust domain is accepted in another.
• What third parties hold tokens into this system? The Salesloft Drift Breach 2025 showed how OAuth tokens held by one chatbot integration became a path into hundreds of customer Salesforce tenants. Valid credentials used this way map to ATT&CK T1078 Valid Accounts.

Running a threat modelling workshop

1. Prepare (one to two days before): the engineering lead drafts a DFD, a list of assets and data classifications, and known assumptions. Share it in advance.
2. Invite the right people: the Manifesto's "Varied Viewpoints" pattern means developers who know the code, an architect, an operations or platform engineer, a security engineer as facilitator, and a product owner who can accept risk. Avoid the "Hero Threat Modeler" anti-pattern, where one security expert does it alone.
3. Timebox: 60 to 90 minutes for a feature, half a day for a new system. Spend the first 15 minutes correcting the diagram; the corrections are often the most valuable output.
4. Elicit threats: walk boundaries with STRIDE (or LINDDUN for privacy), use card decks such as Microsoft's Elevation of Privilege to keep non-specialists engaged, and park debates on severity until the list is complete.
5. Decide responses: for each threat, agree mitigate, eliminate, transfer or accept, with an owner. OWASP notes that "Risk transfer does not itself reduce the likelihood or harmful consequences of an event", so record who owns residual risk.
6. Close: create backlog items and security test cases before the meeting ends, and schedule the review.

Threat modelling in agile teams and at scale

• Per story, not per release: add two questions to the definition of ready for any story that touches a trigger above: "what changes on the diagram?" and "what can go wrong?". Most stories need minutes, not a workshop.
• Threat model as code: OWASP pytm, "A Pythonic framework for threat modeling", describes the system in Python (TM, Boundary, Actor, Server, Datastore, Dataflow, Lambda, and newer LLM and Agent elements), then generates DFDs, sequence diagrams and a threat report from rule conditions. Its --stale_days option flags models that have drifted from the code. Custom threat files are evaluated with eval(), so protect them like code.
• Diagram tools with rule engines: OWASP Threat Dragon (web and desktop, STRIDE, LINDDUN, CIA, DIE and PLOT4ai) and the Microsoft Threat Modeling Tool (STRIDE per element, designed for non-security experts) generate candidate threats from a diagram. Treat generated threats as prompts, not conclusions.
• Store models with the code: keep the model file in the repository, review changes in pull requests and link threats to issue IDs. Threat Dragon's future format is expected to follow the CycloneDX-overseen Threat Model Bill of Materials (TM-BOM) schema, which should ease tool interchange.
• Small versus large organisations: a small team can use a whiteboard, STRIDE and a shared document, reviewed at design time. A large organisation needs a risk-tiering rule deciding which systems get full models, a trained champion in each team, a template and tooling standard, and central reporting of open mitigations.

AI systems and agents: the same four questions apply, with new elements (models, tools, memory, retrieval stores) and new threats such as prompt injection and excessive agency. Use the dedicated method in the AI Agent Threat Modelling Guide rather than stretching STRIDE alone.

Outputs and tracking mitigations

A useful threat model produces four artefacts: the diagram with assumptions, a threat register, security requirements and test cases. OWASP asks that mitigations be testable and their success measurable, and points to SSDF practice PW.1 for turning risk modelling into requirements. NIST's draft SP 800-154, Guide to Data-Centric System Threat Modeling (initial public draft, March 2016; NIST said in January 2025 it plans to finalise it), adds a data-centric view in four steps: characterise the system and data of interest, select attack vectors, characterise controls and their side effects, then analyse, noting that "It is far too simplistic to say that a control should be applied because it lowers risk."

Rolling out a threat modelling programme

1. Pilot with two or three teams on systems with real design work ahead; avoid starting with legacy systems nobody can change.
2. Standardise a light template: DFD conventions, the STRIDE prompt table above, the register fields and a definition of done.
3. Train champions in each team and pair them with a security facilitator for their first three models.
4. Tier by risk: full models for internet-facing, high-data or high-privilege systems; story-level questions for the rest.
5. Wire into delivery: design review gates, pull request templates, and links from threats to issues and tests.
6. Review and adjust quarterly: if models are not producing changes or finding issues later confirmed by testing, simplify rather than add process.

Detection and measurement

Threat modelling itself is not detected, but its outputs should drive logging: every threat accepted or partly mitigated should state what telemetry would show it happening, which feeds the Detection Engineering Guide process. Useful metrics:

• Coverage: percentage of tier-1 systems with a model reviewed in the last 12 months or since their last significant change.
• Mitigation closure: share of threat-model mitigations verified by a test, and median age of open ones.
• Design escapes: penetration test or incident findings that a model should have caught, tracked as a ratio to findings the model did catch.
• Drift: number of models older than the code they describe (pytm's stale check or last-commit comparison).
• Risk acceptances: number past their expiry date.

Framework mapping

CISA's Secure by Design initiative frames the same expectation for vendors: customer security as "a core business requirement, not just a technical feature", applied during design and owned "at the executive level".

Common failure patterns

• The shelf document: a model produced for an audit, never updated, while the architecture changes underneath it.
• Admiration for the problem: the Manifesto's anti-pattern of long threat lists with no decided responses or owners.
• Missing components: test tenants, legacy apps and admin paths left off the diagram, as in the Microsoft Midnight Blizzard Breach 2024, where a forgotten test tenant and an OAuth app opened executive mailboxes.
• Arrows without credentials: flows drawn but not labelled with the identity that authenticates them, so over-privileged service accounts and shared keys go unseen.
• Tool output as the answer: hundreds of generated threats accepted wholesale, burying the few that matter.
• Security team only: no developers or product owners in the room, so the diagram is wrong and nobody can commit to fixes.

Practitioner checklist

• Define triggers that require a new or updated threat model and add them to design review.
• Draw DFDs with trust boundaries, and label every boundary-crossing flow with data class and credential.
• Use STRIDE per element for security, LINDDUN for personal data, and attack trees for crown-jewel goals.
• Run workshops with developers, operations, security and a product owner who can accept risk.
• Record each threat with a response, owner, backlog item and verifying test.
• Keep models in the repository and review them in pull requests; consider pytm or Threat Dragon.
• Apply the identity questions at every boundary: who authenticates, with what, with what scope, stored where.
• Use the AI Agent Threat Modelling method for systems with models, tools or agents.
• Report coverage, mitigation closure, design escapes and expired acceptances quarterly.

Standards and references

• Threat Modeling Manifesto Working Group: Threat Modeling Manifesto
• OWASP: Threat Modeling Cheat Sheet
• Microsoft Learn: Microsoft Threat Modeling Tool threats (STRIDE)
• NIST: SP 800-154 Guide to Data-Centric System Threat Modeling (draft)
• NIST: SP 800-218 Secure Software Development Framework
• OWASP: Threat Dragon
• OWASP: pytm
• Bruce Schneier: Attack Trees

Related NHI Mgmt Group resources: AI Agent Threat Modelling Guide · Service Account Security Guide · DPIA Guide: Running a Data Protection Impact Assessment · Cyber Risk Quantification Guide · NHI Authentication Guide