Book Review: Threat Modeling: Designing For Security 32
benrothke writes "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 not clear or intuitive. What exactly 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 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." Read below for the rest of Ben's review.
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 organizations faces. | Threat Modeling: Designing for Security | |
| author | Adam Shostack |
| pages | 624 |
| publisher | Wiley |
| rating | 10/10 |
| reviewer | Ben Rothke |
| ISBN | 978-1118809990 |
| summary | Invaluable guide to create a formal threat modeling program |
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.
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 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.
For those that still think the topic is complex, the book references Elevation of Privilege (EoP), an easy way to get started 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.
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 Threat Modeling: Designing for Security 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.
Reviewed by Ben Rothke.
You can purchase Threat Modeling: Designing for Security from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:now, if someone could handle the weather warnin (Score:5, Informative)
The irony is, you have it completely backwards. From AccuWeather [accuweather.com] (and any other source):
"Watches, like severe thunderstorm watches and tornado watches, which are two of the most common types, are issued when weather conditions are conducive for the event to occur,"
"Warnings are different. A warning is issued when the weather event is happening now," Pigott said. "In terms of flooding, for instance, a flood warning means a river has spilled over or flash flooding is occurring."
"Basically, a watch means atmospheric conditions are right for it to happen. Warnings mean it's actually happening," Pigott said.