Application threat modeling has gotten a bad rap over the years. Security leaders looking to implement application threat modeling with their product teams must contend with stakeholders who see it as nothing more than a compliance checkbox and previous iterations that were overly formalized and heavyweight. As security pros sort through the conflicting frameworks and approaches to find an application threat modeling approach that is effective, efficient, and repeatable, they must also unpack their own biases about what makes a good threat model.

While researching my latest report, Build A Business Case For Application Threat Modeling, I spoke with security practitioners who helped clarify and debunk some of the most common misconceptions around application threat modeling. Here are three of them:

  • Myth: You must use a threat modeling framework. STRIDE and DREAD are the best-known threat modeling frameworks, with PASTA, VAST, LINDDUN, and others less well known — but familiarity does not equal adoption. Most of the people we interviewed did not use any of the standard frameworks, instead preferring whiteboarding, discussion, decision trees, or a more lightweight conversation based around understanding how a specific application functions. Even the authors of the “Threat Modeling Manifesto” declined to recommend a framework, describing their guidance as “methodology-agnostic.” Frameworks can have their uses, however, such as when your threat modeling initiative is led by less experienced security personnel or by developers who are new to security; in that case, a formal framework will provide guidance and structure. But don’t shoehorn in a framework. You can meet the goals of threat modeling without one.
  • Myth: You must conduct threat modeling differently for different types of applications. Whether you are modeling a monolithic application, a set of APIs, an internet-of-things device, an application deployed in the cloud, or an application deployed on-premises, the security practitioners we spoke with agreed that the threat modeling structure and process is the same. That’s good news for security leaders, who can apply a single threat modeling approach across all product teams. The most important questions asked during threat modeling — What does the product do? What data does it handle? What can go wrong? What can we do about it? — are architecture-, form factor-, and deployment-agnostic. The answers to those questions will vary depending on application type, but that doesn’t change how you conduct the threat modeling exercise.
  • Myth: If the threat model doesn’t identify every threat, the process is flawed. If you don’t set expectations around threat modeling’s goal, perfect can become the enemy of good. As with many security tools and processes, there can be an absolutist expectation that threat modeling will find every possible threat that will ever exist. The practitioners we spoke with stressed that threat modeling is about making the product better. Instead of labeling threat modeling a failure if it doesn’t find everything, use threat modeling as a “defense in depth” layer that helps identify and mitigate key security concerns early in the product lifecycle.

For more on this subject, please check out my latest report, Build A Business Case For Application Threat Modeling, or set up an inquiry or guidance session to discuss further. Also, if you will be attending Forrester’s Security & Risk Summit, please join me for my session, “‘The Not-So-Premature Burial’: Rethinking Application Threat Modeling” which is part of the Cloud & Application Security track at the summit.