What Makes a Good Threat Model?

Implementing the PASTA methodology can help you identify vulnerabilities and build a secure application design.

What exactly is a threat model?

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. 

What should I look for in a 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.

• External regulations: HIPAA HITECH, PCI-DSS, FIPS 140-2
• External frameworks: NIST, CIS, ISO
• Internal standards: .Net baselines, Java security, virtual machines and container security baseline templates, authentication standards, network standards
• Other: Results from continuous compliance scans or pen testing

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.

• Vendor-specific
• Inclusive of all layers, such as:
  • Cloud or server components
  • Operating systems and languages utilized
  • Supported client types
  • Individual libraries
  • Integrated or dependent capabilities (e.g., identity providers, gateways)

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.

• Protected data is identified where stored and transmitted.
• Network segments are identified and mapped around the components and data.
• Trust levels are identified and mapped around protected data and actions. It’s worth noting that while a role-based access control strategy may not be necessary or commonly implemented at this stage, it is important to acknowledge where one will be needed for protected data and actions.

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.

• A threat library should be inclusive of multiple sources, which maps back to defining the objectives. Does the content in the threat library correspond with the specific standards and frameworks chosen as objectives?
• An exceptionally mature threat model may include individual contributions. Logs and previous results from scans and pen tests are a great place to start.
• Similarly, a vulnerability library should draw from multiple sources and map back to the standards identified as objectives for the application.
• Look for scoring. Likelihood by severity is a common scoring metric, but it may not always reflect the priority for every use case. Individual assessments by those most familiar with the application are welcome at this stage.

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.

• A threat and vulnerability library used for assessment should include a detailed mapping of chained vulnerabilities up to the parent threat.
• You can choose to utilize a popular multi-sourced library based on a framework like MITRE ATT&CK (https://attack.mitre.org/).

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?

• Ensure that all identified threats and vulnerabilities are directly mapped to corresponding mitigations.
• The mitigations should be tailored to the specific technology involved, and the responsible technical parties should have confidence in their ability to implement them.

The bigger picture  

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.