Threat modeling has long been hailed as an essential practice, a cornerstone for creating secure applications. Most people in the industry agree with this sentiment. However, when asked how they implement it, they are often still working to figure it out.
So, I turned to LinkedIn to hear how the general appsec community is experiencing threat modeling and how they are tackling the complexities of building a process.
This is the result of my conversations.
The High-Level: Why Your Corporate Culture, Tech Debt, and Risk Posture Matter
First, the bedrock of any successful threat modeling strategy is intrinsically linked to your organization's culture. No strategy can take off if the corporate environment doesn't place a premium on security. Here's another twist: a comprehensive approach should also factor in the organization’s technological debt and risk posture.
Is your organization genuinely invested in security, or is it just lip service? Your answer to this question will likely determine the efficacy of your threat modeling initiatives.
I derived five keys to successful threat modeling strategies.
Key 1: Linking Threat Modeling to Business Success
So, how do you move from theoretical security aspirations to tangible results? Start by anchoring your threat modeling activities to the business objectives. Make it relatable and an enabler for the company’s long-term goals. Ask yourself: Are your threat modeling activities quantifiable? Are they contributing to your key performance indicators (KPIs)? You're essentially operating in the dark if you’re not measuring your efforts.
But it’s not just about numbers. Consider the quality of your threat models and the mitigations implemented as a result. These factors offer a more nuanced understanding of your program's true impact.
Key 2: Adopt an Integrated and Incremental Approach
Being agile isn't just a buzzword; it's a survival skill in the ever-changing landscape of cyber threats. You can't afford to freeze your threat modeling in a large, unmanageable Data Flow Diagram or architectural outline. The approach must be agile, integrated into your software development lifecycle, and designed for evolution. And here's the kicker: It’s not where you start; it’s where you aim to end up that counts.
That's not to say threat modeling should exist in isolation. Supplement it with other security practices to ensure a well-rounded, resilient strategy. Guidance like OWASP’s Software Assurance Maturity Model (SAMM) can offer valuable insights here.
Key 3: Keeping Your Threat Models Up-to-Date
Remember, outdated threat models are like expired medicine: ineffective and potentially harmful.
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.”
So, are you relying on dated diagrams or actual, real-time system telemetry? Continuous updates to your threat modeling framework are non-negotiable.
Key 4: Keep it Simple and Holistic
Here’s where many of us miss the mark: Threat modeling isn't a one-and-done activity. It should be iteratively revisited throughout the development and operational phases. The key is to keep it simple yet holistic, seamlessly integrating it into your design process.
Key 5: Focus on the Right Problems
And let's not forget about focusing on the right problems. While covering the broad strokes is essential, automated approaches can't detect domain-specific threats effectively. That’s where human expertise comes into play by zoning in on unique vulnerabilities like privilege escalation.
Anton Abashkin shared what threat models should focus on, “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: The Five-Step Strategy
Here are the five steps for a comprehensive threat modeling strategy.
Make it relatable and measurable by tying it to business success.
Be agile, integrated, and incremental.
Keep it current, always.
Keep it simple
Focus on the right problems
By adhering to these five core principles, you’re not just adopting a strategy—you’re embracing a philosophy. After all, the absence of strategy is a strategy of its own, just not one that will end well for your security posture. So why leave it to chance?
Special thanks to the experts and contributors who inspired this article, Iswarya Subramanian Balachandar, Kuldeep Kumar, Abdoulkader Dirieh (Abdo), Rob van der Veer, and Tony Turner. Their collective wisdom adds immeasurable value to our journey toward better security practices.