What are the main threat modeling methodologies?

The most established threat modeling methodologies are STRIDE (a Microsoft threat taxonomy), PASTA (a seven-stage risk-centric process), DREAD (a prioritisation and scoring model), attack trees (a graphical attacker-centric technique) and OCTAVE (an asset- and organisation-centric method). Related methods such as VAST and LINDDUN extend the same landscape, with LINDDUN focused specifically on privacy threats.

What is the difference between STRIDE and PASTA?

STRIDE is a threat-centric taxonomy that helps you enumerate six categories of threat against a design, and it is fast and repeatable. PASTA is a broader seven-stage, risk-centric process that starts from business objectives and ends in attack simulation and residual-risk analysis. STRIDE answers "what threats exist"; PASTA additionally ties those threats to business impact, at the cost of more time and cross-functional effort.

Is DREAD still used for threat modeling?

DREAD is used far less than it once was. It scores threats across Damage, Reproducibility, Exploitability, Affected users and Discoverability, but the scoring is notoriously subjective — different analysts often rate the same threat very differently, and it does not map cleanly to formal risk management. Many teams now treat DREAD as a rough triage aid for ordering remediation rather than a reliable risk measure.

Which threat modeling methodology should I use?

Match the method to the system. Use STRIDE for design-level application reviews, PASTA for high-value or regulated systems where business impact matters, attack trees to analyse a single critical attack in depth, and OCTAVE for organisational, mission-level risk across assets. Many teams combine them — STRIDE as the backbone, PASTA-style attack paths for realism, and a light DREAD-like ranking for prioritisation.

What is the four-question framework in threat modeling?

Adam Shostack’s four-question framework asks: what are we working on, what can go wrong, what are we going to do about it, and did we do a good job. It is not a methodology but a flexible loop that any method — STRIDE, PASTA, attack trees or OCTAVE — can fit inside, which is why it is a good structure for running any threat model consistently.

Are attack trees and OCTAVE alternatives to STRIDE?

They serve different purposes rather than being drop-in replacements. Attack trees go deep on a single attacker goal and suit detailed architecture risk analysis of critical scenarios, whereas STRIDE gives broad coverage of a design. OCTAVE operates at the organisational level, assessing mission-critical assets and business risk instead of specific technologies, so it complements rather than replaces a design-time method like STRIDE.

Threat Modeling Methodologies Compared: STRIDE, PASTA, DREAD

Threat modeling methodologies are structured approaches for finding, naming and prioritising the things that can go wrong in a system before an attacker finds them for you. Rather than waiting for a penetration test or an incident, threat modeling asks a team to reason about its design — the data flows, trust boundaries and assets — and to enumerate plausible threats while there is still time to change the architecture cheaply. The catch is that there is no single method: STRIDE, PASTA, DREAD, attack trees and OCTAVE each frame the problem differently, and choosing the wrong one wastes effort. This guide compares the major methodologies and gives you a practical basis for picking one.

The threat modeling methodologies at a glance

It helps to see the field before diving into any single method. Broadly, the methodologies differ along two axes: whether they are threat-centric, attacker-centric or asset-centric, and how heavyweight they are to run. A comparative academic survey groups STRIDE, DREAD, PASTA, OCTAVE, VAST and LINDDUN by exactly these traits, noting that PASTA is comprehensive but complex, OCTAVE is organisational rather than technical, and attack trees suit detailed architecture risk analysis (Naik et al., Cardiff Metropolitan University, 2024). Here is the short version:

STRIDE — threat-centric. A Microsoft-origin taxonomy of six threat categories. Best for enumerating design-level threats against a data-flow diagram.
PASTA — attacker- and risk-centric. A seven-stage process that ties technical threats to business impact. Best for high-value systems and formal risk programmes.
DREAD — a prioritisation and scoring model, not a discovery method. Ranks threats you have already found, but suffers from well-documented subjectivity.
Attack trees — a graphical, attacker-centric technique that decomposes a single goal into the paths an adversary could take. Best for deep analysis of critical scenarios.
OCTAVE — asset- and organisation-centric. Assesses mission-level risk from a business standpoint rather than focusing on specific technologies.

STRIDE: the default starting point

STRIDE, developed at Microsoft, is the most widely taught threat modeling methodology and the one most teams should learn first. It is a mnemonic for six categories of threat: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Each maps to a security property you want to preserve — spoofing violates authentication, tampering violates integrity, repudiation violates non-repudiation, information disclosure violates confidentiality, denial of service violates availability, and elevation of privilege violates authorisation.

In practice you draw a data-flow diagram, mark the trust boundaries, then walk each element and each flow asking which of the six threats apply. The structure is what makes STRIDE repeatable: two engineers modelling the same design tend to surface a similar set of threats. Because it is systematic and beginner-friendly, STRIDE is our default recommendation for product and application teams — and it adapts well to newer surfaces. Our companion piece on stride-threat-modeling-llm-apps shows how the same six categories map onto prompt injection, model tampering and data leakage in AI systems.

