A Comprehensive Threat Modeling Strategy
A challenge in threat modeling is developing a comprehensive strategy to effectively identify and mitigate potential threats in each system or application. How do you go about putting threat modeling into action? Anyone you ask these days will tell you that threat modeling is essential, but when I question how they are making it a reality, often they have yet to figure it out.
I took this challenge to LinkedIn to tap into the collective intelligence of the AppSec community. As I continue this journey deeper into threat modeling, gaining insight from people who have seen the world differently is helpful. Some people have experienced threat modeling in a different way than I have.
I used the feedback I received via LinkedIn to weave together a cohesive story. Listen until the end to hear the names of the folks that contributed concepts included within.
High-Level View
Let’s begin with a high-level view of a comprehensive threat modeling strategy: the critical factors in developing a threat modeling strategy are an organization’s culture, tech debt, and the current risk posture. Culture does drive what gets done in an organization, and a strategy must consider the current risk posture within the business. If a company doesn’t care, threat modeling will never be successful as a practice and discipline.
Link Threat Modeling to the Business's Success
The first key to threat modeling strategy is tying threat modeling to the business's success. Consider how threat modeling can act as an enabler for the company. Map threat modeling to the business's success for your program's long-term success. Another critical factor is defining key success metrics for the program. Measure the bulk of threat modeling or how many models are created over time. Also, measure the mitigations introduced due to the threat modeling exercise.
Use an Integrated and Incremental Approach
The second key is an integrated and incremental threat modeling approach. Perform threat modeling in an agile, incremental manner, baking it into your sprint planning and doing it in small chunks rather than one giant DFD and architectural diagram. It is not about where you start your threat model but where you intend to end up. Start with critical applications or components and gradually increase the scope of coverage.
To ensure that security is not relying on threat modeling only, combine it with a hardening approach to take care of basic 'security hygiene.' A good example of this is OWASP SAMM’s Agile Guidance.
Keep the Threat Model Up-to-Date
The third key is to keep the threat modeling inputs up to date. Jeff Williams shares, "Threat Modeling is only as good as the data. What are you relying on? Security observability telemetry from the actual running system? Or a broken-down Visio diagram from 3 years ago and whatever the newly hired developers happen to have gleaned. You must think of it as a process, not a document. Threat modeling runs continuously and adapts to new threats AND system changes.”
Manuel Walder shares a specific example: “If the system or component is already built and running, the reality of how a feature was implemented is likely far away from the documentation or the design decision done before coding. So, if I review a component, I only trust the running system's data flow and control flow analyses. A ZAP data flow dump can be a helpful starting point or alternative to outdated documentation and can even be the baseline to draw the DFD.”
Keep the Model Simple and Holistic
The fourth key is to perform holistic and simple threat modeling. Threat modeling should begin after high-level design to inform the detailed design and must be continuously revisited as the design evolves throughout the product's development, implementation, and operation phases. Despite potential changes in the threat model due to engineering workflows, it's crucial to ask threat modeling-related questions as design elements are conceived and planned, underscoring the value of threat modeling before finalizing any design.
Focus on the Right Things
The fifth key is to focus on the right things, which threat modeling is good at finding. Anton Abashkin provides context here about what to focus a threat model upon.
This a direct quote from Anton. “Something that isn't talked about enough is the distinction between domain-agnostic and domain-specific threat modeling. Threat modeling should focus on finding domain-specific problems. Domain-agnostic problems are much easier to identify using automated approaches that look for well-established risk patterns. An example of a domain-specific threat is privilege escalation.
Discussing domain-agnostic threats, such as cross-site scripting and SQL injection, can be helpful if penetration testing is the only security activity you’re doing today. On the other hand, if your developers are already aware of the dangers of SQL injection and you have other processes, such as static analysis, to detect SQL injection, then discussing SQL injection is not an effective use of time. The most effective use of time-crunched TME sessions (particularly those under two hours) is to discuss the kinds of threats that your existing tools won’t automatically detect."
Recap of the Five Points
To tie this whole thing back together, a comprehensive threat modeling strategy includes linking threat modeling to the business's success, utilizing an integrated and incremental threat modeling approach, keeping the threat modeling inputs up to date, performing holistic and simple threat modeling, and focusing on the right things, the things threat modeling is good at finding, or is they are also referred to as, the domain-specific threats.
Remember, not having a threat modeling strategy is a strategy all to itself.
Special thanks to Iswarya Subramanian Balachandar, Kuldeep Kumar, Abdoulkader Dirieh (Abdo), Rob van der Veer, and Tony Turner, whose thoughts and feedback were synthesized into this episode.
References:
- https://www.opensamm.org/2011/01/domain-driven-security/