What Is Threat Modeling? STRIDE, PASTA, Attack Trees

A login service hashes passwords, rate-limits attempts, and logs every failure. It looks secure. Then someone draws the data flow and notices the password-reset endpoint trusts an email address from the request body, never re-checks the session, and emits a reset token over an unauthenticated GET. No scanner flagged it, because nothing is misconfigured and no CVE applies. The flaw is in the design, and the only thing that catches a design flaw before an attacker does is someone sitting down and asking, on purpose, how would I break this. That is threat modeling.

Threat modeling is the practice of examining a system's design to find what could go wrong, before it ships, and deciding what to do about each thing. It is structured, not a brainstorm: you map what the system does, enumerate the threats against it with a method like STRIDE, PASTA, or attack trees, rank them, and feed concrete fixes back into the design. This guide covers what threat modeling is, the four questions that drive it, the three methods you will actually meet (STRIDE, PASTA, attack trees), how they differ, and how a team runs a session that produces decisions instead of a document nobody reads.

Note on sources: the CrowdStrike reference page for this topic returned a 404 at the time of writing, so this article is written topic-first from primary framework sources (Microsoft for STRIDE, the PASTA authors, Bruce Schneier for attack trees) rather than rewritten from that page.

What is threat modeling?

Threat modeling is a structured analysis of a system that answers one question: what can go wrong here, and what are we going to do about it. You do it on the design, not on a running scanner, which is why it catches a different class of problem. A vulnerability scanner finds known flaws in things that already exist. Threat modeling finds the flaw in the way you decided to build something, the trust you should not have granted, the data path nobody secured, the assumption that breaks under an attacker who does not play along.

It is most valuable early, while the design is still cheap to change. Fixing a trust-boundary mistake on a whiteboard costs a conversation. Fixing it after launch costs a redesign, a migration, and probably an incident. That is the economic argument for threat modeling: it moves security decisions to the point where they are cheapest to act on.

Threat modeling is not a one-time gate, and it is not only for software. You can model an application, a network segment, a cloud deployment, a business process, or a single new feature. The unit is "a thing with a boundary, some data, and someone who would want to abuse it." Mature teams re-model when the design changes meaningfully, because a new integration or a new data flow can void the conclusions of the last model.

The four questions of threat modeling

Most modern threat modeling, including the approach the Threat Modeling Manifesto codified in 2020, is organized around four questions. Run them in order. They are the spine every method below hangs on.

1. What are we working on? Build a shared picture of the system. Draw the components, the data stores, the processes, the external entities, and the data flows between them. Mark the trust boundaries, the lines where data crosses from one level of trust to another, because almost every interesting threat lives on a trust boundary. A data flow diagram is the usual artifact. The goal is not a beautiful diagram; it is a model everyone in the room agrees is accurate.

2. What can go wrong? Enumerate the threats against that model. This is where a method earns its keep: STRIDE gives you six categories to check against each element, PASTA simulates an attacker against business impact, attack trees decompose a goal into the ways to reach it. The method is a forcing function so you do not just list the threats you happened to think of.

3. What are we going to do about it? Decide a response for each threat that matters. There are four honest options: mitigate it (add a control), eliminate it (remove the feature or the data), transfer it (push the risk to someone else, e.g. a payment processor), or accept it (document the decision and move on). "Accept" is a real answer when the risk is low and the fix is expensive, as long as someone with authority signs off.

4. Did we do a good enough job? Review the model. Check that the diagram still matches reality, that the threats were enumerated systematically, that each decision was recorded, and that the agreed mitigations actually got built. This is the step teams skip, and skipping it is how a threat model becomes a document that described a system that no longer exists.

STRIDE: classify threats by what an attacker does

STRIDE is the most widely used threat modeling method, created at Microsoft in 1999. It is a mnemonic for six categories of threat, and you use it by walking each element of your model and asking whether each category applies.

The strength of STRIDE is coverage. By forcing each element through all six categories, you find threats you would never have free-associated, the missing log that enables repudiation, the queue with no rate limit that enables denial of service. "STRIDE per element" is the structured form: take each process, data store, data flow, and external entity, and check which of the six it is exposed to, since not every category applies to every element type.

STRIDE is fast, teachable, and developer-friendly, which is why it dominates application threat modeling. Its weakness is that it is technical and element-focused; it tells you a threat exists but not how much it matters to the business, and it can balloon into a long list if you do not prioritize the output. Pair it with a ranking step.

