Over the past two years, I've found myself in more discussions about threat modeling than throughout my entire 14-year career prior. This is significant, considering that over half of those years were within the government defense sector, one of the few industries regularly conducting threat models during that time. While it’s not a new process or approach, it is one that’s quickly gaining recognition for its effectiveness in building secure and compliant applications. The surge of threat modeling can be attributed to compliance with cybersecurity framework requirements, although a few recent conversations were specifically prompted by compliance concerns.
Open Web Application Security Project (OWASP) defines a threat model as a "structured representation of all the information that affects the security of an application.” This usually looks like a mapped list of assets, their threats, attack vectors, individual vulnerabilities, and mitigating controls for a given application or scope. This list, when assessed and prioritized, allows an organization to determine which threats are most critical and must be mitigated to achieve their security and compliance goals.
A threat model doesn’t simply emerge out of nowhere. The need for a tool, framework, or process often comes with a lengthy and uncertain analysis, regardless of how simple the problem you’re trying to solve might be. Each option may have its own proprietary vocabulary, and each tool can have unique capabilities that are advertised as major game-changers. The goal of this read is to simplify the mystery behind what makes a good threat model.
As a longtime practitioner of cyber defense, I’ve found that in few other places does the old saying “it’s not what you do, but how you do it” ring more true. Utilizing an existing threat modeling methodology offers a structured approach, making it easier to break down the process into manageable parts and identify the key elements to address. In this discussion, we'll focus on the steps outlined in the Process of Attack Simulation and Threat Analysis (PASTA) methodology. PASTA stands out among several methodologies for threat modeling as one of the most applicable and comprehensive. While I’ve witnessed organizations with niche and specific requirements adopt alternative methodologies in the past, PASTA emerges as a newer methodology with benefits that surpass many of the previous options.
Step 1 - Define the objectives: Identifying and clearly defining the compliance and security requirements for an application is the most critical step. During the initial stage of threat modeling, it's essential to identify the following types of objectives. Notice that these objectives are specific to an organization and encompass frameworks and standards applicable to technology, data, and processes. They should be tailored to the needs of the application being modeled.
Step 2 - Identify the components: Breaking an application down into components enables the identification of specific technical risks. While enhanced cybersecurity training programs have helped address the risks that fall into the social and physical domains, these exploits still need to be executed against a technical component at some point. The more thoroughly decomposed the components of an application are, the more accurately a model can articulate the potential threats and associated attack vectors.
Step 3 - Decompose the application: The primary objective of this step is to establish context. While you may already have a technical topology of your application following the identification of its components, you can enhance your ability to recognize threats by layering in the context of what the application is doing.
Step 4 - Analyze threats and identify vulnerabilities: While these are typically individual steps, they share common ground when determining the effectiveness of a model. During this stage, threats to a particular application and its data are assessed, and underlying vulnerabilities corresponding to those threats are identified.
Step 5 - Attack analysis: Determining the feasibility of an attack allows you to determine what actually needs to be addressed or mitigated. The most common approach involves mapping individual threats along the chain of vulnerabilities that could be exploited to achieve a breach or denial of service.
Step 6 - Risk and impact analysis: This is the stage where we truly gauge the success of your threat model. What does a well-crafted threat model look like once it's finalized? Does your comprehensive list of mappings of assets, data, tech, threats, and vulnerabilities translate effective mitigations?
It's important to recognize that completing a thorough and comprehensive threat model is just one component of a broader secure software development lifecycle (SSDLC). While identifying threats is essential, the risks persist until technical or other controls are implemented. While threat modeling can shift much of the risk assessment and mitigation left and allow for a more secure application design, it does not alleviate critical SSDLC operations like continuous compliance, Static Application Security Testing (SAST), or Dynamic Application Security Testing (DAST). However, a well-executed threat model can significantly enhance performance on these benchmarks and uncover threats and vulnerabilities not detected elsewhere.
If you are looking to move towards a SSDLC, our experts are here to help. Contact Concord to learn more about the steps you can take to improve the security of your organization.
Not sure on your next step? We'd love to hear about your business challenges. No pitch. No strings attached.
