PASTA Threat Modeling

PASTA Threat Modeling

Why PASTA Threat Modeling?

Before the bad guys can exploit your security vulnerabilities, you may identify them via threat modeling and develop countermeasures that address those vulnerabilities. Security experts frequently use threat models to find holes in application environments (mobile, IoT, etc.) for security objectives. As a risk-centric threat modeling methodology, the Process for Attack Simulation and Threat Analysis (PASTA) introduces risk analysis and context into an organization’s security strategy right out of the gate. PASTA urges all stakeholders to work together to provide a secure environment.

What is PASTA Threat Modeling?

Founded in 2015 by VerSprite CEO Tony UcedaVélez and security expert Marco M. Morana, PASTA is a risk-centric threat modeling technique. Because of its risk-centric approach, collaborative dispositions, evidence-based threat data, and emphasis on the likelihood of any attack, PASTA has become a popular choice for businesses worldwide, including GitLab.

Compared to typical threat modeling methodologies, PASTA provides several advantages. For developers and business stakeholders to work together, PASTA enables them to understand better their applications’ inherent risks, how likely they are to be attacked, and the consequences for their businesses if a compromise occurs. Other classic frameworks for threat modeling can be hyper-focused on a single component, such as coding or the attack itself. Security terms like STRIDE can be remembered with the assistance of acronyms (which stands for “Spoofing,” “Tampering,” “Rejection,” “Information Disclosure,” “Denial of Service,” and “Elevation of Privilege”). Because it is a static framework, it is straightforward to put into action. As a result, it doesn’t make sense to have the same dangers in different businesses.

Benefits of PASTA Threat Modeling

  • A business-oriented strategy that is always contextualized.
  • Tests the viability of evidence-based threats by simulating them
  • An attacker’s perspective is taken into account.
  • Allows for the use of existing procedures inside the company.
  • A rapidly scalable method that can be swiftly scaled up or down

There Are 7 stages in the PASTA Threat Modeling Process

PASTA includes seven stages, each serving as a foundation for the next. Utilizing existing security testing activities like code review, third-party library analysis, static analysis, and threat monitoring for application infrastructure, this approach makes it possible for your threat model to be a linear process.

Stage One: Define the Objectives

Defining goals is the first stage in the PASTA technique. Internally, publicly, and by your user base, these are all possibilities. The application’s objective should be apparent to you. How does your company profit from this? Alternatively, it may be doing more back-end processing. What kind of rules should be put in place? Stage one of PASTA allows you to bring governance into these discussions from the beginning, unlike traditional, static threat modeling methodologies.

  • What to Include in Your Threat Model: Governance and Compliance
  • SANS, CAG, and other third-party frameworks are examples of an external frameworks.
  • Internal Standards: Cryptography, Authentication, NET Safety, and JAVA Safety
  • FIPS 140-2 and FedRAMP are examples of external regulations.

Risk assessments, vulnerability assessments, and SAST/DAST reports are all examples of internal processes and artifacts.

You don’t want your business to get penalized. For liability and reputational reasons, it doesn’t want an application that isn’t dependable or could leak credentials or personal information. Identifying the company’s objectives and aligning those objectives with your own security needs is always the first step.

Stage Two: Define the Technical Scope

The second stage of PASTA is to define your technical scope and determine your attack surface. Due to our singular focus on the application domain, security professionals in both the application and product domains often find themselves under-scoping.

You should know what you’re working with and what third-party services you might depend on when designing an attack surface. This can contain features developed by a developer, systems maintained by an engineer, or infrastructure components tracked.

Examples of attack surface components:

  • Endpoints of an API
  • web-based software
  • Infrastructure for a telecommunications network
  • The settings of the operating system
  • DNS (Domain Name System) server
  • The certificate server
  • a client on the move
  • Software/Library from a third party
  • a device for storing data
  • Framework for an Application
  • Configuration of Kubernetes is
  • Configuration of Docker
  • Configuration of a service

“What are you working with?” is a question that PASTA encourages collaboration with the engineering team, the cloud team, developers, and architects. In this setting, what are you advocating?” Then comes the question of “What can help us align?” Where does technology fit into this picture? You’ll be ready when it comes to staging three, application decomposition.

Stage Three: Decompose the Application