PASTA: risk-centric and business-aligned

PASTA — the Process for Attack Simulation and Threat Analysis — is a seven-stage, risk-centric and attacker-centric methodology. Where STRIDE stops at "what threats exist", PASTA drives all the way from business objectives to simulated attacks and residual risk, deliberately involving business, operational, technology and risk stakeholders rather than only engineers. The seven stages move from defining business objectives, through defining the technical scope, decomposing the application, threat analysis, vulnerability analysis and attack modelling, to risk and impact analysis.

That breadth is PASTA’s strength and its cost. It produces threat models that executives and auditors can act on because every technical finding is tied to business impact — but it is heavier to run and needs cross-functional time and evidence. We reach for PASTA on high-value, high-scrutiny systems: payment platforms, regulated data stores, or anything where a board-level risk conversation is inevitable. For less critical services, its overhead is hard to justify.

DREAD and its limits

DREAD is not a discovery methodology at all — it is a scoring model for prioritising threats you have already identified. It rates each threat across five factors: Damage, Reproducibility, Exploitability, Affected users, and Discoverability. Sum or average the scores and you get a ranking that tells you which threats to fix first. On paper it is appealing because it turns a messy list into an ordered queue.

Use DREAD with caution. Threat modeling practitioners now rarely use it: as originally published it provoked arguments over how people should score risk and impact, and even with later scoring rubrics it lacks a way to define likelihood and impact factors that tie into a formal risk approach (OWASP; Shostack + Associates, 2026). Two analysts often score the same threat very differently, so treat DREAD as a rough triage aid, not a source of truth.

Attack trees and OCTAVE: depth and organisational scope

Attack trees take a different shape. Instead of a taxonomy, you pick a single attacker goal — "steal the signing key", say — and place it at the root, then branch downward into the sub-goals and steps an adversary would chain together to achieve it. Leaves can be annotated with cost, difficulty or required privilege, so the tree exposes the cheapest path to compromise. Attack trees are graphical and attacker-centric, and they shine for deep architecture risk analysis of a few critical scenarios rather than broad coverage of an entire system.

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), from Carnegie Mellon’s SEI, operates at a higher altitude again. It is asset- and organisation-centric: it assesses mission-level risk from a business standpoint and deliberately does not focus on specific technologies. That makes OCTAVE a poor fit for a sprint-level design review but a strong fit for enterprise risk programmes that need to reason about which business assets matter most. It pairs naturally with the kind of programme thinking in our guide to vulnerability-management-that-reduces-risk.

How to choose a threat modeling methodology

There is no universally best method; the right choice depends on what you are protecting, who is in the room and how much time you have. A pragmatic pattern many mature teams adopt is to use STRIDE as the backbone, borrow PASTA-style attack-path thinking for realism, and apply a lightweight DREAD-like ranking only to order remediation. Use these questions to decide:

Are you doing a design-level review of an application? Start with STRIDE — it is repeatable and quick to learn.
Is this a high-value system where business impact and audit evidence matter? Invest in PASTA’s seven stages.
Do you need to understand one critical attack in depth? Build an attack tree for that specific goal.
Are you assessing organisational or mission-level risk across assets, not a single app? Use OCTAVE.
Do you only need to prioritise threats you have already found? Apply DREAD carefully, and cross-check its scores rather than trusting them.

Running a threat model: the four-question framework

Whatever methodology you pick, it should fit inside Adam Shostack’s four-question framework, which distils threat modeling to its core and is flexible enough to host any of the methods above (Shostack + Associates, 2026). The four questions give any team a repeatable loop:

What are we working on? Draw the system: data-flow diagram, assets and trust boundaries. Scope it to what you can actually change.
What can go wrong? Enumerate threats using STRIDE, PASTA, attack trees or OCTAVE, depending on the context you chose above.
What are we going to do about it? Decide to mitigate, eliminate, transfer or accept each threat, and rank the work — this is where a DREAD-style triage can help.
Did we do a good job? Review the model against the built system, close the loop, and revisit when the design changes.

Threat modeling is not a one-off. Fold it into your delivery pipeline so the model is revisited whenever the architecture shifts — our guides to devsecops-integration-2026 and owasp-top-10-2025-changes cover how to keep design-time analysis and runtime controls in step as systems evolve.

The honest takeaway is that methodologies are tools, not religions. STRIDE will carry most application teams a long way; PASTA earns its keep on critical, regulated systems; attack trees add depth where you need it; OCTAVE raises the conversation to organisational risk; and DREAD, used sceptically, helps you order the backlog. Pick the lightest method that answers "what can go wrong" for the system in front of you, wrap it in the four-question loop, and repeat it often enough that it becomes a habit rather than a project.