Threat modeling in the name of security

Published: 2014-02-19
Last Updated: 2014-02-19 17:14:12 UTC
by Russ McRee (Version: 1)
0 comment(s)

I'm sure hoping you've read headlines recently; there's so much to work with here. :-)
As indicated in ISC Diary coverage of the Linksys worm referred to as The Moon, as well as a KrebsonSecurity discussion of a plethora of other vulnerable hardware, threats are everywhere. And as the Internet of Things leads us to pwned refrigerators and home automation gone amok, its time to revisit one of my favorite topics: threat modeling.
Further, Adam Shostack's Threat Modeling: Designing For Security is now available via Wiley and online book sellers. If you plan to be at RSA, Adam will be speaking at RSA on New Foundations for Threat modeling (Wednesday, 26 FEB, at 9:20)
Why should you consider threat modeling for your computing and technology-centric environments? Threats abound, and there are no more important reasons than the viability and reputations of your organizations. The consequences of a successful cyberattack would almost certainly affect your organization's ability to conduct its day-to-day business operations. Ask the Navy how it feels about the four months and $10 million dollars it took to get the Iranians off the Navy Marine Corps Intranet. If such attacks lead to exposure of confidential information, your organization is likely to be perceived as one that failed to do what was necessary to protect itself, which in turn can affect the ability to conduct business in the future. Failure to protect customer information could subject your organization to legal liabilities and potentially significant fines. Imagine the possible cost to Target if you use the approximate $200 cost per exposed customer record x 110 million (40 million, then 70 million) records alleged to be in play in some for or fashion as a result of the Target compromise.
Threat modeling allows you to determine what threats exist that could affect your organization's computing infrastructure, helps you identify threat mitigations to protect resources and sensitive information, and helps you prioritize the identified threats so that you can manage your security efforts in a proactive manner.
Sound like a good plan right? I'm now leading an entire team dedicated to this cause at Microsoft; after having written the IT Infrastructure Threat Modeling Guide in 2009 (revision pending in the March/April timeline) it's finally been agreed that threat modeling and assessment is a natural fit for the practice of Threat Intelligence (data science) & Engineering (build mitigations).
The fortuitous timing of Adam's book release is not lost on me as I engage this recent new work assignment, Threat Modeling: Designing For Security is, in essence, the bible for our practice. I was honored to be the Technical Proofreader for this book which gives me the opportunity to provide you with a few insights with the hope of inspiring you to read it and embrace threat modeling broadly.
Quoting Adam directly, "This book is written for those who create or operate complex technology. That’s primarily software engineers and systems administrators, but it also includes a variety of related roles, including analysts or architects. There’s also a lot of information in here for security professionals, so this book should be useful to them and those who work with them. You will gain a rich knowledge of threat modeling techniques. You’ll learn to apply those techniques to your projects so you can build software that’s more secure from the get-go, and deploy it more securely. You’ll learn to how to make security tradeoffs in ways that are considered, measured, and appropriate and you will learn a set of tools and when to bring them to bear."
Adam asks you to consider a set of related questions that are essential to threat modeling:
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?

If you embrace these as you mature your threat modeling practice you will maintain perspective throughout. Thinks about those questions as you ponder the interconnectedness of so much of modern technology. Do you need to threat model your brand new refrigerator or Internet connected lighting controller? Yeah, prpbably a good idea. What could possibly go wrong?
The well known STRIDE mnemonic (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) remains entirely viable, integral, and omnipresent but other modeling tactics are described in the book too. We've also incorporated Allegro Octave, as well as DREAD, OWASP, CVSS, and others risk assessment methods as part of threat assessment tactics, techniques, and procedures (thank you SimpleRisk).

Your action items are simple: read up on threat modeling, begin to threat model as part of your regular information security focuses, apply mitigations to the findings, and admire your handiwork as threat vectors are diminished. If you have any questions on this front please reach out directly or drop comments here.

Keywords: threat modeling
0 comment(s)


Diary Archives