Benefits of PASTA Threat Modeling and its 7 Steps

Why PASTA Threat Modeling?

Threat models are often used by security champions to discover flaws in application environments, systematically exploiting applications (mobile, IoT (Internet of Things), etc.) for security purposes. Threat modeling allows you to acknowledge security concerns and create appropriate countermeasures before they are exploited by the bad guys.

The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat modeling methodology that provides a step-by-step process to inject risk analysis and context into an organization’s overall security strategy from the beginning. PASTA threat modeling encourages collaboration across all stakeholders, creating an environment focused on security.

‍

What is PASTA Threat Modeling? Why Use PASTA?

PASTA is a risk-centric threat modeling methodology co-founded in 2015 by VerSprite CEO Tony UcedaVélez and security leader Marco M. Morana. Organizations all over the world like GitLab are adopting PASTA as their internal threat modeling standard because of its risk-centric approach, collaborative tendencies, evidence-based threat intel, and focus on the probability of each attack.

PASTA threat modeling allows for collaboration between developers and business stakeholders to truly understand your application’s inherent risk, its likelihood of attack, and the business impact if there was a compromise. Other traditional threat modeling frameworks can be hyper-focused on one component, such as coding or the actual attack.

For instance, STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS), and Elevation of Privilege) is a mnemonic that has been used and recommended by many. It is simple to implement because it is a static framework. However, with ever-evolving threat landscapes, it doesn’t make sense to have static threats across several industries. PASTA has several advantages over other traditional threat modeling methods.

‍

Benefits of the PASTA Threat Modeling Framework:

• Contextualized approach that always ties back to the business context
• Simulates and tests the viability of evidence-based threats
• Takes the perspective of an attacker
• Leverages existing processes from within the organization
• Collaborative process that can quickly scale up or down

‍PASTA has seven stages, with each stage acting as building blocks to one another. This approach allows your threat model to be a linear process and leverage existing security testing activities present within your organization, like code review, third party library analysis, static analysis, and threat monitoring for application infrastructure.

‍

Beginning Stages of PASTA

Stage One: Define the Objectives

These may be internally driven, externally driven, and/or driven by your user base. You should clearly understand the purpose of the application. How does it make your company money? Or maybe it does more back-end processing. What kind of regulations need to be incorporated? Unlike traditional, static threat modeling methods, stage one of PASTA allows you the opportunity to incorporate governance into these discussions and bake it in from the very beginning.

‍

Governance and Compliance To Include in Your Threat Model:

• External Framework – CoBit, ISO, NIST, SANS, CAG, CIS
• Internal Standards – Crypto, Authentication, .NET security, JAVA security
• External Regulations – PCI-DSS, NERC CIP, FIPS 140-2, FedRAMP
• Internal Process/Artifacts – Risk Assessments, Vulnerability Assessments, SAST/DAST reports

Your business doesn’t want to get fined. It doesn’t want an application that is not resilient or an application that could cough up credentials or personal information for liability and reputational reasons. Always start by understanding the business objectives first, and then harmonize them with your security requirements.

Stage Two: Define the Technical Scope

Understand your attack surface by defining your technical scope: know what you are protecting. A common theme for professionals in application security and product security is under-scoping because we are focused purely on the application domain.

When you are defining an attack surface, you should understand what you are running with and what sort of dependencies you might have with third-party services. This can include features created by a developer, systems maintained by an engineer, or components monitored in the infrastructure.

‍

Attack Surface Component Examples:

• API endpoints
• Web application
• Network infrastructure
• OS Settings
• DNS server
• Certificate server
• Mobile client
• 3rd party SW/Library
• Data storage device
• Application Framework
• Kubernetes configuration
• Docker configuration
• Service configuration

PASTA is meant to be a collaborative effort and encourages working together with the engineering team, the cloud team, developers, and architects to ask “What are you working with? What are you supporting in this environment?” And then “What will be helpful to align? What is the technology landscape?” This conversation will set you up to move successfully on to stage three, application decomposition.

‍

‍

Stages 3-4 of PASTA Threat Modeling

‍Stage Three: Decompose the Application

In stage two, we built context around what we are running. Stage three goes further by creating context around how everything communicates and how it all comes together. The key output of this stage is to understand if you have implicit trust models and where they are. It may be an IoT device talking to the cloud, or an embedded device talking to an automobile component. You may have an implicit trust model that could be a good conduit for exploitation.

In this stage, you should produce data flow diagrams. It is best to work with your architecture to understand the calls and integrations you discovered in stage two. Data flow diagrams alone are not threat modeling. A data flow diagram shows the flow of data between callers across trust boundaries, but it has no depiction of threats. It doesn’t illustrate to a developer or to an engineer what they should be worried about, it provides a map for analysis.

