If you want to understand how to threat model systems and applications in most any environment you turn to someone who has done so. That’s why we took 30 minutes to speak with Adam Shostack. Adam is responsible for security development lifecycle threat modeling at Microsoft and he is one of the very few threat modeling experts in the world. We thought, with more and more organizations moving toward DevOps and Continuous Deployment, would be a great time to discuss how this impacts the design of secure software. Earlier this year Adam published his book, Threat Modeling: Designing for Security, available here. The book provides pragmatic and actionable advice on how to make security an integral part of systems, software, or services from the outset.
This advice applies to systems and development teams both big and small and is especially crucial as application deployment times accelerate.
devopsy.kinsta.cloud:Why threat modeling? What benefits does it provide the business as well as the application development and operations teams?
Adam Shostack: For the business, executives, they don’t want to deal with individual problems as they arise, they want to address problems as a category. They want to manage a class of things that can be completed in a consistent, repeatable, or predictable way. When it comes to managing application risks, threat modeling gives you an opportunity to answer questions as to whether you are dealing with certain vulnerabilities across all of the applications – rather than coming at them as one-offs. It’s a way to model and abstract away many of the details and look at things in a more strategic fashion.
The other value threat modeling provides is the degree of predictability as you’re developing things – instead of forging ahead and building things and then running a pen test at the end only to learn then that you have serious security problems. What ends up happening in that scenario is that once you fix those problems, you then run another pen test and learn of even more or new security problems and you end up in that very unproductive cycle for a very long time.
So threat modeling helps you think about your security before you start building. This way you can bake security into what you’re doing. My book helps to make both of those value propositions concrete and approachable. You can take these lessons in the book, give them to people and say go do these things and you really get an increased degree of control and predictability through what you’re designing through what you’re delivering.
Also, when you threat model, you get a picture of where things are likely to go wrong. A lot of the threat modeling practice can be very process heavy. That’s why there’s a lot of very process heavy documentation out there. But actually threat modeling integrates well inside a test driven design approach to software development. Why? Because threat modeling tells you where you need to concentrate your security testing. If you’re looking for bug classes, don’t look at random sets of things or relatively random sets of things and you won’t get nearly as much test coverage.
devopsy.kinsta.cloud: So, they can operationalize secure development into the processes, which is what security advocates have often spoke of as the optimal state of security’s relationship with application development and operations – rather than be a barrier at the end of the development process.
Adam Shostack: The whole barrier meme comes from the idea that you do security activity late. A lot of people come into security through hacking. You hear the hacking metaphors all of the time. They are memes like “you can’t secure something if you don’t know how to break it.” Now, knowing how to break things is great. It’s a fun skill. It’s an important skill set. But you notice when you ask about making it operational is that one of the things that security people love to say is you’re never done threat modeling. Now, if you go to a VP of development or a VP of Ops or a VP of DevOps and say, “I want you to do this thing and it’s never done, but it’ll fit into our four week sprints….” You will get a big “huh?” The conversation won’t go anywhere from there.
In order to work it has to be complete-able. It has to be focused and it has to be prescriptive with checklists. It has to have exit criteria, and it has to have metrics that answer: “Are we doing this well?”
devopsy.kinsta.cloud: That type of thinking strikes me as fitting well with the continuous improvement objectives of DevOps.
Adam Shostack: Absolutely. I’ve been threat modeling in various ways for a good 20 years. When I joined Microsoft I encountered people in development and in operations who were passionate about security, who knew that they had to do security and they wanted to do it right. But they also wanted to focus in on reliability, on accessibility, on internationalization, on performance. They wanted to focus on all of these other things each of which is an important property of the system you’re developing. I had to learn to make threat modeling easy. I had to learn to focus in on the highest value deliverables and make sure that those deliverables were accessible and capable. This has to be so even when you didn’t have a security expert groomed because people don’t understand that their decision has a security implication. They’ll make a decision without a security person handy. If you make the security goals accessible and understandable, they’re more likely to understand that what they’re doing has a security implication and they’re more likely to do it well.
Let me give you an example of this. One of the areas that most often goes wrong in the design of a system is people don’t draw their trust boundaries. They don’t know where different principles are going to interact with one another. And application accounts with different authorization levels interacting are a natural place for security problems to arise.
So what you can do is draw these trust boundaries on a white board. It doesn’t have to be a fancy diagram. Scribble on a white board and say, this is where things happen in admin. This is where things happen in the database. This is where things happen as the web user, and this is where web sessions are authenticated and you put boundaries between each of them. Developers understand that these things that they’re writing are run at different privilege levels.
They then say, okay, this code runs on the web user context, this code runs on the database context. That’s great because once you’re doing that you can see the places that your threats are going to arise and look for places to exploit. There are lot of elements in threat modeling that you can work toward incorporating, but the fundamentals are actually easy to teach, easy to learn, and they’re easy to apply.
devopsy.kinsta.cloud:We started out by talking, from a high level, what threat modeling means to different constituencies in an organization. More concretely, what is the payback of threat modeling for developers? Is it more resilient applications, fewer problems that have to be dealt with after the fact, and generally improved outcomes?
Adam Shostack: Those are great values. The biggest “what’s in it for me” for a developer is that threat modeling takes all of these details about security that they want to deal with and provides a model, an abstracted way to frame them. So, instead of constantly worrying “Gosh, I might have another security issue” you can get a sense for how much you’ve done to solve the risk, and how much of it might remain. You get a sense of where you want to prioritize that work.
I think a big misconception is that people believe that only an expert can do threat modeling. One of my aspirations for this book is to show that threat modeling should be like version control. Every developer, every ops person should know a little bit of threat modeling. And it doesn’t have to be a security expert. Perhaps it’s the person who manages your source tree. Or, if you work in a small organization threat modeling will be a side job for someone and that’s okay too. The important thing is to make it a part of your work.
