In this episode, we discuss the four-question framework for threat modeling with its creator, Adam Shostack. We dive deep into the meaning and purpose of each question and how they simplify the threat modeling process. The four questions are: 1) What are we working on? 2) What can go wrong? 3) What are we going to do about it? 4) Did we do a good job?
Adam explains that these questions are not a methodology but a foundation for a more practical approach to threat modeling. We also discuss the importance of retrospectives, evolving the framework, and how it can be applied in various situations. Lean into the four questions, and you might become a threat modeling Jedi.
If you've ever heard the words threat modeling, you've probably heard of Adam Shostack. In Threat modeling. Adam is a single name like Prince or Elvis. He's the first person I'm aware of that brought threat modeling to tech companies during his tenure at Microsoft. Adam's famous for many things within the world of threat modeling, but we'll focus on his four question framework about threat modeling. Who better to explain the framework than Adam himself?Adam Shostack:
I think of the four questions as a framework. In fact, I call them the four question framework for threat modeling, I don't think of them as a methodology because we don't have specific ways of answering them, and that's both a strength and a weakness. It's a strength in that it enables us to vary up the way we answer them, and in varying them up, we can respond to the situations in which we find ourselves. I created the four question framework while I was at Microsoft, and in fact, I created it as five questions\ I was trying to simplify how we talked about threat modeling. T he first question about requirements and goals has fallen away. similarly, The first way I represented it was in a loop, in a hamster wheel of pain, to represent that we threat model at the beginning of a project, we threat model as we're creating features, we threat model at the end. The implication was that threat modeling is a never ending chore. So I simplified it to be more linear and I think that that's a superior approach. the four questions are, what are we working on? What can go wrong? What are we going to do about it? And did we do a good job?Chris Romeo:
In the world of threat modeling, we often speak of methodology. Adam states that the four question framework is not a methodology, but it's essential to understand why that is. Some argue that methodology is a religious debate where their approach is the only way to do threat modeling. Threat modeling methodology is an approach that a practitioner uses to perform threat modeling, consisting of both a process and a set of threats and mitigations for consideration. Many different methodologies exist and we'll unpack many of them over time, but for now, you may have heard of Stride or Lindon, Pasta or No Dirt. These all represent different methodologies for performing threat modeling. As Adam said, the four questions are not a methodology. The four questions are a way to simplify threat modeling at its core. The four questions are simple. Simple always equals more secure. When something is simple, it's easier to explain to the people that need to internalize it. The four questions are a great place to start and are the foundation for how most people approach threat modeling. Let's dive deeper into the four questions because it is the easiest way to begin threat modeling. You don't have to remember a million details or facts or implement a 27 step process for success. The four questions are simple, by design. They lead you down a path/process that generates a meaningful outcome.Adam Shostack:
The first question, what are we working on is a scoping question, and our friend, Izar likes to say, threat model. Every story. In which case, what are we working on? Is what are we working on in this story? Or if what we're working on is a big waterfall project, say windows or a rocket ship, or a self-driving car, what we're working on can be an overall question, but this question both gives us scope, it gives us an introduction to the project if we're coming in as a consultant. And it helps us gain a shared understanding. We tend to answer the question, what are we working on with diagrams often created in conversation to help bring people together in mutual understanding of the system that they're working on.Chris Romeo:
With this question, as Adam said, we're addressing the scope of a given threat model. We want to encourage people to threat model whatever they are personally working on. So when a person answers this question, they can narrow the scope to a manageable size. The Izar he mentions is our friend, Izar Tarandach, who you'll hear from later in the series. Now for the second question, what can go wrong?Adam Shostack:
The question of what can go wrong is both the heart of threat modeling and the hardest part of threat modeling. It's the core of the framework, and we answer it either from simply asking what can go wrong, or we can use structures. We can use things like stride or kill chains to help us answer the question of what can go wrong. And we do that to give us repeatability, which is a great property, but it's not an essential property. When I say it's the hardest part, I wanna mention here, if I may, my new book. Threats: What Every Engineer Should Learn From Star Wars is an attempt to share and to develop common answers. What are the norms that every engineer should know? Just subtitle of the book is really an essential part of how we get to that consistency, and so I'm really pleased with it. And hope people like it. The other thing I wanna mention about what can go wrong is just asking that question can be incredibly powerful. Making space for people to express the things about which they worry. This can be the evil brainstorming side of things that our friend Tanya Janca talks about. This can be the use of, fortunately, unfortunately, where I say, fortunately, we've encrypted that data and you say, unfortunately, the key is stored on the local machine. And I say, fortunately, we've set permissions on it. And you say, unfortunately, they're world readable. And we can even just use the question of what can go wrong and encourage people to speak, make their answers valid, tell them we appreciate hearing them. That's really powerful.Chris Romeo:
What can go wrong is not prescribing a particular methodology but directing us to list the threats regardless of the source, as Adam states, as we document it in the threat modeling manifesto, threat modeling is both art and science. Evil brainstorming represents the creative side of threat modeling. On to the third question.Adam Shostack:
So the third question of"what are we gonna do about it?" ranges from we're gonna develop controls, we're gonna develop features that make these threats harder to exploit, or we're gonna deploy controls. Technologies, products, processes that help us defend our systems. And when it's hard to develop or deploy controls, we can go towards risk management, where we can eliminate, accept, or transfer risk. And I think the relationship between a risk and a threat is a risk is a quantified threat, where we start to focus on likelihood and impact to help us decide between the various ways in which we do risk management because the controls are difficult to develop, deploy, operate, make the system unusable, et cetera.Chris Romeo:
Mitigations are the key value driver of threat modeling. Without mitigations, we're wasting time, dreaming up threats that will never be resolved. Mitigations dictate the positive security change that occurs because of discovering the threats. Mitigations require. Follow up to determine if any fixes are in place.Adam Shostack:
So the final question in the four question framework is, did we do a good job? And we can start this at a very mechanical level. Do we have a diagram? Do we have a list of threats, which is appropriate for the way in which we're engaged in these things? We can answer it at a satisfaction level. Would you recommend threat modeling to a colleague? And if you would, great. And if not, there's probably an issue and we can answer it retrospectively. Did our pen test do better this time than it did previously?Chris Romeo:
We want to use retrospectives to pinpoint ways to improve our threat modeling process, methodology, or tools. The key to long-term security improvement is not being afraid of asking for feedback. We talk about this often in the DevOps world. Craving actionable feedback and blameless retrospective. The same applies to the world of threat modeling. Before I could wrap this up, I had to understand Adam's thoughts on the future of the four question framework. Where will it go in the future?Adam Shostack:
All right. So do I see any evolution to the four questions? No, but that's the thing about evolution is it surprises you. When we were creating the manifesto, the team argued for did we do a good enough job, and made that case. If I had foreseen that I would have evolved it. So another thing that I did is when I started with the four questions, I would say, what are you working on? It was a consulting approach. It was an external approach rather than a collaborative approach. And I apologize to whoever made the case that we should make it"we" they made a strong case. And so now, I talk about the four questions in terms of what are we working on, what are we gonna do about it?Chris Romeo:
The four question framework for threat modeling is a foundational approach. We see many different organizations building their threat modeling programs using this approach. The reason it's so successful is simple. The method is simple. By remembering four simple questions, you can threat model anything. So give it a try next time you're standing in the security line at the airport. But a tip from my experience. Don't share the results with them in real time. They may not share the same sense of humor that you do.