‍

‍

Stage Four: Analyze the Threats

The main output for stage four is to understand what the application does and what sort of threats are affecting your defined attack surface.

The scope is based upon your technology selection defined in stage two. You also need to consider your data type, your data model, and your data consumption model. What sort of threats are more pervasive based on how you’re consuming data?

As a threat modeler and security champion, you must first understand what threats are relevant to you by analyzing threat intelligence that might provide insight into attack behavior against your industry and your technology footprint. From there, you can start to build your threat library.

Traditional threat modeling methodologies lack threat context. When providing information on threats, we don’t want to fearmonger our audiences. Whether they’re developers or product owners, we want to have credible evidence-based threats to build on. Think of cooking an actual plate of pasta. If you are a true pasta lover, you can’t have pasta with some weak, bland sauce. You need good evidence-based sauce. PASTA allows you to produce relevant threat analytics for your audience.

‍

Dos and Don’ts of Threat Intelligence Consumption & Analysis

Dos:

• Make your threat intel utilizing internal/external researchers or internal logs
• Know where your threat sources come from, it’s relevant and cross-validated

Don’ts:

• Use one source of threat intel data
• Use your competitors’ threat intelligence as a basis for industry-related threats
• Let the threat analysis reveal assets you didn’t consider in stages 2 and 3 (this means you did those steps wrong”

‍

PASTA Threat Modeling Stages 5-6

‍

Stage Five: Vulnerability Analysis

Stage five correlates the application’s vulnerabilities to the application’s assets. How are you going to sew together tools and best practices, in terms of volume management, volume assessment, static analysis, dynamic analysis, etc.? And in all the noise that you’re seeing in the vulnerability analysis, what are the ones that are material to the threats in your threat library?

The key differentiator with PASTA is focusing on risks that will have the most impact on the business – all based upon stage one.

In stage five, you identify what is wrong. What is wrong with the application in terms of not just vulnerabilities that might be in my code base through static analysis, but also what is wrong with my design? What’s wrong with my trust model that I may have discovered in stage three?

There are many factors to throw into the vulnerability bucket, including flaws or weaknesses that were identified during manual security testing, vulnerabilities or weaknesses in architecture stemming from your data flow diagram, and/or different types of vulnerability scanners to name a few.

‍

Stage Six: Attack Analysis

The key objective for stage six of PASTA is to prove that the things we found vulnerable in stage five, are viable. To blueprint a good model for attacks, you want to use attack trees. Using attack trees allows you to map known vulnerabilities to a node on the attack tree to determine its likelihood.

How to Create an Attack Tree

The parent node of your attack tree is typically your threat objective. For example, if you’re a cybercriminal you want to compromise credit card information. The underlying nodes should be the affected application component, AKA the target – where they will access this information.

Then you have subsequent nodes that are pulled from the attack library you created earlier on. The end goal is to create a blueprint for exploitation. The great thing about attack trees is they can be large, medium, or small and either focus on the entire application, or one small asset inside your Software Development Life Cycle.

‍

‍

PASTA Threat Modeling Stage 7: Risk and Impact Analysis

At the end of the day, PASTA threat modeling is about reducing risks. The end goal for stage seven is to build countermeasures that mitigate the important threats. To finalize the threat modeling exercise, we want to utilize and tie back in the information we found in stages one through six.

By factoring all this information in, you will have access to the derived impact of threats through simulated attacks. By increasing your visibility into the impact of exploits and gaps in countermeasures, it becomes possible to make informed risk management decisions that save your organization time and money.

‍

Adapting PASTA to Design Your Risk-Centric Cybersecurity Program

As a CISO, the hardest activity to perform is often risk prioritization. PASTA will provide your team with prescriptive guidance on where to focus mitigation efforts. If we can prove the viability of impact to developers in stage six and demonstrate the business impact that is inherent in stage one, that affects their technology aspects as defined in stage two, then you can have access to a residual risk analysis.

This approach to risk-based threat modeling provides your developers, executives, and board members with clear visibility into the risks, flaws, and vulnerabilities of your application. PASTA can be the backbone of your program, woven into everything you do so seamlessly that you become a company with security molded in its culture.

VerSprite leverages our PASTA methodology with customization for your business’s cyber security needs. Get started with VerSprite today by downloading our e-book: PASTA Threat Modeling: The Process for Attack Simulation and Threat Analysis.

Contact VerSprite with any questions or to better your business with an experienced professional cyber security team.

Download the eBook