TOTAL: {[ getCartTotalCost() | currencyFilter ]} Update cart for total shopping_basket Checkout
PrivacyTraining_ad300x250.Promo1-01
DPC17_WebBanner_300x250-COPY
PSR17_WebBanner_300x250-COPY

For the privacy professional who lacks an engineering or computer science background, an invitation to read a book with the title Threat Modeling: Designing for Security may well provoke an urge to run the other way. That was certainly my first inclination, but I’m glad I overcame it. This book has a lot to offer the threat-modeling neophyte as well as the sophisticated programmer.

The author, Adam Shostack, is a program manager at Microsoft who develops security processes and attack models. He’s also a very able writer and has even developed a card game, "Elevation of Privilege," which is available for free online, to teach threat modeling.

If you’re like me, the first question on your mind is, "what the heck is threat modeling?” Shostack eases the reader into the concept by asserting, “Everyone threat models.” He gives the example of when you’re speeding down the highway and anticipating the “threat” of a police car lurking on a side road.

In the online world, threat modeling involves two types of models, says Shostack. There’s the model of what you’re building, e.g., a website, a program or an app, and there’s a model of the threats, or what can go wrong. In a nutshell, threat modeling is the analytical process of figuring out what might go wrong with the thing you’re building.

Although the reasons to threat model might seem self-evident, Shostack takes pains to explain them. They include:

  • Finding security bugs early, even before a line of code is written. He compares the process to designing a house, where early decisions, for instance, including lots of ground-level windows, will have a dramatic effect on security. Anyone familiar with Privacy by Design will readily see the analogy here.
  • Understanding what security is required. As you think about threats, you think about what security is appropriate to meet those threats, and that flows into design decisions.
  • Engineering and delivering better products. Not only will consumers buy and be happier with more “threat-proof” products, but you can avoid, or at least minimize, a cycle of bug fixes and redesigns and the bad publicity that can follow by dealing with security issues at the outset.

The book’s observations are often provocative. For instance, Shostack disagrees with the “think-like-an-attacker” exhortation, saying that such thinking “may lead you to focus on the wrong threats.” He also emphasizes that some threats can’t be effectively mitigated, which he admits is a painful thought for many security professionals.

Shostack offers an elegant structure for approaching threat modeling by focusing on four simple questions. First you must ask, “What are you building?” and “What can go wrong?” Then, you must determine, “What can you do about the things that can go wrong?” The final question is, “Did you do a decent job of analysis?”

For those with the technical background to follow him, Shostack gets much deeper into the weeds, exploring such topics as trade-offs when addressing threats, e.g., a design change to enhance security may hinder usability; how to validate that threats have been addressed, and specific tools useful for threat modeling. There is a practical bent throughout. For instance, Shostack leads off his discussion of threat-modeling tools by talking about the trusty whiteboard.

Although Shostack’s focus is naturally on security, he doesn’t ignore privacy concerns. His chapter on threat modeling for privacy covers such tools as Daniel Solove’s taxonomy of privacy harms, privacy impact assessments and the “Nymity Slider” developed by Ian Goldberg, which provides a sliding scale of how much information about a person’s identity is revealed by a particular transaction, from “verinymity,” e.g., using a credit card, to “unlinkable anonymity,” e.g., cash payments. Shostack acknowledges, however, that threat modeling for privacy involves judgment calls not required in the security context. Not only do people have very different perceptions of what privacy is, but the designer of a website or app may view lack of privacy not as a threat but as a marketing opportunity—the more personal data collected, the better.  

Even if you’ve never coded a line of software in your life, and you don’t know spoofing from a denial of service attack, you’ll have an excellent understanding of what threat modelers do, and why it’s important, after reading this book.

1 Comment

If you want to comment on this post, you need to login.

  • comment Annie • Sep 2, 2014
    A good review.  I am persuaded, will read it.  Thanks.