Threat models are often used by security champions to discover flaws in application environments, systematically exploiting applications 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 Analysisis 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.
The Process of Attack Simulation and Threat Analysis 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 an 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.
The first step of the PASTA threat modeling 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.
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.
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, 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.
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 on how you’re consuming data?
تعليقات