PASTA: model the attacker against business risk

PASTA, the Process for Attack Simulation and Threat Analysis, is a seven-stage, risk-centric methodology. Where STRIDE starts from the system, PASTA starts from the business and works toward a simulated attack, so the threats that survive are the ones tied to real impact.

1. Define objectives. Establish the business and security objectives, the compliance requirements, and what a breach would actually cost.
2. Define the technical scope. Inventory the application, infrastructure, dependencies, and the attack surface in scope.
3. Decompose the application. Map data flows, trust boundaries, and entry points, the same modeling step STRIDE relies on.
4. Analyze the threats. Pull in threat intelligence and identify the relevant threat actors and their likely goals against this system.
5. Analyze the vulnerabilities. Correlate known weaknesses and design flaws in the decomposed system with the threats from stage four.
6. Model the attacks. Simulate how an attacker would chain those weaknesses into a real attack, often with attack trees or attack paths.
7. Analyze risk and impact. Quantify the residual risk and prioritize countermeasures by business impact.

PASTA's strength is that it ends in business terms, which is what gets remediation funded and what executives understand. It also explicitly consumes threat intelligence, so the threats reflect real adversaries rather than a generic checklist. Its cost is weight: seven stages with cross-team input is a heavy process, too heavy for a small feature, well suited to a high-value system where the stakes justify the effort.

Attack trees: decompose a goal into how to reach it

Attack trees are the oldest of the three, formalized by Bruce Schneier in 1999. They are a graph, not a checklist. The attacker's objective is the root node at the top, and the branches below it are the ways to achieve that objective, decomposed down to concrete leaf actions.

The logic is the value. Child nodes are joined by AND or OR: an OR node means any one child achieves the parent, an AND node means all children are required together. "Read the CEO's email" might branch into "compromise the mail server" OR "phish the CEO's credentials" OR "steal an authenticated session," and each of those decomposes further. You can then label leaves with cost, difficulty, or detectability and read the cheapest viable path straight off the tree, which is exactly the path a rational attacker would prefer.

Attack trees are method-agnostic and compose well with the others. PASTA stage six uses them to model attacks. STRIDE can seed the root goals (each high-impact STRIDE threat becomes a tree). Their weakness is that they are goal-by-goal: a tree models one objective deeply, so covering a whole system means many trees, and the tree is only as complete as the analyst's imagination of the branches. They shine for high-value targets where you want to reason about attacker effort, not for broad first-pass coverage.

STRIDE vs PASTA vs attack trees

The three are not competitors so much as different tools. STRIDE gives breadth, PASTA gives business-aligned depth, attack trees give per-goal reasoning. Many real programs use STRIDE for routine coverage and reach for the others when a system warrants it.

The practical pattern: run STRIDE per element to get coverage, rank what it finds, then build attack trees for the few goals that scored highest, and reserve full PASTA for the systems where business risk and compliance justify a seven-stage process. Use the method that fits the stakes, not the method you read about last.

How to run a threat modeling session

A threat model is worth the time only if it ends in decisions that get built. A session that produces a tidy document and no changes is theater. Here is the shape of one that works.

Get the right people and a diagram. You need someone who knows how the system actually works (usually an engineer), someone who thinks like an attacker (security), and someone who can authorize fixes. Start from a current data flow diagram with trust boundaries marked. If no diagram exists, drawing one is the first half of the session, and it routinely surfaces threats on its own because people discover the system is not built the way they assumed.

Enumerate with a method, not vibes. Walk the model with STRIDE per element, or decompose the top goals with attack trees. The method is what keeps the session from collapsing into "the stuff we already worry about." Write down every threat, even the ones you will not act on, so the decision is recorded.

Rank by impact and likelihood. Not every threat deserves a fix. Sort them so the conversation spends its energy on the ones that combine real impact with real reachability, the same prioritization discipline that separates useful vulnerability management from a raw CVE dump.

Decide and assign. For each threat that matters, pick mitigate, eliminate, transfer, or accept, name an owner, and create a real ticket. A threat with no owner and no ticket is a threat you have chosen to ignore without admitting it.

