Threat modeling has undergone a metamorphosis of sorts in recent years. We’ve seen more recent approaches to threat modeling move to include DevSecOps, putting a greater focus on developers as a critical arm of cybersecurity. Additionally, we have seen modern threat modeling pull away from a reliance on security professionals looking at finished products, instead asking engineering to embrace the concept of security as code.
All of these changes are important, and are meant to help us get back to the “why” of threat modeling. Once we all agree on the “why”, I believe we can find a better way to execute it.
So, why threat model to begin with? I see four key reasons for organizations to engage in threat modeling:
- Engineering teams are laser-focused on designing for use cases, not abuse cases. If you’re not constantly thinking like an attacker, your perfectly functional software is likely vulnerable in ways you don’t know about.
- It is becoming increasingly mandatory by regulatory bodies such as the FDA, and more will surely follow suit.
- It serves as evidence of due diligence when you’re inevitably asked for it. You never want to be the one that doesn’t have the answer to “did we know about this weakness?”
- “An ounce of prevention is worth a pound of cure”. Remediating vulnerabilities after they’ve been introduced (or worse, exploited) is extremely expensive and time-consuming. Designing for security from the outset is the best way to avoid unexpected costs, delays, and reputational/financial losses.
How threat modeling “has always been done”
Typically, a series of meetings are held between software architects, senior engineers, and members of the security team to collectively brainstorm possible threats and start to identify appropriate countermeasures. These countermeasures, however, rarely contain an appropriate level of detail for developers to follow.
One example of this would be a directive like “Ensure app isn’t vulnerable to DOM-based XSS”. An experienced developer may know exactly what to do based on this headline alone, but security-conscious organizations can’t afford to make that assumption for their entire engineering staff. General statements that can be interpreted multiple ways or have context-specific implications can end up not addressing the core problems at all.
Another problematic factor is that the term “threat modeling” is somewhat of a misnomer. Its intention has always been more about achieving an ideal security posture for a system than intently analyzing every possible threat. We’ve also recently seen threat modeling start to become more tied-in to privacy and compliance, which has greatly expanded its scope and impact. Nonetheless, shifting to a more developer-focused philosophy will help improve all of these areas without wasting resources.
A more modern approach to threat modeling
Modern threat modeling takes a more holistic and developer-focused approach than the practice’s origins. In order to facilitate this shift, it’s important that developers think of their systems as a house, and themselves as a homeowner. Hostile actors often look at old systems or code built years ago that haven’t been updated to newer security standards. This is essentially a window for the attackers to climb through. When you leave your home, you don’t lock and deadbolt the door but keep all your windows open. Good threat modeling forces a comprehensive look at all of a system’s components and functionality from many perspectives.
Does the developer’s focus mean that the roles of security professionals have become obsolete? Of course not. Sticking with the home security analogy, if you need to install a stronger door or a different lock but don’t know how, who do you go to? For some companies, their developers will be sufficient. Unfortunately, most businesses do not have equal security domain knowledge across their development teams. This means security professionals would likely need to be retained to offer guidance and help ensure the scalability and actionability of the threat modeling, not unlike hiring a contractor to install that new door or deadbolt.
All companies need to threat model, but may need to approach it from different ways. A startup may need to build from the ground up with security-minded developers. Larger corporations, however, need full-time security professionals to help streamline their processes and ensure scalability. Regardless of the approach, it’s important to understand the required resources so the parties involved have the support they need to correctly complete their tasks in a timely manner.
Where to start
A good place to start is for security leadership to analyze the delta between the needs and current capabilities of the company in order to prioritize projects. Once that’s been done and practitioners get to work, leadership must review the scope and scale of the models being produced to ensure not only completion and accuracy, but actionability of the outputs. Communication is critical throughout the entire process, especially as it pertains to instructions being given to developers so there’s no confusion when it comes time to implement.
While the exact threat modeling process and philosophy will vary between organizations, they all boil down to thinking like an attacker to protect an asset and its contents. Threat modeling is always evolving, and companies need to evolve with it to ensure they have the best level of protection from hostile actors looking for an easy target or an unlocked door.
