Executive Summary
Threat modeling is a methodology to assess the risk and consequences of the security threats faced by your product. During the design and planning phase, threat modeling encourages defense-in-depth and structurally sound security controls. During execution, threat modeling encourages developers and security engineers to work on the most severe risks where the greatest marginal gains can be found. Threat modeling at every phase of the DevSecOps lifecycle gives you the greatest chance of anticipating and defending against the most severe threats.
Why Threat Modeling Works
When an engineering organization identifies and remediates a vulnerability in one of their products, it is often useful to conduct a root cause analysis. Was there any structural shortcoming that made this vulnerability (and vulnerabilities like it) more likely? Even when the root cause is of a more pedestrian nature, performing a root cause analysis can get the right people thinking about potential threats they may not have previously considered. Could a newly proposed dependency introduce unexpected security issues? What implicit assumptions are being made by legacy code and components? What is the actual risk posed by a hypothetical change to the product’s supply chain?
Of course, it also makes sense to ask these questions before latent vulnerabilities are found. This is essentially what is meant by threat modeling. Threat modeling consists of taking a holistic view of a product’s business functions, making deductions about what can potentially go wrong, and deciding how these threats can be most effectively mitigated.
Threat modeling often occurs in the context of a formalized methodology. Various methodologies exist; early examples include the STRIDE and DREAD methodologies from Microsoft. STRIDE and DREAD are geared toward categorizing threats and assessing the associated risk. Other methodologies are more comprehensive, providing a means of generating potential attack paths and reasoning about how these attack paths could impact specific business assets.
To some extent, engineers already do these things implicitly. The problem with an ad-hoc approach is that it tends to result in omissions, which is why Praetorian advocates a more formalized approach. After an organization has decided to take a formalized approach to threat modeling, it’s reasonable to ask: When should we do this?
Why you should always be Threat Modeling
An easy way to answer this question is to say that you should always be threat modeling. What does that really mean, and how can busy engineering and product teams fit this into their workflow?
At Praetorian, we think it makes sense to conduct a holistic, top-to-bottom threat modeling exercise when certain benchmarks are met. Some examples include:
- After a major new set of features has been planned
- After development on these features has concluded
- Prior to acquisition or regulatory approval
In some cases, threat modeling exercises should be conducted alongside a security assessment that incorporates active testing.
In addition to these top-to-bottom exercises, organizations should also look to update their threat models on a continuous basis throughout the DevSecOps lifecycle. These continuous efforts are less comprehensive, but they also pose less of a burden in terms of time and effort. When successful, they can help an organization understand the security implications of adding a particular feature or modifying a particular process.
This is another occasion when a formalized threat modeling methodology can be useful. Praetorian often uses the PASTA threat modeling methodology (“process for attack simulation and threat analysis”). Praetorian finds the attacker-focused PASTA methodology to be particularly effective, as it allows us to take advantage of our red team expertise during the threat modeling process. PASTA also uniquely incorporates business risk analysis, expanding cybersecurity awareness beyond traditional technical roles.
For example, given a proposed feature, the organization can generate corresponding threats based on industry trends, threat intelligence, analysis of relevant application logs, and subject matter expertise. Threats can be characterized by risk level and existence of a corresponding attack path that compromises a critical asset. The organization should also judge the plausibility of these attack paths, taking existing mitigations into account.
Each threat generated during the exercise can be submitted into the engineering team’s ticketing queue, with priority based on the assessed risk level. If the threat has a technology-oriented resolution, the ticket can be linked to stories that mitigate or neutralize the threat. Threats with a process-oriented resolution can be marked accordingly. Methods such as these help to ensure that threat modeling results in concrete, measurable improvements to the product. These methods also provide clear documentation on decisions made in the design of new features.
Threat Modeling and Security Assessments
Threat modeling can be an excellent way to reason about the risks facing a product and the security controls necessary to mitigate these risks. A comprehensive threat model can also be useful in the context of a security assessment. At Praetorian, we consider a product’s threat model when deciding how to allocate resources during a security assessment. If a specific mitigation is being used to “cover” a critical asset from exposure, then we can allocate proportionally higher effort to testing that mitigation—and the product’s threat model can guide these decisions.
Conclusion
The PASTA methodology has been useful to Praetorian in part because it resembles the thought process of a realistic attacker. As a general rule, attackers think in terms of assets they’d like to obtain, control, or disrupt. Security organizations should keep these assets in mind when reasoning about risks, and let the resulting threats drive risk prioritization. This prioritization should be woven into new features as early as possible, such that security and functionality both have the same proactive role in driving development.
Some security organizations take a more reactive approach, trying to assess whether a particular feature is or is not sufficiently secure. Both approaches have defensible characteristics, and both approaches have resulted in commercially successful products. Nevertheless, rising levels of abstraction in the technology stack and increasingly bold, motivated attackers are making it harder to justify any approach that does not include good security from the start and throughout the DevSecOps lifecycle. Praetorian encourages security organizations to take the proactive, attacker-driven approach as much as possible—and hopes you see the next major attack path before the adversaries do.
