It’s particularly gratifying to see that the work is standing the test of time.
My thanks to the judges, most especially to Gastón Hillar for the constructive criticism that “Unluckily, the author has chosen to focus on modeling and didn’t include code samples in the book. Code samples would have been very useful to make the subject clearer for developers who must imagine in their own lines of code how some of the attacks are performed.” He also says “Overall, this is an excellent volume that should be examined by most developers concerned with issues of security.” The full review is at “Jolt Finalist: Threat Modeling.”
I’m planning to be on the East Coast from June 16-27, giving threat modeling book talks. (My very popular “Threat Modeling Lessons from Star Wars.”) I’m reaching out to find venues which would like me to come by and speak.
My plan is to arrive in Washington DC on the 16th, and end in Boston, flowing generally northwards. We intend to nail down a schedule on May 15th, so please be in touch by then.
If you are along that path, and would like me to come speak on threat modeling, please let me know by emailing firstname.lastname@example.org. I’m working with Erika of VACreatively to help me organize things.
We look forward to hearing from you and are happy to answer questions you might have.
One very important question that’s frequently asked is “what about threat modeling for operations?” I wanted to ensure that Threat Modeling: Designing for Security focused on both development and operations. To do that, I got help from Russ McRee. For those who don’t know Russ, he’s a SANS incident handler as well as a collegue at Microsoft, where he
beat me about the head and shoulders made the case for the importance of threat modeling for operations. Those conversations led to me helping out on the “IT Infrastructure Threat Modeling Guide.”
Russ had an official role as “Technical Proofreader,” but that understates what he did. What he did was make sure that infrastructure and operations got a full and fair treatment, and the book is better for his help.
There’s an important interplay between threat modeling for developers and threat modeling for operations. The threats are the same, but the mitigations are functionally different. There are mitigations which are easy for developers which are hard or impossible for the operations, and vice versa. The simplest example is logging. It’s really hard to add logging without changing the source. But reading the logs? There’s no way for a developer to ensure that that happens. Someone in operations has to decide what logs are important and relevant. Good threat modeling can elicit the threats, and lead to the early creation of a security operations guide, making explicit who needs to do what.
(I don’t mean to ignore the rise of devops, but even in that world, it can help to think of different types of mitigations.)
When Wiley asked me about a technical editor for Threat Modeling: Designing for Security, I had a long list of requirements. I wanted someone who could consider the various scenarios where threat modeling is important, including software development and operations. I wanted someone who understood the topic deeply, and had the experience of teaching threat modeling to those whose focus isn’t security.
More, I wanted someone who I respected for their depth of experience, where I wouldn’t be tempted to ignore comments which were tough to address or required me to rewrite a chapter late in the process.
And Chris Wysopal was the perfect guy for that. His background includes time at the L0pht, so he knows how to think like an attacker. While he was at @Stake, he delivered threat modeling as a consultant, and helped companies (including Microsoft) learn to threat model. And at his most venture, Veracode, he’s bringing secure development technology and services to a wide range of companies.
So I’m thrilled that we were able to work together on this book.
I am super-excited to announce that my new book, Threat Modeling: Designing for Security (Wiley, 2014) is now available wherever fine books are sold!
The official description:
If you’re a software developer, systems manager, or security professional, this book will show you how to use threat modeling in the security development lifecycle and the overall software and systems design processes. Author and security expert Adam Shostack puts his considerable expertise to work in this book that, unlike any other, details the process of building improved security into the design of software, computer services, and systems — from the very beginning.
- Find and fix security issues before they hurt you or your customers
- Learn to use practical and actionable tools, techniques, and approaches for software developers, IT professionals, and security enthusiasts
- Explore the nuances of software-centric threat modeling and discover its application to software and systems during the build phase and beyond
- Apply threat modeling to improve security when managing complex systems (or even simple ones!)
- Manage potential threats using a structured, methodical framework
- Discover and discern evolving security threats
- Use specific, actionable advice regardless of software type, operating system, or program approaches and techniques validated and proven to be effective at Microsoft and other top IT companies
Threat Modeling: Designing for Security is full of actionable, tested advice for software developers, systems architects and managers, and security professionals. From the very first chapter, it teaches the reader how to threat model. That is, how to use models to predict and prevent problems, even before you’ve started coding.
Threat Modeling: Designing for Security is jargon-free, accessible, and provides proven frameworks that are designed to integrate into real projects that need to ship on tight schedules.
For more information, I’ve set up a small book website: threatmodelingbook.com.
Amazon has Kindle edition, and is saying that the paperback will ship in “9-11 days.” I believe that’s startup issues in getting the books to and through the warehousing system, but don’t know details. I will be having a book signing at RSA, Wednesday at 11 AM in Moscone South. (iCal reminder.)
In light of me already spending time on what to put on which blog, but more importantly, not wanting readers to have to subscribe to three blogs, I’ll be blogging about threat modeling here on New School.
Five years ago Friday was the official publication date of The New School of Information Security. I want to take this opportunity to look back a little and look forward to the next few years.
Five years ago, fear of a breach and its consequences was nearly universal, and few people thought anything but pain would come of talking about our problems. Many people found it shocking when we challenged best practices, or asked if there was evidence for the ways we invested in security. I’d like to think we played some small role in how the culture of information security has changed. I’m hopeful that culture will continue to evolve in ways that focus on outcomes and data about those outcomes. At the same time, as I reflect, I go back to what Andrew and I wrote.
We wrote that the New School of Information Security is:
We’ve seen tremendous movement in the sharing of objective data. From the DBIR to Mandiant’s report to revelations from Google, RSA, Bit9 and many others, we see people willing to talk about what went wrong. Sure, they sometimes add some spin, but that’s human nature. We’re seeing data being shared, or as I now like to say, published. We can’t take credit for that. Lots of people did a lot of hard work to convince their organizations to publish that data, and we’re learning from it and collections like the Open Security Foundation’s dataset.
We’ve also heard from countless folks about how much they liked the book, how it’s influenced their thinking and their actions, and that’s been a wonderful return on our work.
What we haven’t seen as much of is learning from other professions, such as economics and psychology. It’s still to common to complain that people will click on anything, we still argue with a paucity of data about if training people makes any sense. (Although if you have any data, I’d love to get it some attention at BlackHat.)
We also haven’t yet seen a lot of published data on the effectiveness of various security investments. As far as I know, no compliance regime yet requires breached entities to report back to those who create the standard about what went wrong, perpetuating the wicked environment in which we work, and wasting the time and money of those who need to comply.
Sadly, the pervious two paragraphs relate to what we wrote in chapters 5 and 6. For those of you who enjoyed the book, let me ask you to re-read them. For those of you who haven’t yet read it, now’s a great time. [Update: Even better, Addison Wesley is offering 40% off with code NEWSCHOOL40 to help us celebrate! Apply the code after proceeding to checkout.]
Andrew and I remain optimistic that our world can get better, and we’re proud to have helped illuminate a path forward.
Last week I did a podcast with Dennis Fisher. In it, we touched on what I might change in the book. Take a listen at: “Adam Shostack on Methods of Compromise, the New School and Learning“
Last Sunday, I did a book reading at Ada’s Technical Books. As I say in the video, I was excited because while I’ve talked about the New School, and I’ve given talks about the New School, I hadn’t done a book reading, in part because of the nature of the book, and my personal comfort zone in promotional activity. Since Ada’s is just getting started on taking video, the quality of the recording isn’t super-high, but the conversation afterwards is great stuff.
Thanks to Danielle for inviting me, and I’d be happy to do more readings in the future.