Threat models are often used by security champions to discover flaws in application environments, systematically exploiting applications (mobile, IoT, 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 encourages collaboration across all stakeholders, creating an environment focused on security.
The Process of Attack Simulation and Threat Analysis (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 allows for collaboration between developer 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 a number of advantages over other traditional threat modeling methods.
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.
The first step of the PASTA methodology is to 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.
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 of PASTA is to 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 as a developer, systems maintained as an engineer, or components monitored in the infrastructure.
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.
Stage three of PASTA is application decomposition. In stage two, we built context around what we are running. Stage three goes further by creating context around how everything communicates, 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 is analyzing 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 upon 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 an insight into attack behavior against your industry and your technology footprint. From there, you can start to build your own threat library.
Traditional threat modeling methodologies lack threat context. When providing information on threats, we don’t want to fear monger 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 to your audience.
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 to 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.
The key objective for stage six of PASTA, is to prove that the things we found vulnerable in stage five, are actually 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 it’s likelihood.
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 your 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.
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 threats that are important. 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.
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.