PASTA Threat Modeling

PASTA Threat Modeling

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.

Enter your Email address if you want to connect and receive threat modeling updates (I won’t spam you or share your contact details):

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.

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:

  1. Define the Objectives
  2. Define the Technical Scope
  3. Decompose the Application
  4. Analyze the Threats
  5. Vulnerability Analysis
  6. Attack Analysis
  7. Risk and Impact Analysis
PASTA Threat Modeling Stages
PASTA Threat Modeling Stages

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
Table 1: PASTA stage one (define the objectives) input, activities and output

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

Table 2: PASTA stage two (define the technical scope) input, activities and output

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



Table 3: PASTA stage three (decompose the application) input, activities and output

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



Table 4: PASTA stage four (analyze the threats) input, activities and output

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



Table 5: PASTA stage five (vulnerability analysis) input, activities and output

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





Table 5: PASTA stage six (attack analysis) input, activities and output

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




Table 7: PASTA stage seven (risk and impact analysis) input, activities and output

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.

Nick

About the author

Nick has over 10 years of experience in the cyber security field. Nick has performed threat modeling at many enterprise-sized organizations, with a focus on threat modeling of IT applications, IT infrastructure, and business processes. Nick has also set up and rolled out threat modeling programs from the ground up.