by adam on May 1, 2014
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 email@example.com. 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.
by adam on April 23, 2014
Today, most presentations on threat modeling talk about each phase of the process. They talk about how to model what you’re building, what can go wrong, and what to do about it. Those tightly coupled processes can be great if you’ve never heard of an approach to threat modeling. But they can add to the challenge for those trying to execute the process. What knowledge and skills can they re-use, and what do they need to replace?
Two of the big ideas in Threat Modeling: Designing for Security are that there’s more than one way to threat model, and that we can and should compose them. We can move beyond every talk covering how to model, how to find problems, and how to fix them. And when we do that, we improve our ability to agilely engage with new approaches, because the cost of experimentation falls.
One such new approach is DIAL: Discovery, Incorrectness, Authorization/Authentication, Limits/Latency. It’s a set of ‘threats’ to reliability, being explored by my colleagues in Microsoft Trustworthy Computing’s Reliability team. DIAL is an interesting complement to security threat modeling, because it starts with a D which (of course) stands for Denial of Service in STRIDE. And that’s sort of neat.
Anyway, the blog posts are worth checking out:
- Reliability vs. resilience
- Categorizing reliability threats to your service
- Reliability-enhancing techniques (Part 1)
- Reliability-enhancing techniques (Part 2)
[Update: inserted “D” in the “starts with a ..” sentence. Thanks Mike for pointing out the error!]
by adam on April 21, 2014
It has to be said that no one in the Princess Bride is great at threat modeling. But one scene in particular stands out. It’s while they’re planning to attack the castle and rescue Buttercup:
Westley: I mean, if we only had a wheelbarrow, that would be something.
Inigo: Where we did we put that wheelbarrow the albino had?
Fezzik: Over the albino, I think.
Westley: Well, why didn’t you list that among our assets in the first place?
The trouble here is that Inigo and Fezzik don’t see a wheelbarrow as an asset worth listing. They know about it, but don’t bring it up. This is a predictable and even desirable state. When you model, you discard details that seem irrelevant. If you list absolutely everything, you end up sounding like the rain man, not an engineer.
Knowing what’s important enough to list is challenging. There’s no prescriptive guidance to what assets are worth including. (Because it’s challenging to know what’s a good list, there’s also no clear exit criteria or “gate.”)
Security experts love to complain that others have left things out. If you want to complain, you need to start with a clear definition of what’s an asset, what assets are important enough to list (A $10 wheelbarrow?), and what constitutes a good list. That’s simply easier with the technology that you’re threat modeling, rather worrying about assets.
by adam on April 17, 2014
George Hulme interviewed me for Devops.com, and the article is at “Q&A: Speaking DevOps and Threat Modeling.”
Its obvious that devops is an important trend, andit’s important to understand how to align threat modeling to that world.
by adam on April 15, 2014
A couple of reviewers have commented that they have different perspective on assets. For example, in a review I very much appreciated, Gunnar Peterson says:
I have slightly a different perspective on Shostack’s view on assets. The book goes into different views that launch the threat model, the approach advocated for in the book is very software-centric. I have no quibble on that, especially if you work for a software company. But for a financial institution, a supply chain, a healthcare company, I think it works less well to assume a software first view of the world. Its simpler in those companies to get traction by looking at the assets in play – accounts, confidential data, supplier access, and so on. for one thing, you can engage a wider portion of the organization. For another you have an easier time linking the resultant threats to a business impact.
The TL;DR response is consultants may like asset-centered approaches more than others, and the closer you are to the code, the less helpful they are. Previously, I wrote (page 39):
Focusing on assets appears to be a common-sense approach to threat modeling, to the point where it seems hard to argue with. Unfortunately, much of the time, a discussion of assets does not improve threat modeling. However, the misconception is so common that it’s important to examine why it doesn’t help.
There’s no direct line from assets to threats, and no prescriptive set of steps… That discussion, at best, results in a list of things to look for in your software or operational model, so why not start by creating such a model? Once you have a list of assets, that list is not (ahem) a stepping stone to finding threats; you still need to apply some methodology or approach. Finally, assets may help you prioritize threats, but if that’s your goal, it doesn’t mean you should start with or focus on assets. [Note that this sentence could be more clear as “assets may help you prioritize threats, but that doesn’t mean you should start with, or focus on, assets.’]
Let me say a bit more, since this perspective keeps coming up in both reviews and private conversations. Financial institutions are a great example, because, after all, they hold money as an asset which attackers want and that they want to defend, so we can avoid definitional issues. We can over-simplify and say that money is THE asset that the bank has. Also, I’ve done a fair amount of work threat modeling for financial institutions, so I have a basis for discussing how those systems are really built.
So, let’s take a retail bank as an example. (In contrast to an investment bank, a retail bank does most of its business with consumers and businesses, providing things like loans and money management.) The bank has a general ledger (GL) system. It’s often still on a mainframe, and it is the only place where money really moves from one account to another. So we should start threat modeling there, right? Maybe.
Let’s look at the rest of the business. It turns out that there are pretty much two types of systems at the bank: those that touch the GL as a matter of course, and the desktops and laptops that people use to do their day jobs. In other words, pretty much everything that the bank has deployed, from the web front ends that show you your balance through to the inter-bank transfer systems like ACH and credit cards through the systems that calculate taxes have access to the GL. That access is often mediated through several layers of control, protocol translation and the like, but the access is there. Worse, even the systems that you’d hope are read-only (the tax calculators) can often move money around (manage deductions, enforce IRS mandatory withholding, etc). Now, I’m modeling, that is to say simplifying. But in this instance, I don’t think I’m dramatically over-simplifying.
If you go and enumerate everywhere the money is, or everywhere that there’s access to the GL, what you eventually get to (in essence) is a model of the software. It’s more expensive than a software-mainly model because you need to draw in additional people who can explain the business processes, and add a layer of model that covers how money moves.
Now, it may be that if you come in consulting at the senior management level (and I think Gunnar often does), that you start from the money because the senior management folks have no idea how their systems are actually plugged together, and figuring it out requires following the business processes, and reporting will require going back along that path of following the money. So here, I think the difference is one of intended audience: the book is primarily for people building or operating software, not consultants. If we make it accessible, those folks can and should learn to threat model. It’s easier than git.
People building software or systems at a financial institution, a supply chain, or a healthcare company should start from the software they’re building because it’s what they know best. Another way to say this is that they are surrounded by layers of business analysts, architects, project managers, and other folks who translate between the business requirements (including assets) and software and system requirements.
Gunnar and I agree that assets are a great tool to link “the resultant threats to a business impact.” It’s my experience (as a consultant and at my current employer) that the assets come out in risk discussion after you’ve identified a software issue.
So to answer the question: it depends who you are. If you know the software, you should start there.
by adam on March 19, 2014
“Please note that your password will be stored in clear text in our database which will allow us to send it back to you in case you lost it. Try avoid using the same password as accounts you may have in other systems.” — a security conference’s speaker website
This is a silly pattern. At least these folks realize it’s a bad idea, and warn the person, but that’s the wrong approach, since it relies on people reading text, and then relies on them being willing to make up and recall yet another password.
The origin of this problem is a broken model of what people want from their online accounts. As I discuss in chapter 14 of Threat Modeling: Designing for Security, the right goal is almost always account recovery, not password recovery. It’s irksome to see a security conference get this so wrong.
To be fair, the person who selected the conference management system was likely not a security expert, and had other functional goals on which they were focused. It would be easier to be annoyed if someone had a comprehensive and precise list of security problems which they could look for. But while we’re being fair, this isn’t like a XSS or SQLi issue which require some skill to discover. It’s right there in the primary workflow.
by adam on February 21, 2014
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.)
by adam on February 20, 2014
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.
by adam on February 19, 2014
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.
by adam on January 31, 2014
Yesterday, I announced that I’ve set up a mailing list. You may have noticed an unusual feature to the announcement: a public commitment to it being low volume, with a defined penalty ($1,000 to charity) for each time I break the rule.
You might even be wondering why I did that.
In the New School, we study people, and their motivations. Knowing that introspection is a fine place to start, a poor place to end and an excellent source of mis-direction, I talked to several people who seem like the sort I want on my list about their experience with mail lists.
The first thing I heard was fairly unanimous: people don’t subscribe because they get spammed.
The perception is that many people who create lists like this abuse those lists. So to address that, I’m using a commitment device: a promise, made publicly in advance. By making that promise, I give myself a reason to hold back from over-mailing, and I give myself a way to constrain helping others with my list. (But not eliminate such help — perhaps that’s a bad idea, and it should be just about those new things where I’m a creator. Would love your thoughts.)
The second issue I heard is that unsubscribing tends to feel like an interpersonal statement, rather than a technical one (such as “I get too much email.) So I promise not to be offended if you unsubscribe, and I promise to be grateful if you tell me why you unsubscribe. This is why I love Twitter: I control who I listen to. It’s also why I think the “unfollow
unsubscribe bug” (real or imagined) was such a good thing. It provided a socially acceptable excuse for unfollows.
Are there other factors that hold you back from signing up for a mailing list like mine? Please let me know what they are, I’d love to address them if I can.