PASTA was developed by Tony UcedaVelez and Marco Morana and published in their 2015 book Risk Centric Threat Modeling. Unlike STRIDE (technical taxonomy) and DREAD (scoring system), PASTA is a methodology — an end-to-end process that starts at business objectives and ends at risk-prioritized countermeasures.
The seven stages move from business → technical → attacker → risk. Done well, PASTA produces a threat model that an executive can read and an engineer can act on — which is why it shows up in regulated industries (finance, healthcare) where the threat model has to defend itself in front of an auditor.
The seven stages
Define business objectives
Start with what the application is for. What's the revenue model? What regulations apply? What's the cost of an hour of downtime? What is the data classification of what's stored? The threat model begins by understanding what's worth defending and why.
Define the technical scope
Identify the systems, services, network paths, third-party integrations, and data stores in scope. What's the application boundary? What lives inside and what's external? Where is the data at rest and in motion?
Decompose the application
Map the technical scope to data-flow diagrams, identify trust boundaries (where one system trusts data from another), enumerate authentication mechanisms, list privilege levels. This is roughly the same artifact STRIDE consumes — PASTA produces it with business context already attached.
Analyze the threats
Now identify the threats themselves. This stage can use STRIDE or any other discovery technique. PASTA's contribution is that the threats are tied back to business objectives from Stage 1 — you're not just listing "SQL injection," you're listing "SQL injection threatens the payment-card data store identified as PCI-regulated in Stage 1."
Identify vulnerabilities
For each threat, identify the specific vulnerabilities in the application or infrastructure that would make it realizable. Pull from CVE databases, OWASP Top 10, internal pen-test findings, code review notes. This is where the threat model meets the actual state of your codebase.
Simulate attacks
For each high-priority threat + vulnerability pair, walk through what an attacker actually does. Build attack trees (see the Attack Trees page). Map to MITRE ATT&CK techniques. Model the chain end-to-end: initial access → persistence → privilege escalation → lateral movement → objective.
Analyze risk and impact
Quantify the business impact of each attack scenario. Apply controls, calculate residual risk, and produce a prioritized roadmap. The output is something the business can sign off on: "we accept this much residual risk; we will spend $X to reduce these specific risks."
How PASTA differs from STRIDE
STRIDE vs PASTA at a glance
| Aspect | STRIDE | PASTA |
|---|---|---|
| Kind of tool | Threat taxonomy (vocabulary) | End-to-end methodology (process) |
| Starting point | The application's data flows | The business objectives |
| Audience for the output | Engineering team | Engineering AND executive AND auditor |
| Time investment | Hours per application | Days to weeks per application |
| Best at | Catching technical threat classes | Tying threats to business risk and prioritizing |
| When to use | Architecture review, design phase | Regulated industries, security program planning |
You can use both at once. A common pattern: PASTA at the program level (which threats matter to the business?) with STRIDE inside Stage 4 to do the actual threat discovery against each DFD. The two are complementary, not competing.
When to reach for PASTA
- Regulated industry. Finance, healthcare, government. When the threat model needs to satisfy an auditor as well as the engineering team.
- High-stakes new system. Greenfield architecture for something that will move money, hold PII at scale, or be safety-critical.
- The business has questions. When non-engineering stakeholders need to understand "what are we actually exposed to and what should we spend to reduce it?"
- Threat-driven roadmapping. Security teams that need to justify investment use PASTA outputs as the input to budget conversations.
When not to use it
- Sprint-scoped feature work. A single user story in a two-week sprint doesn't warrant a seven-stage methodology. Use STRIDE on the affected DFD; move on.
- Small teams without dedicated security resources. PASTA assumes a security architect who can drive the process. Without one, the method collapses into ceremony.
- Early-stage prototypes. When the system shape is changing weekly, formal threat modeling is wasted effort. Wait until the architecture stabilizes.
PASTA is the methodology for organizations whose threat modeling has to answer to more than just engineering. It is heavier than STRIDE because it does more — it ties threats to business risk, produces output executives can read, and survives audit conversations.
The seven stages are a recipe, not a religion. If stages 2 and 3 overlap for your system, do them together. If stage 6 (attack simulation) needs an external red team, hire one. The structure is there to make sure no critical step gets skipped — not to be followed slavishly.
References
Formatted in APA 7. Alphabetized by first author's last name.
- OWASP Foundation. (n.d.). Threat modeling process. https://owasp.org/www-community/Threat_Modeling_Process
- Shostack, A. (2014). Threat modeling: Designing for security. Wiley.
- UcedaVelez, T., & Morana, M. M. (2015). Risk centric threat modeling: Process for Attack Simulation and Threat Analysis. Wiley.