---
title: "Adam Shostack — The Jenga View of Threat Modeling"
url: https://appsecpodcast.com/adam-shostack-the-jenga-view-of-threat-modeling/
date: 2020-06-16
duration_seconds: 1873
guests: ["Adam Shostack"]
topics: ["Threat Modeling"]
audio: https://www.buzzsprout.com/1730684/episodes/8122602-adam-shostack-the-jenga-view-of-threat-modeling.mp3
video: https://www.youtube.com/watch?v=Ph-hgWInEQs
transcript: true
---

# Adam Shostack — The Jenga View of Threat Modeling

*June 16, 2020 · 31 min*

with [Adam Shostack](https://appsecpodcast.com/guests/adam-shostack/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122602-adam-shostack-the-jenga-view-of-threat-modeling.mp3) · [Video](https://www.youtube.com/watch?v=Ph-hgWInEQs)

## Show notes

Adam Shostack is a leading expert on threat modeling, and consultant, entrepreneur, technologist, author and game designer. He has taught threat modeling at a wide range of commercial, non-profit and government organizations. Adam joins us to discuss his new white paper called the Jenga View of Threat Modeling. He's a member of the Black Hat Review Board, is the author of Threat Modeling: Designing for Security, and the co-author of The New School of Information Security. Adam joins us this week to discuss his new white paper called The Jenga View of Threat Modeling. We hope you enjoy this episode with Adam Shostack. You cannot hack yourself secure.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Adam Shostack is a leading expert on threat modeling and consultant, entrepreneur, technologist, author, and game designer.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Adam Shostack:  
→ [Jenga View of Threat Modeling whitepaper](https://associates.shostack.org/whitepapers)  
→ [Adam Shostack](https://adam.shostack.org/)

Mentioned in this episode:  
→ [Jenga View of Threat Modeling whitepaper](https://associates.shostack.org/whitepapers)  
→ [Adam Shostack](https://adam.shostack.org/)  
→ [Threat Modeling: Designing for Security](https://amzn.com/1118809998)  
→ [New School Of Information Security 9780132800280](https://www.informit.com/store/new-school-of-information-security-9780132800280)  
→ [Robert Hurlbut](https://twitter.com/RobertHurlbut)

Chapters:  
00:00 Meet Adam Shostack: Adam Shostack — The Jenga View of Threat Modeling  
02:05 Yeah, thank you. And so you have some things you've been  
05:22 You remember those Jenga commercials back from when those of us  
07:54 Okay. Makes sense. Again, you don't want it to fall down  
09:46 Adam, I'm looking at the white paper that you've written about  
11:50 You had a few others there We don't have time right  
16:49 One of them that actually has an asterisk next to it  
22:15 Right  
25:43 Okay. Now, with all the way we've talked about here today  
27:23 I got another question about kind of a more general approach

## Transcript

*4,587 words · assemblyai*

**0:00 Chris Romeo:** Adam Shostack is a leading expert on threat modeling and consultant, entrepreneur, technologist, author, and game designer. He has taught threat modeling at a wide range of commercial, nonprofit, and government organizations. He's a member of the Black Hat Review Board, is the author of Threat Modeling: Designing for Security, and the co-author of The New School of Information Security. Adam joins us this week to discuss his new white paper called The Jenga View of Threat Modeling. We hope you enjoy this episode with Adam Shostack. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation together with learning. We believe We believe that developers need hands-on experience, but not at the expense of fundamental knowledge. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo.

**1:08 Robert Hurlbut:** Hey folks, welcome to another episode of the Application Security Podcast. This is Robert Hurlbut, Threat Modeling Architect, and I'm joined by my co-host, Chris.

**1:31 Chris Romeo:** Hey, thanks, Robert. For those that are listening to this right now, we're right in the middle of sheltering at home and all the craziness that's been going on with the COVID-19 virus and everything else, but we are lucky and blessed that we get to talk about application security even right now in this kind of trying time. for the nation. So let's talk about something fun. Let's talk about threat modeling.

**1:56 Robert Hurlbut:** Absolutely. And for threat modeling, we have Adam Shostack joining us again today. Adam, welcome.

**2:03 Adam Shostack:** Hey, pleasure to be back.

**2:05 Robert Hurlbut:** Yeah, thank you. And so you have some things you've been working on lately. I know, you know, we're not— as Chris mentioned, we're not out there in the conference world at the moment, mostly hunkering down and doing some work at home and so forth. But What's going on lately for you with threat modeling? You have this something new, right? Tell us about it.

**2:28 Adam Shostack:** I do, I do. And it's a new lens for thinking about threat modeling, for breaking it down. And I've got a fun little metaphor which isn't Star Wars. Tried to make it Star Wars, it didn't work. But the lens, the lens is Jenga. And so it's the Jenga view of threat modeling where we build a tower to support our delivery of secure products. And there are 3 types of blocks in this metaphor. There's the technical building blocks, the interpersonal ones, and the organizational ones. And as everyone knows, Jenga towers are sometimes unstable if they don't have enough blocks in them to support the top.

**3:13 Robert Hurlbut:** Right.

**3:14 Adam Shostack:** But they can also be too heavyweight. Each block in the Jenga model has a cost to support it. If we're going to teach people more and more technical building blocks, it takes time and energy for them to learn those things. If we're going to do measurement of how our program is doing, that takes time. If we're gonna run office hours, that takes time. And so the idea is to give people a way to think about their tower, to think about the way threat modeling supports the delivery of secure products, secure services, and to make sure they have the right set of blocks in the technical sense, in the interpersonal sense, and in the organizational sense.

**4:07 Robert Hurlbut:** Okay, so you're building blocks and thinking of all the things that we need to think about in terms of getting to our goals. How did you come up with that? I'm curious.

**4:17 Adam Shostack:** So, I was reading something, and I don't remember what it was. And they had woven these 3 ideas together in a way that I was trying to piece out, you know, I think a lot about the building blocks. I've used Legos as a metaphor before. And this piece that I was reading felt like it was a little bit jumbled up, that the ideas were intertwined in a way that made it hard to see them. And I said, how can we clarify this? And I started, you know, I started with some very traditional metaphors of like pillars, or a 3-legged stool. And I was, I was sketching my little 3-legged stool, and I wanted to put all these details in it, and I just couldn't fit it. And I said, I need a different metaphor so that it works visually. And, and so I started playing around.

**5:21 Chris Romeo:** You remember those Jenga commercials back from when those of us on this, this phone call right now. Back when we were— seems like we were young. I just remember the commercials of Jenga where the people would be standing around the Jenga thing going, Jenga, Jenga, Jenga. So I'm like, maybe, maybe I'm remembering that. Anybody else remembering that?

**5:40 Adam Shostack:** Oh yeah, I, I think, I think we need a link in the show notes.

**5:44 Chris Romeo:** There you go.

**5:45 Robert Hurlbut:** Yeah, the game pulling out the blocks and hope it doesn't all fall down, uh, in terms of, uh, The analogy with threat modeling, obviously you're building, these are building blocks and you're moving along, but ultimately you want it to stay together, right? You don't want it to fall down. That almost sounds like being resilient. That's that term that seems to be used quite a bit these days. How does that apply?

**6:16 Adam Shostack:** Or does it apply?

**6:16 Robert Hurlbut:** Yeah.

**6:20 Adam Shostack:** The goal of Jenga is that you're pulling out blocks and you're not the one responsible for the tower falling down. And, you know, as we, and if you think about it, threat, people often talk about threat modeling being heavyweight. And so if you think about what are we gonna remove, what are we not gonna invest in, we all know that we wanna do that without making the tower less resilient. We want to find, this balance. And when you get to the resiliency end of things, everyone wants resiliency on a shoestring, right? And so I think that the metaphor carries a little bit and that they intersect, that if we're trying to make our data center resilient, we want higher and higher uptime for our power, for our internet. And every time you add another generator and you add a switch so that it fails over automatically, there's a cost. And we haven't been thinking about the costs of supporting the threat modeling work that we do. You know, I got into a bit of a conversation with Clint Gibbler, and we were talking about using questionnaires as a way of making threat modeling lighter. I think that that goal of how many of these blocks can we remove and still get value from the work that we're doing is super important to organizations today.

**7:54 Robert Hurlbut:** Okay. Makes sense. Again, you don't want it to fall down, but like you said, are there some things that we could do? Also think about the kinds of blocks. You mentioned the technical, interpersonal, the organizational. Maybe tell us about the technical building blocks that you have in mind.

**8:16 Adam Shostack:** So technical building blocks are the things that people will often think of first. They're things like data flow diagrams or message passing diagrams. They're things like data flow diagrams and kill chains, right? These are the core technical skills that help us threat model in a structured and systematic way.

**8:39 Robert Hurlbut:** Okay, so that's still there, plus the questions as well, the 4-question framework and similar?

**8:47 Adam Shostack:** Yeah, yeah, the 4-question framework is a way of sort of sub— you can think of it as a way— you can think of the 4-question framework actually overlaying all of this. So data flow diagrams are a way of asking, what are we working on?

**9:02 Robert Hurlbut:** Mm-hmm.

**9:03 Adam Shostack:** Questionnaires can be a way of asking that, but we can also think about making sure that we have a gate, right? And gates are no longer popular, but we can say, for example, if we're working on a medical device, we can say that you cannot exit the design phase until you have a data flow diagram that's been reviewed. So that review of the data flow diagram is an organizational activity. The idea of a gate is an organizational activity. And so the 4 questions play into each of the types of Jenga blocks.

**9:44 Robert Hurlbut:** Okay.

**9:46 Chris Romeo:** Adam, I'm looking at the white paper that you've written about this Jenga threat modeling approach. And I noticed that you had called out some additional technical skills. And some of these things I thought were pretty interesting, and I thought it'd be worth kind of looking through those and discussing them a little bit more. So the first one you had there was critical thinking. So what's the importance? What do you see the importance of critical thinking in threat modeling?

**10:10 Adam Shostack:** So there are people who will argue that threat modeling is just thinking critically about what's going on. And to me, critical thinking includes sub-skills like stating our beliefs in a crisp way, asking why we hold those beliefs, asking why someone else holds a certain belief, thinking about what would test and either buttress or undermine our thinking. And when we threat model, oftentimes what we're doing is we're coming to a critical analysis of some piece of work. And so the ways in which we do that critical thinking that people might have learned in high school or college can be applied, but if we don't have some of the other technical building blocks, and this is a really good question, I love this question. If I don't have the building block of I'm going to draw the system in some way, or even I'm going to draw the system with a data flow diagram, then what can happen is different people have different mental models of the system.

**11:25 Robert Hurlbut:** Right.

**11:26 Adam Shostack:** where they're applying that critical thinking. And in having those different mental models, critical thinking can lead us to question, to, through dialogue or discussion, understand one another's models. But we can accelerate that process by applying the technical skill of drawing what the system we're thinking about is.

**11:50 Chris Romeo:** And you had a few others there We don't have time right now in this conversation to kind of go through each one. I'll call out a couple others, and there's one I'm specifically interested in, just like critical thinking. Some of the other ones that I think made sense, you had knowledge of repertoire of attacks, general technical knowledge of the systems being used, understanding software delivery models, DevOps, Agile, Scrum, all these things are important. The next one that really caught my eye though was teaching. And so I'm curious why you think, just like with critical thinking, why do you think teaching is so important for someone who has that technical building block or as a technical building block of threat modeling?

**12:29 Adam Shostack:** Wow, another great question, and I'll try and be brief. Oftentimes, the threat model is the time when the security people and the engineers doing other work on a system come together. And to the extent that we can explain how we're approaching the system that they're working on, to the extent that we can explain what the threat is and why the threat matters, and do so in a way where they walk away with that knowledge. There's incredible power in teaching someone to phish rather than teaching them to click on the link. I mean, rather than phishing on their behalf.

**13:13 Chris Romeo:** Yeah, no, I understand that. And I agree with you there. I think that's a very powerful thing. And I love the fact that you said threat modeling is one of the times where we all get to the table. Even if you're coming from security and development and you have a culture that isn't very unified, this is that opportunity to start building those relationships. And it's we as security people explaining to our developers how to do threat modeling and getting them excited and engaged in it, practicing developer empathy. This is the big thing. This is gonna be my 2 words for 2020. I'm gonna say it 1,000 times. Because we don't do it enough. We don't have that empathy. And I know I've been guilty of that in the past, and I've seen the challenges that builds. And so teaching really builds, it helps us to really pour into those developers. It shows empathy saying, hey, we understand where you're coming from. We want to show you how to do this threat modeling thing, but we're also cognizant of the fact that you have a way of doing development and doing your job. And we're not telling you you're doing everything terrible. We're here to say, let's work together in a partnership.

**14:19 Robert Hurlbut:** Mm-hmm.

**14:20 Adam Shostack:** And boy, what a nice lead into interpersonal building blocks.

**14:23 Robert Hurlbut:** Indeed. Indeed. In fact, I was thinking about that in your paper as well, different aspects of that. So yeah, tell us about some of those.

**14:33 Adam Shostack:** You stole my thunder, darn it. It's okay, we know each other and I can joke about that and say, you've said developer empathy Is so important that when we are the department of no or the department of calling your baby ugly, we lose the ability to engage. We lose the invite to the next meeting. We lose the seat at the table because no one wants to deal with that difficult person, right? There's a book, and I don't, I don't remember what your policy on swearing on the podcast is, so I'll say it's the No Jerks Rule. Um, it's not quite that. Substitute a word starting with A. It's really important as we engineer things that if we're going to be able to deliver a difficult message, if we're going to deliver a harsh critique of a system that where security might not have been thought about, that we do so with an understanding that we're critiquing the system, not the person who built it. that we're doing so knowing that design is hard, that if we are respectful of the person who did the work and say, look, getting this stuff to work is difficult, we get that, and here are the security implications of decisions that have been made, and being very careful with the words that have been made rather than the decisions you've made. Yeah. Because the minute I start making it about the person, the other engineer, they're going to start feeling defensive. It's just human nature. And so if we think through these things, if we show developer empathy, if we teach it, if we practice it, we get further. And so as we roll out a Security Champs program, making sure that the Security Champs are going through training not only in the technical skills which they absolutely need, they're table stakes, but the interpersonal skills are also table stakes.

**16:49 Chris Romeo:** I want to ask about one of them that actually has an asterisk next to it on your list of the interpersonal building blocks. So you had working the organization, and then you have an asterisk next to that and some additional explanation. But I'm curious as to what are your thoughts on working the organization as someone who's trying to roll out this new, new thought process about threat modeling?

**17:13 Adam Shostack:** So the reason there's a star there is working the organization is jargony, and I didn't understand what it meant until, until I read a book titled Making It Big in Software. It's a set of interviews with important software engineers, and I don't remember the precise explanation there, but working the organization means going around and talking to people about what's going on, before a formal decision is made so that you have a chance to hear their feedback one-on-one, to hear the challenges that they see or they anticipate with what you're saying so that you can start to address them as part of an official plan, right? If you're gonna go to the VP of engineering, for example, and say, we'd like to roll out an AppSec program, or we'd like to enhance our SDL with AppSec, or we'd like to enhance our SDL with threat modeling, they're going to say, what does that mean? What are the— how much is this going to cost me? What are we going to get out of it? And you're going to have some answers, hopefully. And so being able to let them ask those questions one-on-one, see how well thought out things are, is important. But that VP probably has a set of managers who also need to be talked to. Go talk to them one-on-one. If the first time someone hears about something is in a meeting, you know, you go to that VP's meeting and say, hey, we'd like to add threat modeling to every sprint, and someone raises their hand and says, what the heck is threat modeling? You've just lost in all likelihood. Because what the VP is going to say is, oh, that person who just raised their hand isn't bought in. Chris, why don't you come back to me in 3 months once you've worked this proposal a little bit better? And so working the organization is that process of talking to the people, to, to go from jargon to English language. It's go talk to people. Find out what objections they have, see if your answers address their objections, and ask for their support. Once you've done that, the official meeting is much more a formality. And this is sort of big company thinking. Some of your listeners might be saying, you know, we here are super agile, we don't need all that politicking and BS. This is not about politicking and BSing. This is about listening to other human beings who have a say in the decision that's being made and making sure you hear that. That could be a series of 5-minute conversations if you're super agile. You say, hey, we want your people to be able to answer these 4 questions with every sprint. We can do it really easily. Let's do a prototype right now so that you see what it is. That's working the organization too in a much more lightweight way than back in the day while I was still at Microsoft or Chris, when you were at Cisco or Robert, when you're at some large bank, I forget which one. That's working the org.

**20:35 Robert Hurlbut:** What I liked was that one as well as assumption of good intent. That's where you come to a meeting, I think, and you can correct me if I'm wrong, but most people want to get this right. They want to do the right things. But having that assumption rather than go into a meeting and assume everyone doesn't know what they're doing or really just want to do the wrong thing, if you will, I like that idea of good intent.

**21:04 Adam Shostack:** Yes. Let me build quickly on that. Even if someone says, this security stuff isn't my job, You do it. Assume they're doing that from a good place. They feel overworked. Maybe they feel scared. They don't know what the request really entails. Believe that even when they're coming at you angrily, they're doing so not because they hate what you're saying, but because they're taken aback. You didn't get a chance to work the org and talk to them. They had a fight with their kid on the way to school this morning. Something else is going wrong and you can win them back.

**21:49 Robert Hurlbut:** Good advice. Okay, so we've talked about a couple of building blocks. Uh, the next one is organizational. Tell us about that. What does that mean?

**21:59 Adam Shostack:** So there's 2 halves to organizational, and the first half is the governance. Do the executives know what you're doing and why and believe that it should happen?

**22:15 Robert Hurlbut:** Right?

**22:15 Adam Shostack:** Is there an executive whose bonus depends on the SDL happening well? If there's not, every time you run into trouble and escalate, it's going to be painful. So there's governance and then there's operations. There's roles and responsibilities, right? Who does what? Okay, so I'm raising my hand here. I'm a software engineer working on the mobile app. What does it mean for me to do my job once we've made this change to the way we deliver things? What exactly am I supposed to deliver Who do I deliver it to? What does goodness look like? How do I get help? What software do I use? All of these sorts of things that as you roll out, you know, what goodness looks like. For example, you know, let's go back to our previous jobs at Microsoft and Cisco. The answers were specific to each of those companies, probably each business unit within those companies, but each company had ways of answering that at various levels. If you don't have an organizational view of the answer of what do we do to make this happen, it's not going to happen in a systematic, and consistent way. So we need to think about those organizational blocks.

**23:57 Robert Hurlbut:** And so you also talk about, and some of this may be interpersonal as well, but certainly in an organization, you know, the responsibilities, who's responsible, who takes on certain roles, who does, you know, make some decisions and so on. So that also plays into this as well, along with, you know, organizations are not entities to themselves. There's obviously people there as well. So there's certainly some overlap in, in some places here as well.

**24:27 Adam Shostack:** Yeah, you know, you, you guys know I'm fond of saying all models are wrong and some models are useful. And some of, some of the things that I was putting into one bucket or the other, I, I thought about and, and I realized, you know, I could put this in either place.

**24:49 Chris Romeo:** Mm-hmm.

**24:51 Adam Shostack:** You know, training, for example, is training an organizational thing? Is it a technical skills thing? Yeah, you can move it around, it doesn't matter. But if you don't think about training as you're rolling out a change to your SDL, it's not gonna go very well. Might be 5 minutes of training, right? We've got a new static analyzer. Here's the website that gives you the translations of the error messages and the mapping to our company's internal standard for what you need to do about it. Please save this message in a place that you can easily find it again. Or it might be, here's a day of training and fuzzing for our security champs. You've got to think about the building block. It's less important where the building block sits or what color you paint it.

**25:43 Robert Hurlbut:** Okay. Now, with all the way we've talked about here today, how would someone decide what structure they need to use typically? Or is it one of those, it varies, it depends type of thing?

**25:57 Adam Shostack:** So the way, the way I would use this is to use this white paper as you're working the organization. walk through and say to the various people whose lives are changing, we've got 3 types of building blocks that we wanna talk to you about. Let's talk about what the technical skills are. Let's talk about what the interpersonal skills are. And let's talk about the organizational pieces. You know, we think, for example, we think generically we should use a lot of data flow diagrams. Have you used data flow diagrams before? Are you comfortable creating them? Let's talk about the interpersonal. How are our people doing? Do you get complaints or grumbling that our folks are lacking in some of the interpersonal skills that we should think about as we do this? How do we make this work?

**26:57 Robert Hurlbut:** Who do—

**26:58 Adam Shostack:** what does the management committee need to know out of this initiative to know whether or not it's succeeding. And so talking through with the white paper as a structure gives people a way to have conversations that are a little bit more broken down, a little bit more granular than we'd like you to do threat modeling.

**27:22 Chris Romeo:** So I got another question about kind of a more general approach here. As I look through the different pieces that you've assembled here. Obviously, the technical building blocks in the white paper are specific to threat modeling, but when I think about the interpersonal and the organizational building blocks, I could see those just as easily being applied to a secure development lifecycle in its, in its whole. And so what are your thoughts on that? I mean, did you think, did you think this could be bigger than just threat modeling, or were you really trying to lock in the pieces in these other sections to just be threat modeling specific?

**28:00 Adam Shostack:** I love talking to you guys. It's great. It is— this is absolutely applicable to everything in an SDL. The reason that I focused the paper on threat modeling after a lot of back and forth in my head was A lot of pieces of an SDL, whether it's static analysis, software composition analysis, fuzzing, bug reporting, penetration testing, are things that happen within the security team, are done by the security champs, are done by code, and don't have this perception of heavy weightness over them and generally don't involve as many moving parts or sliders or opportunities to do it differently as exist within threat modeling. And that's why I focused it in on threat modeling. But you're right, this is, this is a paper that you can apply very directly to the entirety of secure product delivery, secure service delivery within an SDL and change very little. But with threat modeling, it just needed to be specific. It needed to be drawn out. Let me fix that last sentence. It needed to be specific. It needed to be explained rather than drawn out. Drawn out sounds like it's a long convoluted set of work.

**29:36 Robert Hurlbut:** Okay, well, we really appreciate you covering this for us today and help us understand some of the new things going on. Any final thoughts that maybe where they could— folks can find this paper?

**29:51 Adam Shostack:** Wherever fine threat modeling resources are found. No, no. It'll be on threatmodelingbook.com/resources. That's the easiest to spell URL, so I can say it in a podcast, but it'll be on all the places that I tend to put things, the adamshowstack.org/blog. It's on my little business website for associates.showstack.org. Um, so it's, it, it's out there. It's free. It's no registration wall because I want people— I want this to be a resource that is just easily available to people. I didn't want there to be any friction associated with that.

**30:35 Robert Hurlbut:** All right, well, Adam, thanks again for joining us. Always a pleasure.

**30:38 Adam Shostack:** Hey, Thank you.

**30:40 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/adam-shostack-the-jenga-view-of-threat-modeling/