PASTA: Process for Attack Simulation and Threat Analysis

The defining feature of PASTA relative to methodologies like STRIDE is sequencing: business objectives and business impact analysis come first, and only after that does the process move into technical decomposition and attack simulation. This ordering forces every technical threat identified later in the process to be traceable back to a business consequence, which is what makes PASTA output usable in risk registers and executive reporting rather than only in engineering backlogs.

PASTA also incorporates attacker simulation explicitly — it asks the team to model attack scenarios the way an adversary would actually execute them, informed by threat intelligence, rather than only enumerating abstract threat categories.

PASTA is structured as seven sequential stages. Each stage builds on the outputs of the ones before it, so skipping a stage tends to weaken everything downstream.

• •Stage I — Define Objectives: capture business objectives, compliance requirements, and the business impact of a security failure for the system in scope.
• •Stage II — Define Technical Scope: enumerate the technical environment — application components, infrastructure, dependencies, and the boundaries of what's being modelled.
• •Stage III — Application Decomposition: break the application down into its constituent parts (services, data flows, trust boundaries, actors) to understand how data and control move through it.
• •Stage IV — Threat Analysis: analyse relevant threat intelligence and threat actor behaviour against the decomposed application to identify what's actually likely to target this system.
• •Stage V — Vulnerability and Weakness Analysis: correlate identified threats against known vulnerabilities and design weaknesses in the system (scan results, code review findings, configuration gaps).
• •Stage VI — Attack Modeling: build attack trees or attack scenarios that show how identified threats could realistically exploit the identified vulnerabilities to reach an attacker's goal.
• •Stage VII — Risk and Impact Analysis: quantify the business risk of each viable attack scenario and prioritise remediation based on that risk, closing the loop back to Stage I's objectives.

Stage I is where PASTA earns its "risk-centric" label. Rather than jumping to a system diagram, the team documents what the business is trying to protect: revenue, customer trust, regulatory standing, intellectual property, uptime commitments. This produces the criteria that later stages use to judge whether a given threat actually matters.

Stage II then scopes the technical environment the exercise will cover — which applications, which infrastructure, which third-party integrations are in and out of scope. This matters because Stage III's decomposition work can be substantial for anything beyond a small application, and an unbounded scope makes the exercise unmanageable.

Application decomposition in Stage III is conceptually similar to building the DFD used in STRIDE — it produces the architectural map that later stages reason against. Stage IV then layers threat intelligence onto that map: which threat actors target this industry, what techniques do they favour (often mapped to something like MITRE ATT&CK), and which of the decomposed components those techniques would actually reach.

Stage V grounds the exercise in concrete weaknesses rather than hypothetical ones — pulling in results from static/dynamic analysis, dependency scanning, penetration test findings, and configuration audits, then correlating them against the threats identified in Stage IV. A threat with no corresponding vulnerability in your environment is lower priority than one that maps directly to a finding you already have open.

Stage VI is where PASTA becomes most distinct from checklist-style methodologies: it builds out attack scenarios or attack trees showing the realistic path an attacker would take, chaining vulnerabilities together rather than treating each one in isolation. This is closer to how a red team plans an engagement than to a compliance checklist.

Stage VII closes the loop by scoring each viable attack scenario against the business impact criteria defined in Stage I — likelihood, business impact, and often a cost-of-mitigation figure to support prioritisation decisions. The output is a risk-ranked list of attack scenarios with recommended controls, phrased in terms a risk committee or budget owner can act on.

The two methodologies aren't mutually exclusive — many teams use STRIDE inside PASTA's Stage IV or VI as the technique for generating candidate threats against a decomposed component, while PASTA supplies the business-alignment and prioritisation structure STRIDE doesn't have on its own. STRIDE is faster to run and better suited to a single design review; PASTA is heavier but produces output that's directly usable for risk reporting and investment justification.

PASTA is a good fit when the audience for the output includes risk owners or executives who need the threat model tied explicitly to business consequence — new high-value products, systems handling regulated data, or any exercise that needs to justify a security budget request. It's overkill for a quick design review of a low-risk internal tool, where a lighter STRIDE pass against a whiteboard diagram will get most of the value for a fraction of the effort.