The deconstruction of the application is the third stage of PASTA. In the second stage, we established the context for our activities. We’ve now found a framework for understanding how everything relates. Identifying whether or if you have implicit trust models and, if so, where they are, is the primary goal of this stage. An IoT or an embedded device could communicate with an automobile component. Your implicit trust model could be used as a conduit for exploitation.

Data flow diagrams should be created at this point. To fully grasp the calls and integrations you identified in step two, and it’s best to work with your architecture. Threat modeling is more than just a set of data flow diagrams. Threats are absent from a data flow diagram, which depicts data flow between callers across trust barriers. Engineers and software developers don’t see it as a warning but as a road map for further investigation.

Stage Four: Analyze the Threats

Analyzing the threats is the fourth step. By reaching stage four, you should have a better idea of what the application does and what dangers it faces.

The project’s scope is determined by the technology you choose in stage two. Your data model and consumption method should also be considered when developing a strategy for handling large datasets. What kinds of dangers are more prevalent depending on how you consume data? The first step in your role as a threat modeler and security advocate is to identify the risks relevant to your business and its technology footprint by studying threat intelligence. You can then begin to develop your threat collection from there.

Threat context is lacking in traditional threat modeling approaches. Providing information about risks is not something we want to do to scare our viewers. We want credible evidence-based threats to build on, whether from developers or product owners. Cooking a plate of pasta in your mind is a good analogy. Pasta with a weak, watery sauce will not do for a severe pasta lover. The sauce you use must be scientifically sound. PASTA allows you to provide your audience with relevant threat analytics.

Dos and don’ts of threat intelligence consumption and analysis

Dos:

  • Use internal or external researchers or internal records to build your threat intelligence.
  • Recognize your danger sources and cross-validate them if necessary

Don’ts:

  • Use only one source of threat intelligence data.
  • Use information from your competitors to better understand your industry’s threats.
  • Allow the threat analysis to disclose assets you failed to evaluate in phases 2 and 3

Stage Five: Vulnerability Analysis

The fifth stage relates the application’s weaknesses to the application’s strengths. How will you combine tools and best practices for managing and assessing volumes, doing static and dynamic analyses, and so on? And in all the noise you see in the vulnerability analysis, what are the ones that are material to the threats in your threat library? Based on stage one, PASTA has a distinct advantage in focusing on the most critical threats to the business.

Identifying the problem is done in stage five. Static analysis may reveal weaknesses in my code base, but what about the application’s overall architecture is flawed? What if I was wrong about my trust model in stage three? Vulnerabilities can come from various sources, including faults found during manual security testing, architectural issues revealed by your data flow diagram, and vulnerability scanners.

Stage Six: Attack Analysis

PASTA stage six’s primary goal is to show that the things we found susceptible in stage five are viable. Attack trees are an excellent tool for creating a realistic depiction of an attack. A node on an attack tree might be associated with known vulnerabilities to help you estimate the likelihood of a successful assault.

How to build an attack graph

Your threat objective is often the root node of your assault tree. Cybercriminals, for example, want to steal credit card information. The impacted application component, also known as the target, can only access this information on the underlying nodes. You’ll find attacks from the attack library you built before in the following nodes. A roadmap for exploitation is the ultimate goal. One of the best things about attack trees is that they are flexible enough to cover the entire application or a single little piece of code within your SDLC.

Stage Seven: Risk and Impact Analysis

To put it simply, PASTA threat modeling is a risk management strategy. The ultimate purpose of stage seven is to develop countermeasures that protect against the most critical threats. To complete the threat modeling exercise, we’ll draw on the data gathered in phases one through six and connect the dots.

You’ll be able to see the derived impact of threats by simulating attacks using this information. It is feasible to make better risk management decisions if you understand the result of vulnerabilities and gaps in countermeasures.

Adapting PASTA to Design Your Risk-Centric Cyber Security Program

Risk prioritization is one of the most challenging tasks for a CISO to perform. PASTA threat modeling will give your team specific instructions on how to mitigate the risks. To access a residual risk analysis, we must first demonstrate to developers in stage six the viability of effect and the business impact inherent in stage one that affects their technical elements as described in stage two. With this technique, your engineers, executives, and board members will understand your application’s risks, weaknesses, and vulnerabilities. Weave PASTA into your company’s operations so that security is embedded in the DNA of your organization.

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.