Map to known adversary behavior. Cross-reference the threats against MITRE ATT&CK so the abstract threats connect to concrete techniques real attackers use, and so your detection team knows what to watch for if a mitigation fails. A threat model that names ATT&CK techniques gives the SOC something actionable, not just developers.

Re-model when the design changes. The model describes a moment in time. A new integration, a new data store, a new trust boundary, any of these can invalidate it. Tie a re-model to significant design changes, not to the calendar, so the model keeps matching the system. Keeping the underlying data flow mapping current is what makes that re-model cheap instead of a from-scratch effort.

For a defender, the payoff is leverage. Threat modeling finds the flaws that scanners and pentests structurally cannot, the design decisions, before they become exploitable code. It gives engineering a prioritized list of what to fix while fixing is still cheap, and it gives the SOC a map of how this system would actually be attacked. The work stops being "react to what the scanner found" and becomes "decide, in advance, what we will not let happen."

Frequently Asked Questions

What is threat modeling in cybersecurity?

Threat modeling is a structured analysis of a system's design to identify what could go wrong and decide what to do about each threat, ideally before the system ships. It maps the system, enumerates threats with a method such as STRIDE, PASTA, or attack trees, ranks them, and feeds mitigations back into the design. It catches design flaws that vulnerability scanners and penetration tests cannot, because those test what already exists rather than the decisions behind it.

What are the four questions of threat modeling?

The four questions, codified in the 2020 Threat Modeling Manifesto, are: What are we working on? (model the system), What can go wrong? (enumerate threats), What are we going to do about it? (mitigate, eliminate, transfer, or accept each threat), and Did we do a good enough job? (review the model and confirm the mitigations were built). Every major method maps onto these four questions.

What is STRIDE in threat modeling?

STRIDE is a threat-classification method created at Microsoft in 1999. It is a mnemonic for six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. You apply it by walking each element of the system and checking which categories apply, which forces systematic coverage. STRIDE is fast and developer-friendly, making it the most common method for application threat modeling.

What is the difference between STRIDE and PASTA?

STRIDE starts from the system and classifies threats into six technical categories, giving broad, fast coverage. PASTA (Process for Attack Simulation and Threat Analysis) starts from business objectives and runs a seven-stage, risk-centric process that simulates an attacker and ends in prioritized, business-aligned risk. STRIDE is lighter and ideal for routine application design; PASTA is heavier and suited to high-value, compliance-driven systems.

What are attack trees?

Attack trees are a graph-based method, formalized by Bruce Schneier in 1999, that decomposes an attacker's goal into the ways to achieve it. The goal is the root node; branches are sub-goals and concrete actions, joined by AND (all required) or OR (any one suffices) logic. Labeling leaves with cost or difficulty lets you read off the cheapest attack path, the one a rational attacker would take. Attack trees compose well with STRIDE and PASTA rather than replacing them.

When should you do threat modeling?

Do it early, during design, when changes are cheapest to make, and re-do it whenever the design changes meaningfully, such as a new integration, data flow, or trust boundary. Tie re-modeling to significant design changes rather than a fixed calendar. The earlier a design flaw is caught, the cheaper it is to fix; finding it after launch can mean a redesign and an incident.

Which threat modeling method should I use?

Use the method that fits the stakes. STRIDE per element gives fast, broad coverage and suits most application work. Build attack trees for the few high-value goals that ranked highest, when you want to reason about attacker effort and paths. Reserve full PASTA for high-value systems where business risk and compliance justify a seven-stage process. Many programs run STRIDE routinely and reach for the others when a system warrants it.

The bottom line

Threat modeling is the discipline of asking, on purpose and before launch, what can go wrong with a design and what you will do about each answer. It catches the class of flaw that scanners and pentests structurally miss, the bad trust decision, the unsecured data path, the assumption that breaks under a real attacker. Run it on the four questions: what are we working on, what can go wrong, what are we going to do about it, did we do a good enough job.

The methods are tools for the second question, not rival religions. STRIDE classifies threats into six categories and gives fast, teachable coverage. PASTA runs a seven-stage, risk-centric process that ends in business-aligned priorities. Attack trees decompose a single goal into rankable attack paths. Use STRIDE for breadth, attack trees for depth on the goals that matter, and PASTA when the stakes justify the weight, then make sure every threat that matters ends as a decision with an owner and a ticket. A threat model that changes the design is worth a hundred that only describe it.