The Cybersecurity Canon: Threat Modeling: Designing for Security

Category: Cybersecurity


We modeled the Cybersecurity Canon after the Baseball or Rock & Roll Hall-of-Fame, except for cybersecurity books. We have more than 25 books on the initial candidate list, but we are soliciting help from the cybersecurity community to increase the number to be much more than that. Please write a review and nominate your favorite

The Cybersecurity Canon is a real thing for our community. We have designed it so that you can directly participate in the process. Please do so!

Book Review by Canon Committee Member, Ben Rothke: Threat Modeling: Designing for Security (2014) by Adam Shostack

Full disclosure: The author of the book and the reviewer are friends.

Executive Summary

When it comes to measuring and communicating threats, perhaps the most ineffective example in recent memory was the Homeland Security Advisory System, which was a color-coded terrorism threat advisory scale.

The system was rushed into use and its output of colors was neither clear nor intuitive. No one could really tell what the difference was between levels, such as “high,” “guarded” and “elevated.” From a threat perspective, which color was more severe – yellow or orange? Former DHS chairman Janet Napolitano admitted that it presented “little practical information” to the public.

While the DHS has never provided meaningful threat levels, in Threat Modeling: Designing for Security, author Adam Shostack has done a remarkable job in detailing an approach that is both achievable and functional. More importantly, he details a system where organizations can obtain meaningful and actionable information, rather than vague color charts.

Rather than letting clueless Washington bureaucrats define threats, the book details a formal system in which you can understand and particularize the unique threats your organization faces.


In the introduction to Threat Modeling, Shostack sums up his approach in four questions:

  1. What are you building?
  2. What can go wrong with it once it’s built?
  3. What should you do about those things that can go wrong?
  4. Did you do a decent job of analysis?

The remaining 600 densely packed pages provide the formal framework needed to get meaningful answers to those questions. The book sets a structure in which to model threats, be it in software, applications, systems, software or services, such as cloud computing.

While the term “threat modeling” may seem overly complex, the book notes that anyone can learn to threat model. Threat modeling is simply using models to find security problems. The book notes that using a model means abstracting away a lot of the details to provide a look at the bigger picture, rather than the specific item or piece of software code.

An important point the book makes is that there is more than one way to model threats. People often place too much emphasis on the specifics of how to model, rather than focusing on what provides them the most benefit. Ultimately, the best model for your organization is the one that helps you determine what the main threats are. Finally, the point is not just to find the threats; the key is to address them and fix them.

The beauty of the book is that it focuses on gaining empirical data around threats for your organization. Rather than simply taking an approach based on Gartner, USA TODAY or industry best practices.

While the author states a few times that threat modeling is not necessarily a complex endeavor, it, nonetheless, does take time. He writes that threat modeling requires involvement from many players from different departments in an organization to provide meaningful input. Without broad input, the threat model will be lacking, and the output will be incomplete.

For those organizations that are willing to put the time and effort into threat modeling, the benefits will be remarkable. At the outset, they will have confidence that they understand the threats their organization is facing, likely spend less on hardware and software, and be better protected.

Chapter 18 quotes programmer Henry Spencer, who observed that “those who do not understand UNIX are condemned to reinvent it, poorly.” Shostack writes that the same applies to threat modeling. The point he is making is that there are ways to fail at threat modeling. The first is simply by not trying. The chapter then goes on into other approaches which can get in the way of an effective threat modeling program.

Why should you threat model for your IT and other technology environments? It should be self-evident from an architecture perspective. When an architect is designing an edifice, they first must understand their environment and requirements. A residence for a couple in Manhattan will be entirely different from the design for a residence for a family in Wyoming. But far too many IT architects take a monolithic approach to threats and that’s precisely the point the book is attempting to obviate.

As noted, threat modeling doesn’t have to be overly complex. But, even if it was indeed complex, it is far too important not to be done. The message of the book is that organizations need to stop chasing vague threats and industry notions of what threats are and customize things so they deal with their threats.

For those who still think the topic is complex, the book references Elevation of Privilege (EoP), an easy way to get started with threat modeling. EoP is a card game that developers, architects or security teams can play to easily understand the rudiments of threat modeling.

Risk modeling is so important that it must be seen as an essential part of a formal and mature information security program. Having firewalls, IDS, DLP and myriad other InfoSec appliances can be deceptive in thinking they provide protection. But, if they are deployed in an organization that has not defined the threats these devices are expected to address, they only serve the purpose of giving an aura of InfoSec protection and not real protection itself.


Threat modeling provides compelling benefits in the ability to make better information security decisions, better focus on often limited resources, all while designing a model to protect against current and future threats.

For those serious about the topic, Threat Modeling: Designing for Security will be one of the most rewarding information security books they could hope for and a worthwhile entry into the Cybersecurity Canon.

This is an updated book review which original appeared on Slashdot.

Got something to say?

Get updates: Unit 42

Sign up to receive the latest news, cyber threat intelligence and research from Unit42