When it comes to measuring and communicating threats, 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 not clear.  What was the difference 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 even admitted that the color-coded system presented “little practical information” to the public

While the DHS has never really provided meaningful threat levels, in Threat Modeling: Designing for Security, author Adam Shostack (full disclosure:  Adam and I are friends) 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 bureaucrats and Federal agencies define threats, the book details a formal system in which you can understand and particularize the unique threats your organizations faces.

In the introduction, 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.

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 will 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 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 is not 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. 

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.

Amazon has over 800 Disney World guide books.  Anyone who is going to invest their time and money to spend a few days at Disney World knows they have to do their research in order to get the most out of their visit.

There are only a handful of books on this topic and this is perhaps the finest of them.  No tourist would be so naïve to go to Disney World uninformed.  And conversely, no one should go into the IT world without adequate threat information.

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. 

978-1118809990