PASTA threat modeling is a specific method of threat modeling. As with all threat modeling methods, PASTA threat modeling will allow you to identify potential threats in your object of scope. PASTA threat modeling can be performed on applications (mobile, web, Internet of Things, etc.) and more generally IT systems.
PASTA stands for Process for Attack Simulation and Threat Analysis (PASTA). It is a risk-centric threat modeling method, meaning that risk plays a central role and the focus is on the highest and most relevant risks that can affect your business. After all, IT (such as applications, systems, etc.) serve business, and that is their reason for existing.
New to threat modeling in general? Read my what is threat modeling article.
Note that PASTA threat modeling was created by Tony UcedaVélez and Marco M. Morana from VerSprite. Lots of the information presented here (and other parts of my website), come from the source at VerSprite. So take a look at their excellent explanation of what is PASTA threat modeling.
Why PASTA Threat Modeling
Why should you use PASTA threat modeling instead of another threat modeling method, for example, STRIDE threat modeling?
PASTA threat models have the following qualities:
- Risk centric: Threat modeling is performed with the aim of identifying risks, classifying risks, and focusing on the highest risks for your business. This allows your team to focus efforts on threats that matter and may impact your business instead of overly technical issues that ultimately have little impact either way.
- Collaboration across domains: All team members can contribute toward PASTA threat modeling, whether they are developers, non-developers, business analysts, risk professionals, testers, etc. All domain knowledge can contribute toward a PASTA threat model.
- Contextualized: Business context matters within PASTA threat modeling. This is not the case in many other threat modeling methods (such as STRIDE).
- Capable of simulations: Simulations can be performed using identified threats, collected evidence, etc. This has the advantage of ‘testing’ potential threats, making the more real and less theoretical.
PASTA Threat Modeling using a Threat Modeling Tool
I have a threat modeling tool that will help you to perform PASTA threat modeling. It will guide you through the process, from start to finish.
Start PASTA threat modeling using a threat modeling tool.
How the threat modeling tool can help:
- Develop a PASTA threat model based on assessments and diagrams.
- The PASTA threat modeling tool will guide you through the threat modeling process.
- The tool allows you to create beautiful PASTA threat modeling diagrams.
If you want more information before you dive in: read my article about the threat modeling tool.
History of PASTA Threat Modeling
PASTA threat modeling was developed in 2015 by Tony UcedaVélez and Marco M. Morana of VerSprite security.
PASTA has become a popular choice for businesses worldwide, as part of their threat modeling activities. The most prominent company using PASTA is GitLab. Given their position within the industry (a leading DevOps platform), it is a great seal of approval.
What is PASTA Threat Modeling
PASTA is a threat modeling method (or methodology).
PASTA has seven distinct stages. Each stage feeds information into the next stage. Each stage adds to the information known about the object in scope, its business/technical environment, potential threats involved, and its risks (and feeds into the overall threat model).
Having distinct steps helps practitioners and threat modelers to perform the PASTA threat modeling, because each step has specific instructions, thus breaking down the overall complexity of threat modeling.
The seven stages of PASTA threat modeling:
- Define the Objectives
- Define the Technical Scope
- Decompose the Application
- Analyze the Threats
- Vulnerability Analysis
- Attack Analysis
- Risk and Impact Analysis
The Seven Stages of the PASTA Threat Modeling Process
Now I’ll provide an explanation of each PASTA threat modeling stage.
Stage One: Define the Objectives
Defining objectives is the first stage of PASTA threat modeling. Objectives is a broad definition that includes business objectives (of the object in the scope of threat modeling), objectives of the threat modeling sessions, security objectives, security governance, and compliance objectives, and more.
The objective scope of information that should be included in stage one:
- General business requirements relevant to the object in scope (i.e., the application)
- Functional requirements of the object in scope
- Information security requirements, often in the form of policies, baselines, etc.
- Compliance and regulatory requirements, often in the form of standards or industry-specific frameworks
- Data classification for any data used in relation to the object in scope
| Input > | > Activities > | > Output |
|---|---|---|
| Business requirements Functional requirements Information security policies (baselines, requirements, etc.) Regulatory compliance Data classification / requirements | Define business objectives Define security requirements Define compliance requirements Perform Business Impact Analysis | Application functionality description Business objectives Security, compliance and regulatory requirements Business Impact Analysis |
Stage Two: Define the Technical Scope
Defining the technical scope and attack surface is the second stage of PASTA threat modeling.
This information is critical to determine ‘what we are protecting’ from a technical perspective. This looks at the technology aspect, and not so much the people and processes.
The technical scope and attack surface include relationships with other systems, dependencies, imports, etc.
The following provides an overview of potential items in scope:
- The application itself: Think about the application code base, application configuration, and connectors from the application to other systems/applications.
- Underlying database: Nearly all applications have a data store or database to store data used by the application.
- Cloud hosting: More and more applications, and IT in general, is moving to the cloud. This typically means AWS, Azure, or Google Cloud. The cloud includes lots of configurations with an impact on security.
- Networking: Applications communicate with all kinds of components, other applications, databases, APIs, etc.,
- Operating systems: Application solutions are often (but not always) hosted on a hosting stack that includes operating systems such as Windows or Linux.
- Encryption and Cryptography: Certificate servers, Key Management Systems, and similar systems are often (but not always) included in the scope of providing applications and IT systems.
- SaaS connectivity: Applications and solutions often connect with external SaaS solutions. This is a trend that is only increasing, so expect more SaaS impact.
- External service providers: Developing and providing new solutions are often outsourced, or at least include outsourced components.
- Containers: Container technology is often part of the modern IT stack.
What is not in scope? This is an important question to answer which is often overlooked. What do you want to include in threat modeling, and what do you purposefully want to exclude?
| Input > | > Activities > | > Output |
|---|---|---|
| Design requirements Rough technical sketches and notes Network (security) diagrams Connectors to other applications, APIs, etc. Asset library Architectural documents and diagrams Technical issue/risk register | Determine application and threat modeling scope and boundaries Determine dependencies at network, servers/services, and software level | End to end view of the architecture Overview of all protocols, services and types of data identified, servers and services Overview of hosts and servers, network devices |
Stage Three: Decompose the Application
Decomposing the application is the third stage of PASTA threat modeling.
Decomposing means that we deep dive into the application internals and their way of working.
The result of this stage will provide a lot of insight into how the application (or system) in scope works, and how (current) key security concepts are implemented. Another key output is to understand trust, where it lies, and where the trust boundaries are, either internally or externally.
Similar to STRIDE, we’ll create Data Flow Diagrams in this stage of PASTA threat modeling. With the Data Flow Diagrams, it’s possible to understand flows of trust. This can be used in later steps to analyze threats.
Note that I have an example Data Flow Diagram in the STRIDE threat model example.
| Input > | > Activities > | > Output |
|---|---|---|
| Architectural and sequence diagrams Use cases User roles and permissions (e.g., RBAC implementation) Network diagrams | Creating a Data Flow Diagram (or multiple DFDs) Identify users, roles and permissions (and making this clear if not already available as part of existing documentation) Identify assets, data, hardware & software Identify data entry points and trust levels | Data Flow Diagrams Access Control Matrix (readable) List of assets, interfaces and their trust levels Mapping of use cases x actors x assets |
Stage Four: Analyze the Threats
Analyzing the threats is the fourth stage of PASTA threat modeling.
In the previous steps, we identified the application environment and the application details. Now it’s time to identify and analyze potential threats.
The most important output of stage four is an understanding of threats, and how they relate to your attack surface.
Defining threats is based on general security insight, studying threat intelligence reports and known attack vectors, and consulting threat libraries. A unique feature of PASTA threat modeling is to include threats based on relevancy (i.e., having evidence that threats are truly exploited in the real world).
Further, threat information should come from a wide variety of sources, rather than a single source. And it helps to understand the source of threats (and where they were observed elsewhere along with exploit information).
| Input > | > Activities > | > Output |
|---|---|---|
| Threat agents and their motives Security Incidents Security logging / Secure Incident Event Monitoring (SIEM) reports Application / server logs Threat intelligence reports | Analyze scenarios (using probability) Analyze security incidents Analyze application logs, system logs Analyze all various sources for correlations and learnings | Attack scenario-landscape List of threat agents and attack vector Incident events related to threats an attack scenarios Threat intelligence related to attack scenarios |
Stage Five: Vulnerability Analysis
Vulnerability analysis is the fifth stage of PASTA threat modeling.
The main goal of this stage is to correlate vulnerabilities with assets, resulting in a good understanding of potential threats related to risks.
The source of vulnerabilities can come from the code base (e.g., through static analysis), the (high-level) design, manual penetration testing, vulnerability management, and/or threat intelligence.
| Input > | > Activities > | > Output |
|---|---|---|
| Library of threat trees Attack scenarios Vulnerability Management reports Vulnerability information (i.e., MITRE CWE, CVE, CVSS, CWSS) | Cross reference vulnerabilities and assets Map threats to vulnerabilities Map security flaws to use and abuse cases Include vulnerability scoring | Mapping of vulnerabilities to threat tree Overview of vulnerabilities using CVE-CWE Scoring of vulnerabilities |
Stage Six: Attack Analysis
Attack analysis is the sixth stage of PASTA threat modeling.
In this stage, we link the threats and vulnerabilities identified and include proof of viability. The proof is shown via the use of Attack Trees. This adds to the knowledge of likelihood, which is a key part of identifying and quantifying risk.
| Input > | > Activities > | > Output |
|---|---|---|
| Application technical scope and decomposition Attack libraries/patterns List of threats, attacks and vulnerabilities | Identify application attack surface Develop Attack Trees (for assets in scope) Map attacks and attack vectors Identify exploits and attack paths | Application attack surface Attack Trees with scenarios, and mapping with vulnerabilities Overview of attack paths |
Stage Seven: Risk and Impact Analysis
Risk and impact analysis is the seventh stage of PASTA threat modeling.
PASTA is an end-to-end threat modeling method, meaning that risk reduction is part of the process (rather than just identifying threats and not mitigating them).
So PASTA includes defining countermeasures that mitigate threats.
| Input > | > Activities > | > Output |
|---|---|---|
| All the output from previous steps, including: business scope, technical scope, application decomposition, threat/vulnerability/attack analysis Mapping of attacks to controls Technical standards for controls | Business impact Identify gaps in security controls and security countermeasures Identify residual risks and impact Identify risk mitigation | Application risk profile Risk overview Threats, attacks, vulnerabilities, business impact Residual risk Risk mitigation strategy |
PASTA Threat Modeling Tooling
Performing PASTA threat modeling can be achieved without tooling. However, it’s far easier to do so with a threat modeling tool.
Advantages of using PASTA threat modeling tooling:
- Following a specific and enforced PASTA threat modeling process.
- Easier registration of results (i.e. threats and security requirements).
- Easier learning for new PASTA threat modelers.
- Getting automated input (for known threats and known threat intelligence sources).
- Better reporting (especially for enterprise environments).
- And more (see below for details).
PASTA Threat Modeling Conclusion
PASTA threat modeling is a thorough threat modeling method with many steps. As an example comparison, it has many more steps, analysis points, and documentation than STRIDE.
The big advantage of using PASTA threat modeling is the method’s end-to-end nature, including the inclusion of risk to the business.
