Debunking Three Common Threat Modeling Myths

The benefits of threat modeling are significant. Not only does it provide a systematic process for evaluating potential threats to an organization’s system, but it also creates a framework for informed decision-making, ensuring the best use of limited resources.

Despite threat modeling existing as a proven way to mitigate risk, in 2021, we saw a record number (1,862) of data breaches in the U.S.; a number that broke the previous record of 1,506 breaches from 2017. Even in the face of the increasing severity of data security threats, many organizations still avoid threat modeling altogether. I believe this is because of a few common misconceptions that, when you look closely, highlight a need for further industry examination on how companies are approaching threat modeling today.

1. Myth: Only Security Experts can Complete a Threat Model

Many developers have historically hated threat modeling because they see it as a time-sink that doesn’t help them ship code faster. They spend hours participating in sessions they feel they don’t get value from, which often result in a vague, unactionable laundry list of threats and mitigation ideas they simply don’t have time to prioritize and analyze.

They also question how much value they really bring to the process, given they’re not security experts. However true that might be, they are engineering experts. They know their system better than anyone. With the right tools and processes in place, it is possible to leverage their expertise and bring value in a way that reduces reliance on the security team. But why should they want to?

Modern engineering teams are quickly realizing that assessing potential threats during the design phase of a project can save significant resources that might be needed during a later phase. When engineering’s mandate is getting code out the door and avoiding remediation, presenting this cost of inaction back to them can get the gears turning on how they can help. Put a tool in their hands that asks the questions normally asked in your traditional threat modeling sessions, and give them about 30 minutes to use it to the best of their ability. Then have your security experts check their work and add context. You (and they) will be amazed at how painless it is for everyone involved.

2. Myth: Threat Modeling Should Only be Performed by Specific Companies

If you’re a small company with a handful of applications, you probably know what your critical applications are. You know which ones handle sensitive data, and you know which ones you need to focus on first. At that point, having threat modeling that allows you to go deeper into your small pool of applications is probably how you want to approach it. This is because you generally have fewer things to worry about, and with the right tools, you can update those models more frequently.

But when you are a mega-large enterprise with tens of thousands of applications, you need to focus on scale, not depth. If you try to model every application at 100% level of depth, you simply won’t get enough of them done. Period. Unless you can hire every security architect under the sun, you will never get to 100% level of depth across your portfolio. So, you need to take a risk-based approach, using automation in a way that will allow you to cover as much of your portfolio as possible, at a reasonable risk-adjusted level of depth.

3. Myth: Threat Modeling Hasn’t Changed With the Times

Modern engineering requires modern approaches to security. A lot of traditional threat modeling methodologies were designed when application development looked very different. In the past, we were typically working in waterfall with single code bases which then moved into Agile with multi-layered architectures and, most recently, CI/CD with microservices. The complexity of how applications are designed and engineered today has exploded. If you still approach threat modeling the same way you did when apps were mostly monoliths built-in waterfall, the thought of it keeping pace with how you develop today probably seems impossible. Thankfully, there are several new ways to threat model which prioritize agility and scale while making minimal compromises on attention to detail.

We often see an all-or-nothing approach when it comes to threat modeling. Yes, you can go really deep with your threat model for highly critical apps, spending more manual time or reserving your security architect’s time. But for the other 90% of your portfolio, you shouldn’t be ignoring threat modeling altogether. It’s important to remember that a partially complete threat model is better than no threat model at all.

If your goal post for a complete threat model is hinged on a very long, in-depth manual analysis, you’re never going to cover enough of your portfolio for it to make an impact. Or your software is going to change at a rate that will make your threat models “dead” or “stale” in short order. Take a more scalable approach that has different definitions of “done” based on the risk level or criticality of the asset being modeled.

One of the best ways to do this is by leveraging automation—for instance, you can look at commonalities between different applications, their design patterns and the threats that most commonly result from them. You can save yourself a lot of time by getting something started, and it doesn’t have to be 100% in-depth on everything. You, and your organization’s security posture, will always be better off covering a higher percentage of your portfolio at a lower level of depth than a smaller percentage a mile deep, especially when scaling across hundreds or thousands of applications.

Avatar photo

Kevin Delaney

Kevin Delaney, Director of Solutions Engineering at Security Compass, has a diverse background in networking and security, and he has experience consulting with Fortune 500 companies on secure software development practices and system administration. Prior to joining Security Compass, Kevin worked for a SaaS startup in the data protection space. He started his first software business at age 14.

kevin-delaney has 1 posts and counting.See all posts by kevin-delaney