Threat models are frequently utilized by security professionals to identify weaknesses in applications, and effectively exploiting the applications (mobile, IoT, etc.) for security reasons. Threat modeling lets you identify security risks and develop suitable countermeasures to prevent them from being utilized by hackers. Threat modeling is a method of identifying security risks and implementing appropriate countermeasures. Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric approach to threat modeling that offers a step-by-step method to incorporate context and risk analysis into the security plan from the very beginning. PASTA fosters collaboration between all parties to create an environment that is which is focused on security.
What exactly is the PASTA Threat Modeling?
It is the Process of Attack Simulation and Threat Analysis (PASTA) is an approach to threat modeling that is risk-centric that was co-founded in the year the year 2015 by VerSprite the CEO Tony UcedaVelez and security leader Marco M. Morana. All over the world, organizations including GitLab are adopting PASTA as their own internal threat modeling standard due to its risk-centric approach, collaborative nature as well as evidence-based threat information and a focus on the likelihood of every attack.
PASTA facilitates collaboration between business and developer stakeholders to fully comprehend the inherent risks of your application and vulnerability to attack, as well as the business consequences if there were the possibility of a breach. Other frameworks for threat modeling are often focused on a single element, like programming and the attack. For example The STRIDE (Spoofing Tampering, Repudiation Information Disclosure (Spoofing, Tampering, Repudiation, Information Disclosure (DoS) and Elevation Privilege) is a mnemonic which is used and recommended by a lot of. It’s simple to use since it’s an inherently static framework. With ever-changing threat landscapes, it does not seem sensible to create static threats that span a range of sectors. PASTA offers a variety of advantages over other threat modeling techniques.
The benefits from PASTA threat modeling:
Contextualized approach that always links back to the context of business
Tests the viability of threats based on facts
The perspective is that of an attacker
Make use of existing processes within the company
Collaboration process that can easily increase or decrease the size of the group.
The 7 Steps of PASTA
PASTA comprises seven stages each one acting as a foundation for each other. This method lets your threat model be a linear process that can utilize existing security testing practices that are in place within your organization such as code review, third-party analyses of libraries, static and threat monitoring of application infrastructure.
First Step Stage One: Define the Objectives
The initial step in the PASTA procedure is to determine the goals. They could be driven internally or externally driven and/or controlled by your user base. It is important to understand the goal of the application. What is it that will make your company cash? Maybe it’s additional backend processes. What regulations have to be considered? In contrast to static threat modeling techniques in stage one, PASTA offers the possibility to integrate governance into the discussions and incorporate it into the discussion from the very beginning.
Governance and Compliance to Include in your Threat Model:
External Framework External Framework CoBit, ISO, NIST, SANS, CAG, CIS
Internal Standards for Crypto authentication, .NET security, JAVA security
External Regulations – PCIDSS, NERC CIP, FIPS 140-2, FedRAMP
Internal Process/Artifacts : Evaluation of Risks and Vulnerability SAST/DAST reports
Your company doesn’t wish to be fined. You don’t want an application that’s not resistant, or an application that can leak personal details or credentials to protect its reputation and liability. Be sure to understand the goals of your business first, then align the goals with your security needs.
Stage Two Stage Two: Establish the scope of the technical requirements
The second stage in PASTA is to identify the attack surface of your organization by delineating your technical scope: understand what you’re protecting. The most frequent theme among experts in the field of application security as well as product security, is the lack of scope due to the fact that we focus solely on the application realm.
If you are creating an attack area and defining an attack surface, you must know the risks you face and the kind of dependence could be in place with third-party service. This could be features developed as a designer or system maintained by engineers, or parts which are monitored within the infrastructure.
Attack Surface Component Examples:
API endpoints
Web-based application
Network infrastructure
OS Settings
DNS server
Certificate server
Mobile client
3rd party Library/SW
Data storage device
Application Framework
Kubernetes configuration
Docker configuration
Configuration of services
PASTA is designed to be a collaboration initiative that encourages working with engineers and cloud team as well as developers and architects to ask “What do you work with? What do you support in this context?” And then “What can you do to help align? What is the current technology environment?” This conversation will help you proceed to the next stage, application decomposition.
Third Stage: Break down the Application
The third stage of PASTA is the decomposition of applications. In the second stage we established context around the application we’re doing. The third stage is about making sense of the way everything is communicating, and the way it all works together. The most important outcome in this process is know the degree of trust you have in models and the locations they’re located. It could represent an IoT device that is communicating with the cloud as well as an embedded gadget communicating to an auto component. It could be that you have unintentional trust models which could be a suitable way to exploit.
At this point you must create diagrams of data flow. It is recommended to collaborate with your structure to learn about the integrations and calls you have discovered in stage two. Data flow diagrams do not represent threat modeling. Data flow diagrams show the flow of data among the callers and across trust boundaries, however, it doesn’t provide a picture of threats. It does not show the developer or engineer what to be concerned about, but it only provides a diagram for analysis.
Fourth Stage: Evaluate the threats
The fourth stage is the analysis of threats. The primary output of step four will be to comprehend what the application is doing and what kind of threats are impacting your attack surface.
The scope is determined by the technology you choose to use, as defined in the stage two. It is also important to think about the type of data you’re using as well as your data model and the model you use to consume data. What kinds of threats are more prevalent depending on how you’re using data? As an expert in threat modeling and security advocate you need to first know the threat landscape that is relevant to you . This is done by studying threats that could provide an understanding of the behavior of attackers against your business and technological footprint. Once you have that, you are able to begin to create the threat model of your choice.
Traditional methods for modeling threats do not provide context for threats. When we provide information about threats, we shouldn’t be able to incite fear among our users. If they’re product or developer owners, we need to be able to provide credible, evidence-based threats that we can develop upon. Imagine cooking a real dinner of spaghetti. If you’re a real pasta lover, then you should not serve pasta with a poor and bland sauce. You need good evidence-based sauce. PASTA lets you create relevant threat information for your target audience.
What to do and what not to do of Threat consumption of intelligence & Analysis
Dos:
Create your own threat using intel by using internal or external researchers as well as internal logs
Find out the source of your threat information from, make sure it’s relevant and cross-validated
Don’ts:
Use only one source of information on threat intelligence
Utilize your threat intelligence of competitors as a base for industry-related threats
Make sure the analysis of threats uncover the assets you did not consider in steps two and three (this signifies that you performed the wrong thing)”
Stage Five: Analysis of Vulnerability
Stage five links the vulnerabilities of the application with the application’s strengths. How do you connect the best practices and tools, regarding volume management as well as dynamic analysis, volume assessments dynamic analysis and so on.? In all the chaos you’re experiencing in your vulnerability analysis, which are the risks that are significant to the threats within the threat database? The primary difference with PASTA is that it is focused on the threats that be most detrimental to the business , all built on the first stage.
In the fifth stage In stage five, you determine what’s wrong. What’s wrong with the application, not just the vulnerabilities that may exist in my code base by static analysis as well as what’s wrong in my design? What is wrong with my trust model I could have discovered in the third stage? There are numerous reasons to put your trust model in the vulnerability bucket, such as weaknesses or flaws discovered through manual security tests and weaknesses or vulnerabilities in the architecture resulting from your data flow diagram or different kinds of vulnerability scanners to mention just a few.
Stage Six: Analysis of Attack
The main goal for phase six in PASTA is to show that the methods we discovered to be to be vulnerable in stage 5 are in fact viable. To design a reliable attack model you must use attack trees. Attack trees allow you to link known vulnerabilities to a specific node in the attack tree to determine its probability.
How to create an Attack Tree
The primary node in your attack tree will typically be the goal of your threat. If, for instance, you’re a criminal, you’ll want to steal credit card data. The primary nodes must be the component of the application that is affected, AKA the target – which will be the one that has access to this data. There are additional nodes taken from the attack library you had created earlier. The ultimate purpose is to develop an outline for exploiting. The best thing about attack trees is that they can be huge small, medium, or large and can either concentrate on the entire application or a single asset within the Software Development Life Cycle.
Stage Seven Assessment of Impact and Risk
In the final analysis, PASTA threat analysis is focused on reducing risk. The goal of stage seven is to create countermeasures that minimize the risks that are significant. In order to conclude this exercise of modeling threats we’ll need to use and integrate the data we gathered during the first six stages.
In incorporating all of the information you have this way, you’ll be able to gain access to the effects of the threat through simulated attacks. In addition, by increasing your awareness of the consequences of exploits as well as the weaknesses in countermeasures it is possible to make more informed decision-making regarding risk management that will reduce time and money.
© Islington Stories 2025