---
title: "Izar Tarandach and Matt Coles-- Threat Modeling: A Practical Guide for Development Teams"
url: https://appsecpodcast.com/izar-tarandach-and-matt-coles-threat-modeling-a-practical-guide-for-development-teams/
date: 2021-04-23
duration_seconds: 3005
guests: ["Izar Tarandach", "Matt Coles"]
topics: ["Threat Modeling"]
audio: https://www.buzzsprout.com/1730684/episodes/8391496-izar-tarandach-and-matt-coles-threat-modeling-a-practical-guide-for-development-teams.mp3
video: https://www.youtube.com/watch?v=Hqz4C1pKqAU
transcript: true
---

# Izar Tarandach and Matt Coles-- Threat Modeling: A Practical Guide for Development Teams

*April 23, 2021 · 50 min*

with [Izar Tarandach](https://appsecpodcast.com/guests/izar-tarandach/), [Matt Coles](https://appsecpodcast.com/guests/matt-coles/)

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

[Audio](https://www.buzzsprout.com/1730684/episodes/8391496-izar-tarandach-and-matt-coles-threat-modeling-a-practical-guide-for-development-teams.mp3) · [Video](https://www.youtube.com/watch?v=Hqz4C1pKqAU)

## Show notes

Threat modeling advice often sounds simple until a development team tries to apply it to a real system. Izar Tarandach and Matt Coles join Chris and Robert to discuss their book, Threat Modeling: A Practical Guide for Development Teams, and the collaboration behind it. They explain how the book organizes system modeling, threat discovery, and mitigation into a usable workflow without forcing teams into one methodology. The conversation covers attack trees, LINDDUN, pytm, writing for different experience levels, and the role of empathy when introducing security practices. Their goal is practical: help teams make threat modeling part of software development instead of a specialist exercise performed once and forgotten.

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

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Izar Tarandach and Matt Coles:  
→ [Izar Tarandach on LinkedIn](https://www.linkedin.com/in/izartarandach)  
→ [Matt Coles on LinkedIn](https://www.linkedin.com/in/mattscoles)  
→ [Threat Modeling: A Practical Guide for Development Teams](https://www.oreilly.com/library/view/threat-modeling/9781492056546/)

Mentioned in this episode:  
→ [Threat Modeling: A Practical Guide for Development Teams](https://www.oreilly.com/library/view/threat-modeling/9781492056546/)  
→ [OWASP pytm](https://owasp.org/www-project-pytm/)  
→ [Attack Trees](https://www.schneier.com/academic/archives/1999/12/attack_trees.html)  
→ [LINDDUN](https://linddun.org/)  
→ [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/)

Chapters:  
00:00 A practical guide to threat modeling  
02:00 How Izar and Matt approach the discipline  
09:36 Why development teams needed this book  
11:46 How the collaboration began  
14:49 Writing practical guidance together  
21:44 The book’s system-modeling foundation  
26:03 Four parts of a repeatable workflow  
29:17 Choosing methods without becoming dogmatic  
31:38 Attack trees, LINDDUN, and other techniques  
34:33 Applying the guidance to real teams  
42:15 Empathy as a threat modeling skill  
46:01 Using threat modeling beyond security

## Transcript

*8,504 words · assemblyai*

**0:00 Chris Romeo:** In this episode of the Application Security Podcast, we're joined by friends, Izhar and Matt, authors of the book Threat Modeling: A Practical Guide for Development Teams. Izhar is currently the Squarespace Principal Security Engineer. He lives in New York, where he enjoys telling people who separate security from development to get off his lawn. Matt's currently a Product and Application Security Engineer at Dell Technologies. Matt lives in Massachusetts, is an avid gamer, and enjoys time with his family when not thinking or talking to others about security. We discuss why they wrote the book, what it covers, the target audience, and how to wield the information within to threat model all the things. Robert and I both love the book and we highly recommend it. And on this episode, you'll hear why. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and also co-host of said podcast. Hey Robert, how's it going today?

**1:51** Hey Chris. Yeah, Robert Hurlbut, Threat Modeling Architect, and really Great to be here, and especially the topic that we're going to be looking at today.

**1:59 Chris Romeo:** We're going to blow some people's minds. They're never going to see this coming, this topic, which we've only talked about probably 15 different times on other episodes, which that's okay, we don't care. We're going to keep talking about it, and that topic is threat modeling. And so we are joined by 2 guests today, Izhar Taran Dosh and Matt Coles. Now, Izhar's been a guest on the podcast before, so You've already heard his origin story, and if you want to hear it again, it's the episode about PyTM, which he's a part of. But Matt, this is your first time on the Application Security Podcast. Well, actually, actually, this is your second or 10th time because Matt and Izhar were both part of the Threat Modeling Manifesto. They were part of those episodes that we took the clips of all of us talking about threat modeling for a lot of hours in a row and put them together. So technically, Matt's been here before, but we haven't heard your security origin story. So Matt, if Your entry into security was a comic book. What would episode 1 of that comic book look like?

**3:05** Boy, I have no idea how to answer that. I hate to admit it, that I'm not really a comic book fan, but given I'm wearing a comic book t-shirt, but that's a different matter. It's also a security shirt. I think it's probably a delusional story to start, so I'll just jump into it. Actually, I should— I guess I have an obligatory statement that I'm here obviously speaking on my own behalf, not of my employer in all of this, as a lot of us do in this space.

**3:42** Me too, me too.

**3:45** So I think I have probably the boring, most boring origin story. I have done pretty much every, almost every job in the development lifecycle from development, QA, tech support, network administration, release engineering, customer support, field service, and various other aspects that are required across the years to make stuff happen. And, you know, ultimately I'm a programmer and got into security actually in college and working on my master's degree. I went to WPI and took some classes on cryptography and data security, and it was always an interesting field, but never had an opportunity to be in that role. I mean, I did network administration and keeping computers you know, safe and free of nasty things, and did some networking and whatnot, but never really did any, you know, hardcore security stuff until I got sort of an opportunity when I was at EMC and had an opportunity to— they were forming, or this group called the Product Security Office was being formed. And I had been working closely with some of the team members doing QA and security QA at the time, so primarily security, I should say, QA, but not as a security engineer, as a QA engineer. And so I had an opportunity to move into that new security group to be able to drive secure development and testing practices. And it was a small team, and so I would've been on the ground floor. The problem is I'm a very risk-averse person. And so, you know, I didn't get into security before, really before then in any, you know, in any large, you know, or dedicated role until then. And even then I was like, oh, should I stay in QA? Should I move into the security group? Is that going to be the right move for me? And, you know, 6 months later, took the plunge and haven't looked back. It's just amazing things. So, you know, having an opportunity to build out a security program with a wonderful crew, including my colleague here, Izhar, who joined the team, and then we caused mayhem and chaos for a number of years. And then I left EMC after 11 or so years, went over to a couple other companies, Analog Devices and Bose, for those who may be familiar with those organizations, to drive security into those groups. And I should say, from my— as part of my security, you know, prehistory, I have a lot of experience across a number of different domains, but from a security standpoint, I'm most definitely a product security person, right? My goal is to make sure that things that get built that we ship to customers are secure. That is my thing. I'm not a network security person. I don't do enterprise security, at least not as a full-time job. I try to avoid it whenever possible. But when it comes to building things and making sure that they're secure and they can be used by customers and don't like, you know, cause mayhem in a home or in a car or on the roads or whatever, that's where I— that's my value.

**7:31** So That's it.

**7:33** I mean, it's pretty boring. I think the only key takeaway I would— I hope folks take from it is, you know, if you have an opportunity, take it. Don't be shy. This is a— and the community here, by the way, is wonderful. I mean, you know, getting to meet so many wonderful people. It is small, right? It is a niche. Product security, at least, is, I think, a little bit of a niche still, especially people don't— if you don't know what a product is, right? You call it different things.

**8:00** Yeah.

**8:03** Yeah, I guess I'll pause it there because—

**8:05 Chris Romeo:** No, I think that's— yeah, I don't— I think that's— it's great to hear how you kind of made that transition. And, you know, this, this idea that you're risk-averse coming into security, I think that's a good thing, right? Like, you, you know, you're the person I want that's making decisions about how the data that's stored about me in whatever company you're working for is going to be storing that data, because I want somebody that's got that perspective. That's good. We got a lot of people that are on the other end of that spectrum. Like, let's do anything.

**8:32** Let's, uh, yeah, let's, let's go with whatever we can do.

**8:35 Chris Romeo:** And so, Isar, are you mayhem or chaos? Because Matt alluded to the fact that, you know, and I was trying to guess in my mind, like, which one is Isar? Is he mayhem or chaos? I kind of feel like he's— I don't know.

**8:47** Since he is the risk-averse one, I guess that the story writes itself.

**8:54 Chris Romeo:** We'll leave it at that. The story writes itself. Well, we're here today to talk about the book that that both of you wrote together. And the book's called Threat Modeling: A Practical Guide for Development Teams. So, once again, that resonates with me, hits me right in the heart right there because you're talking about the target audience that we as product security, application security people, we want to work with. You're helping us to focus right in on that. And so, I guess the first question I have about that is, why write this book? Why write it now? What was, what, what was the reasoning behind both of you saying, let's get together and do this?

**9:36** Uh, so I, I, maybe I'll start. Um, and, and Isar, if you can jump in. And by, and by the way, Chris, uh, this is, this is most definitely the story that did not write itself. Um, so, you know, it, it's interesting. Isar, uh, uh, I think it, so, You know, Izhar approached me with this opportunity after, you know, sort of having a pre-chat with the publisher, I think, and, hey, what do you think about this, about, you know, taking our experiences and putting it down on paper and writing a book? And, you know, keep in mind that, you know, Izhar and I both have taught, you know, software security or application security at the collegiate level. I didn't mention that in the origin story, but That's all right. We both have taught at that level. We both deliver presentations and have spoken at conferences, sometimes together, sometimes not. And so the idea of writing a book sounded interesting, except for it was writing a book. I mean, that's a lot of work, right?

**10:44** Yeah. There was risk in it.

**10:53** You know, so to, I guess, to come back to your question at hand though, right? So it was an interesting opportunity. I think we both had a little bit of consternation about doing it, but we both knew that this is something that we have both been very much excited about, right? A lot of the work that we have done collectively and individually has been how do we get security into the hands of the people who are actually building the things that need to be secured, right? And having that experience in addition to having this experience with the PyTM project, which was in full swing delivering capabilities around threat modeling. So I think that's in part, I'll pass it to Isak 'cause I'm sure he has some other thoughts there.

**11:46** So the, the, to me, the reality of the thing is that the book was sort of a culmination. One thing that Matt forgot to say is that we have been working together one way or another, either every day at EMC or later when we both left, uh, in, uh, over the collaborating in one way or another for 10 years now. And the book is basically a culmination of many conversations that we had that started with, hmm, wouldn't it be cool if? And for example, PyTM was one of them.

**12:22 Chris Romeo:** PyTM.

**12:22** And it came out in 2018. And yeah, it came out cool and we are very happy with it and we're dealing with it every day. But then in 2019, I had the opportunity of talking at the O'Reilly Software Architecture Conference in New York. And that to me was a first because that is not a security conference. That's a developer, an architecture per se conference. And to tell you the truth, like I went over most of the program and many of the things in there I had heard of, but many of them just went whoosh over my head. And when I sent a proposal there, it was with the clear feeling that, hey, you know what, I want to take this threat modeling thing away from the security sphere and get it in the hands of the people that we want to use it. So let's start with O'Reilly, which is a very well-regarded conference, and see where it goes. And as I finished my presentation in there, I was approached by some of the, the people in the audience, and some of them actually told me, hey, you know what, this is the first time that I hear about this, and it does sound like something that could give me some kind of leg up in what I'm doing. Or, we don't even have a security team in our shop, and this looks like a good way of figuring out requirements for security. And I left the room, and in between the sessions they had in there, of course, being an O'Reilly conference, they had the O'Reilly stand in there, and I love their books, so I went there to see what I could get. And they had this very small corner, Come Write for Us. And I don't know about you guys, but, you know, I can remember the, the Camel book of Perl being like one of the first really books that I took every single day everywhere with me as I was working as a sysadmin. And the Animal series for me was always like, you know, you write one of those, you're— You actually probably know a bit about what you're talking about. And the opportunity of being part of that to me became very interesting, and I immediately said, hey, you know what, if this thing goes forward, there's only one person that I want to do this with, and that's Matt. And not only because we had been working for so long together, but again, he is the risk-averse one, and I like to shine lights in very strange places.

**14:49** I'll also add, so as you can— as Isar mentioned, you know, we've been working a long time. together. Partners in crime have come up. Yes, mayhem and chaos have come up. It's interesting to note, and I'll just give you and your listeners a bit of a tidbit here, that why us? Why should we write this book? I think the really important part is that because we want— we have the ability and we want to deliver this knowledge to the right people, well, to the to this target audience, right? I won't say the right people because we understand our book is probably being used by others as well. And, you know, we didn't write it specifically to be exclusive of anybody but developers, but we wanted to make sure that we targeted developers. But it's an interesting— something interesting or something you may find interesting, but maybe you won't, I don't know, is Israr really is the threat modeling guy here, right? So, well, okay, so he invented or was part of a team that invented a threat modeling methodology and has been—

**15:57** I formalized it. We talked about it for a long time before.

**16:00** And then maintainer, you know, lead maintainer on an open source project that encompasses a lot of the ideas that he and I have talked about. From my perspective, I'm actually more interested in the modeling and like the system development and design and how do we facilitate this activity. But really the notion of, you know, what threat modeling does in the environment and how it enables, you know, good system design and development has always been Israr's thing, right? And so, but both of us are educators, both of us know how to talk technical terms to non-technical people, and we come at this with 2 different perspectives which allow us to be very effective in delivering that message. And I think that sort of underpins why we took on that responsibility and that I think we did a decent job and were the right responsible folks to be able to do that.

**16:53** Yeah.

**16:54 Chris Romeo:** Yeah, and I've got a follow-up question that kind of came out of, as I was thinking about who you kind of aimed this book at, and you've got development teams in the title. Now, some maybe more classical thinkers are going to come at threat modeling from the perspective of, hey, we have a central security team, they do the threat modeling, they tell the developers what they got to fix. And then you've got the other side of the coin where it's like, hey, we're going to teach the development teams how to do this for themselves and make them self-sufficient. It sounds like you're leaning more towards the develop— the model where developers do this themselves. I'm curious to understand how you came to that conclusion and what you think about the centralized security people doing the threat modeling for everyone.

**17:39** So, I'll jump on this one. Like so many things in security, it comes down to culture. It comes down to the situation that you find yourself in. Some shops are lucky enough to have enough people or to have the right number of products so that they can have specialized security people pay attention to each one of them in the degree that they need. It's a big market, and anybody who tried to hire security engineers know how difficult that is. Together with that, if you come to think of it, And that's something that I hear, at least from Jim Manico, a lot, but from other people as well. Nowadays, that separation between design and implementation, between architect and engineer, has been blurred a lot. The way that we are developing things nowadays, you have some design, and then you have design decisions that happen at implementation time. So at the end of the day, it's the developer who's in the front line, who's writing the stuff, and who's deciding the stuff. And I think that bringing those 2 things together, the scaling function of the security team and the fact that you will always have one more developer writing one more story, brought us to the realization that it doesn't matter the methodology, doesn't matter what, the people who have to have the basic learning and understanding of what threat modeling is, what it represents, and what it can give you, must be the developer. And that's something that I think got repeated and amplified well in the Threat Modeling Manifesto, where we recognize that— and it's funny to think that between the 4 of us, I think that we are, what, almost 1/3 of the team that wrote it?

**19:29** Pretty close.

**19:32** So I think that's something that got amplified in there was this need to get away from the idea of the hero threat modeler, the, that specialist that comes in from the clouds, delivers this amazing document called a threat model, and from then on everything's secure. And to recognize that we need that every day at every resolution. So I think that a strong part of us putting the developer team in the title of the book and basically orienting the dialogue in the book to the developer, to the person in the developer team, and also to the QA and also to the product product manager and to the program manager was to make these people realize that they have an active part in the threat modeling process and that they can get some return on investment in there for them in their functions.

**20:21** And also, I'll also add that, you know, if your organization is— has a centralized security team that is doing threat modeling on behalf of a group, you have a need to make sure that those folks are educated enough to be able to have a good conversation.

**20:42** Yes.

**20:43** They should know the lingo, they should know the terminology, they should understand the action, right? And so even if your developers are not the ones driving the exercise, you need them to be educated anyway. So at the very least, if nothing else, right, this book is is geared towards a non-security mindset to be able to be security aware and to be able to take on this activity, you know, ideally as closer to where code or where systems are designed and developed than at the central— at a central authority. But if you have a central authority, utilizing this book as a means to educate your users so that you can have a good productive conversation with them is certainly something that I think we support, and certainly the book supports that, and we hope that it gets that use out of it. So, while it's not focused at the central security team, it is not designed to preclude them in that.

**21:44 Chris Romeo:** Yeah, that's good to know. So, in looking at the table of contents of the book, I'm noticing that the first section, chapter 1, is on modeling systems. And so, I think it's interesting. You've really given a number of different approaches that somebody can use to model systems. And this is going to be confession time for me. I, until just in the last couple of months, had never looked seriously at attack trees. I always thought people that did attack— I'm like, attack trees are just— I don't get it. And then I was looking closer at our friend Kim Voet's Linden project that she works on and is a big, you know, kind of public persona for.

**22:29** Yeah.

**22:31 Chris Romeo:** And they use attack trees, and I'm like, wow, the light bulb went on. I'm like, now I understand why people think— So I love the fact that you, that you've got a number of different scenarios here that people need to understand. I've always been a data flow diagram person. Like, it's everything for me flows logically through the DFD. Like, I can— I see the world in DFDs. So when you were looking at all these different, um, kind of approaches for diagramming, for example, like, are these things that you've used before and experienced, or was this the result of research, or where did this list even come from?

**23:02** Yeah, so I'll say first off that the design approach for the book was to be— to help people understand, again, the terminology, the concepts, and to be able to get an understanding of what it means to do threat modeling without being focused on a particular methodology. We wanted to give a broad stroke, broad view of that. And so one thing we wanted to make sure that we did was, so threat modeling is 2 parts, right? There's the modeling part and then the threat analysis, although we don't get analysis in the name, but it is definitely the second part of this. And so we wanted to be able to give folks the opportunity to express their systems in a number of different ways. Traditionally, threat modeling is DFD, right, data flow diagrams all over the place. The problem with DFDs, of course, at least from our perspective, is, you know, DFDs hide or mask or just ignore a lot of architectural information. You also ignore adversaries, and I'm gonna use these terms for those who are familiar with the manifesto, right, these are things that may be on one side or the other of the list. I'm gonna ignore that for the moment.

**24:21** Okay.

**24:24** So some models lend themselves well to certain types of information, but in order to have a complete analysis, you need to potentially have that information, right? So data flow diagrams give you good interaction information about how a process— what things are, how they're constructed or intended to be constructed, and how they communicate. Sequence diagrams then give us some ordering and some flow, right? How does data travel and sort of in what order does that occur, and then ATT&CK trees sort of give you a chain of events that you can then follow, right? And so all of the models that, all the model types that we include in the book are ones we've either used directly to do threat modeling or ones that we know can be applied to threat modeling, right? So we had fishbone diagrams in there. I don't know that anyone actually uses a fishbone diagram for threat modeling, but it gives you info— it is a model that gives you information that you can use to do better analysis, right? One really quick thing I want to call out, and it's actually been a— was a point of contention between us and our publisher when we were looking at producing this book, is you started with chapter 1, but the book actually starts with the introduction, and it's an extensive introduction which dives into the concepts of security and that are necessary as the underpinnings for doing your threat modeling and analysis. So I just wanted to let folks know that don't skip the introduction. It does have some valuable content, I hope.

**26:00 Chris Romeo:** Yeah, no, that's, that's fair. That's fair. And that's the foundation.

**26:03** Just to jump on that, and this is a pattern that I think that we— if you divide the book into 4 parts, I think that we repeated that across the book. Somebody that finished reading it told me that it felt like the, the the book intended to compress something that's extremely convoluted into a sequence of small tidbits that you could always get a bit more from them. And when you, Chris, said that, well, you looked at attack trees differently all of a sudden, that's something that I can say that in my personal journey happened a lot. You know, I learned one way of doing it, then I learned another one, and then I learned another one. And Apart from the differences in how you do it, each one of them offered me something else to look at the totality of this thing called threat modeling. So by putting things the way that we put, I think that we try to compress that journey for the reader in showing them, hey, listen, it's not that one thing is better than the other, but here are these different ways of doing it, and here are the things that we learned from each one of them. That may be better for you, that may be something that you want to build on, or that may make absolutely no sense for you, right? So I, I, I laugh, but what I would like to happen is that, you know, some manager hears about threat modeling, brings in his chief architect, gives the book to him and says, come back on Monday and tell me all about threat modeling and what I need to do in here for us to get something working. And the book would be able to give them that.

**27:39 Chris Romeo:** Yeah, yeah. And definitely, I mean, that's, that's been my experience in looking closer at the book. And you guys were nice enough to send me a copy, signed copy. That I did. I will tell you this, I did share it with another member of my team because I was like, you need to read this book because these guys really know what they're talking about. So just read this book from COVID to cover. And so, but, you know, in what I've seen in looking at this book, you've done a great job of covering a lot of different things that If we were to get a number of people together and take the list of methodologies that you had, it would be a battle royale to like— everybody would be fighting for their methodology and everything. And so, I really appreciate the fact that you've taken all of the competing methodologies and you're giving people a taxonomy, a way to kind of look through and understand how— what each of these things actually is. I mean, you've got things all the way down to includes no dirt, which, you know, that's— The author of that has been on the podcast before a couple years ago to talk about that methodology as well. But I just, I love the fact that there's a lot of different depth that goes into this that's going to help somebody. Because I'm thinking about the person that's new. Like, we've all been doing this for, you know, we're going to blush a little bit, but, you know, decades at least. Like, we've been around for a while. I mean, um, but, you know, for somebody that's new coming into this that doesn't have 2 decades of thinking about stuff in this particular way, I just love the, the depth that you're going to give them to not say, here's how you have to do it. Because, like, you could write a threat modeling book that was 5 pages long. Threat modeling according to Chris, but it's not gonna have all the depth that you have here. I'm only gonna tell you the way I think about it.

**29:17** But to tell you the truth, in that depth, there is something that we have to put out there. I think that it was pointed out to us that this is one of the first resources that looks at the different methodologies, both for modeling and for threat elicitation that together make threat modeling. And it's not that we graded things, we didn't. We are not saying this one gets a 10, this one gets a 5, therefore this one is better than that one. What we tried to do there was to point people to understanding that perhaps one methodology would be easier to implement if you're doing waterfall, and one would be easier if you're doing agile, so that they can better direct their study, their going in-depth towards something that will immediately help them. And again, we can compress the journey.

**30:05** Yeah. And it should be obvious by the nature of the book, and as you look through it, that what we tried to do was try to stick to So we tried to stick strictly to the concepts and the activity of modeling, of threat modeling, modeling and the analysis piece or elicitation, and avoid, I guess, all the other stuff that goes along with it, right? So unlike some of the other books out there that talk about threat modeling, we don't talk about— we talk about some security architecture concepts, but we don't talk about, okay, you found this, here's how you fix it. Or we try to avoid many of the other ancillary things that come out of this. We dabble a little bit in risk management, but only to really get people's feet wet and get them to know the terminology and what the big players are, and not really talk about, okay, here's how you handle your results.

**31:02** Yeah.

**31:03** And so the book is really focused on a developer taking it on, putting it on their desk, opening it up to chapter 1 or chapter 2, is like, I need to finish this task. What do I need to do? My security team, for instance, has asked me to create a model that they're going to analyze. What information do I need to deliver? Or I'm the security team and I have this model I have to analyze, or the developer, lead designer needs to figure out, okay, which methodology should I use? So that's really the approach that we took, and I think that that has worked out well.

**31:38 Chris Romeo:** Yeah, that definitely makes sense. And so I've got another question coming out of chapter 6 here, but Robert, I'm going to tee this one up and and say, let me ask my question here, and then if you can think up the hardest question you can think of about threat modeling. You've been doing this, Robert's been doing this longer than I have from a threat modeling perspective. And so I'm going to ask a softball question here while you think of the hardest possible question you can ask them about threat modeling, and then we'll come back to you. But let me ask this. It's not a softball, but chapter 6, Own Your Role as a Threat Modeling Champion. I'm somebody who thinks a lot about security culture and the people side of engaging this, and I love the fact that that there is a section called How Should I Deliver the Bad News? And so I just want to— I want to— There's never good news. There's never good news. I want to— well, I just want to understand, first of all, how you— I just want to— I want to hear the story around this section while Robert's thinking up his hard question.

**32:34** So once upon a time, in a job far, far away, Somebody on the product team showed me an email that circulated into the team that said something like, please don't talk to Isar anymore. Every time you do it, he finds something else. So I could already imagine myself in like a long leather black coat with a monocle looking at other people and saying, again, you did that again? And I noticed that, that it was time for me to start being a bit more diplomatic and change the way that I talk to people. About things that made me wonder why they did what they did. And that's when— and actually, that's something that I'm going to plug it in here— that Adam Szostak has been talking a lot about the soft side of threat modeling. And I think that this, together with what he puts forward, made me understand that, you know, that there is a very strong people dimension in this thing. and how you deliver the news of, you know, you have to change something very fundamental in your design, and that's going to cost you a lot in terms of development time. Otherwise, you're just open for the whole world. But there is a touch on how you go and you deliver those news. So we tried here to change the tables a bit, change the side of the table, and say, if I were that guy that just figured that got a finding that's bad enough that needs to fundamentally change things. How am I going to take this up? Or if I have to get my management engaged in threat modeling, how can I convince them? What else do we have there? How to choose a threat modeling methodology from many similar approaches. So those questions that anybody that gets tasked with threat modeling and doesn't have all that experience, but what can they figure out for themselves?

**34:31** Yeah.

**34:32 Chris Romeo:** And I love I love this whole topic because one of the things I've been thinking a lot about, and I just talked about it in my RSA talk for this year, is the idea of developer empathy. So, we as security people, and this is what you're showing here, is like you're showing that you've been on a path of growth where you went from being the person nobody wanted to talk to, to being the person who's like, hey, you got some problems, but guess what? I'm here, I'm rolling my sleeves up, let's go to work, let's get this thing going.

**34:57** Exactly.

**34:58 Chris Romeo:** You're not telling them, hey, that's the dumbest thing you could have possibly done, which a lot of us might have done early in our careers, But you've gone to this new idea and it's about— yeah, I mean, I'll raise my hand too. I've done the same thing a lot of times. I mean, but it's about us embracing the plight of the developer, walking a mile in their shoes and saying, hey, we are going to understand what you go through and we're going to help you get better with this. And that's really our goal.

**35:25** As security people, we really want to make that message that we're here as partners, we're not here as auditors. We're not here simply— we will tell you when something goes wrong, but it's our job to partner with you, either partner with you or be in the trenches with you, as opposed to like, okay, that's your problem, go for it.

**35:47** Yeah.

**35:49** And a lot of security is the soft skills, right? And so we wanted to make sure in the book, and I think we do this regularly in our day-to-day lives, right? that we're here to facilitate, we're here to enable, we're here to help and educate and really engage with teams and be their partner in security, not an adversary.

**36:14 Chris Romeo:** Yeah.

**36:16** I mean, we may take pride on finding things to fix or to make better, but that's our professional pride. At the end of the day, we're here to collaborate with the people who are writing products and who are writing systems and deploying stuff. We're not here to stop anybody from doing what they actually have to.

**36:31** Yeah.

**36:32** Right? But just to close it, I think that chapter 6, it goes together very well with what comes right after it, the Appendix A, which is the worked example. So we do that soft side of how do you engage with the thing, how do you engage with the things around you, and how do you do this whole culture dance. But then we jump into, okay, now you actually have to do a threat model. So what is it that you're going to do? A, B, C. So we jump from the very— I don't want to say touchy-feely, but I will— side of the thing straight into the work. And how do you get this thing actually done so that you can show that you learned something from here?

**37:17 Chris Romeo:** Yeah, practical. It's got to be practical. That's the only way that we get any movement to come out of this. All right, Robert. I know you've had a bunch of time to think about the hardest possible threat modeling question you could imagine. Hopefully you've been Googling, you've been like—

**37:32** I haven't been Googling, but I've been thinking. Actually, I was going to ask a question about chapter 6 as well, but I have had a chance to work with both you guys and talk about, I mean, from the very beginning or towards the beginning, because I remember you telling me about this back in early 2019 and had the privilege to take a look at some early chapters. And thank you for also sending me the book. And I'm listed as one of the reviewers, which I appreciate.

**37:59** And thank you for your feedback, both of your feedback actually.

**38:04** Absolutely.

**38:07** On the content.

**38:08** The last chapter or 2 were new. I hadn't seen those until they got published. And so definitely on— but there's one thing there that in terms of a question, the first couple of things are about leadership on board and and overcoming resistance. So my question is, okay, we know that threat modeling, you should do this early, do this often, and so forth. But you go into a situation where they have— they're hard fast on this is the way we do things, and threat modeling is not part of that. And they've got a lot of stuff going on. I mean, how do you— It's really related to that. How do you overcome? How do you help them to get over some of those, uh, those stages of, I've already done this, I don't need a new thing, I'm not ready for a new thing? Do you, do you finally just say, sorry, I wash my hands, I'm done? Or, or do you, uh, you know, so I guess that's where my question is, uh, for a champion who wants to bring threat modeling but They're not really sure if they can or do they keep going, that sort of thing. There are lots of companies like that where there are— and that actually kind of relates also to the leadership versus those who maybe are developers who want this, but leadership says, what's that? We're too busy building stuff to stop and think about a threat model.

**39:39 Chris Romeo:** Before you guys answer, Robert, virtual high five. Very hard question.

**39:44** Love it.

**39:44** It is.

**39:44 Chris Romeo:** Can't wait to hear their answer.

**39:45** I, I thought you were gonna give us a threat modeling question, and what you really gave us was sort of an organizational behavior question. That's a culture— It's a culture question. It is culture, but it's, it's also organizational behavior, right? Because what you're, what you're, what you're asking about, right, really is how do you convince an organization that the activity of threat modeling, this thing that, yes, you should be doing it, it as early as possible, ideally when you're designing a system, and obviously we'll keep agile development sort of separate there because you could be designing and implementing repeatedly. But how do you convince an organization that this task, that this activity is necessary, that it has value, and that it should be done?

**40:29** Right.

**40:31** And how do you change the mindset of the organization so that first off, they recognize that it has value, that they recognize that it's not this scary thing that's gonna completely derail everything that they've done. And by the way, there may be people within that organization who do think that, and you have to overcome those challenges, right? So this is really the psychological side of security, and boy, this is really hard for a lot of us, right?

**41:01** Yeah.

**41:02** It's easy if we say, okay, there's a technical problem here, But this is an organizational problem. This is building the culture and convincing people that this thing is necessary, right? And more importantly, adds value, right? And so the answer is really hard, right? Because the answer really is— let's take that step by step. How do you show it adds value? Well, it's easy-ish if they have You know, if they have existing products or systems that have been deployed that have, say, vulnerabilities that have been reported, or they have, you know, customer complaints, etc., and you can trace that back to a design decision that was made. So that allows us to start creating the framework to say, here's something that could have identified that early and/or prevented it, right? We can talk about about detection and mitigation or avoidance as topics, right? And that starts to build the value case. But that's only part of it, right? I'm going to stop because I'm about to lose my train of thought. I'll let Israr jump in a little bit.

**42:15** Actually, just closing that and bringing it down to the personal level, which I think is also important in this question, And borrowing from Chris, from the empathy, when you're doing a threat model, when you're helping elicit threats from a design that's being presented to you that you are not the author of, you are somebody who's being brought as a security expert, nobody likes to have their baby called ugly. So you step forward and you make it very clear, hey, listen, I'm not here to tell you change your design. I'm here assuming that what you designed is good and should work, and I'm here to help you protect your design. I want people to not get their grubby hands all over the data that your design is dealing with. So again, just as Matt said before, we are here to collaborate. We're here to be part of the process. We are not here as one more process. We are still the same process that you are doing. We are still the same process of design and implementation. But we are here to collaborate with you to protect this beautiful thing that you're building.

**43:23** And then once you show the value, now you can have that conversation of cost-benefit and risk management and the whole works. You're not going to win over everybody, right? It's still going to be onerous for some. It's still going to be scary for some, and that's fine, right? values change, right? Risk changes. And so it is a really hard question. Unfortunately, I think it has nothing to do with threat modeling, right?

**43:55** Oh, it can apply to a lot of things, right?

**43:58** It applies to a lot of things, right? Yeah. Why would you do static code analysis, right? Exactly. Similar approach. But it is important. And I think, just to bring it back to the book a little bit, we tried to present some of those ideas and concepts in the book, in both the introduction and chapter 6 and some of the other places, and actually really throughout, is sort of how do you facilitate those conversations as a developer? Because a lot of developers really want to do the right thing. A lot of designers want to do the right thing. And at various levels, everyone wants to do the right thing of what adds value to improve productivity, improve security, because that improves trust, that improves resiliency out in the field, and that And that ultimately drives both sales, current and future sales, and other things. It may not be easy to pinpoint what those contributions are, but it happens because if you don't have trust, you're going to lose, right? And so the book really tries to help folks sort of have those conversations. They may not get it 100%, but it definitely does at least provide them the ability to say, okay, I'm going to talk about risk management, or, oh, we're going to bring out this risk framework. We're going to talk about whatever framework we're using or how we rate the severity of issues, and then we can now have an apples-to-apples conversation. Right. Yeah, that's great.

**45:25 Chris Romeo:** And I'm going to kind of steal the key takeaway call to action as we bring our interview to a close. And I'm going to say Threat Modeling: A Practical Guide for Development Teams. This is a book that Robert and I both— this receives the Application Security Podcast seal of approval. It's the first book in the book club. We didn't really have one, but we're going to have one now. I just made that up on the fly. But I mean, the back cover of this book has an endorsement from 2 people that I think of as just legends, megastars in the industry.

**46:01** Thank you.

**46:01 Chris Romeo:** Alyssa Miller, who was a guest on the podcast just a couple of weeks ago, Brooke Schonfeld, who both of these people were— all of us in this interview are very fond of. To have them offer a quote on the back of a book right there is just priceless. I guess the key takeaway for the audience here is go buy a copy of this book. Buy a bunch of them and bring them and hand them out to developers. It's not a super expensive type of thing where you can buy some and hand them to developers. It's okay. This is going to be a very helpful resource for them. Matt, he's our Thanks for being with us today. Thanks for writing this book that I feel like we really needed at this time for where we all know threat modeling is going. And so for the audience, go buy a copy of this, read it, and then give it to a developer and spend some time helping them to understand what's in there. So guys, thanks for being with us today.

**46:53** Thank you, Chris. And if I can for one more second, I think it's important for us to point out that it's not the only book out there on threat modeling. There are some other great ones. And that one thing that we both got during the writing of this book was huge support from the community that we run through. And some of the names that we already mentioned, Adam and Brooke, and there are other people named in the book and thanked. And without their hard work before, ours would have been much harder.

**47:28** Yeah.

**47:29** So we really have a huge community, a huge small community here to thank for.

**47:35 Chris Romeo:** Yes, definitely.

**47:37** Yeah, I'll echo that, Chris, and thank you for having us on. I'm glad I had an opportunity to talk about my origin story, boring as it was. And thank you, Robert, for also for your feedback on the book, but also wonderful questions in the conversation today. Yeah, I think Izhar hit it right. There's a lot of work that preceded us, and we had an opportunity to sort of take that and distill that into some points that people can take advantage of. We didn't try to boil the ocean by design, so hopefully folks find it useful. And if you don't, like I said, there are other books out there. Pick up a copy of— I'll do the plug for Linden Go. Yeah, but wait, did you show the book? We didn't show the book.

**48:26 Chris Romeo:** We should definitely show the book.

**48:30** It's the funky fish on the front, if you like the ocean. And so, yeah, I mean, it's definitely— we had a fun time writing it. And I'll say that I think Izan and I both were gainfully employed at the time, and so we should thank our employers for giving us the opportunity to write it. Yep, there it is.

**48:54** Yep, very cool.

**48:56 Chris Romeo:** Well, thank you so much, guys.

**48:59** And I'm sorry, one other plug I'll just mention is if anyone else wants to contribute to the field of threat modeling, writing a book, working on an open source project, Azhar and I both work on the PyTM project, but there's plenty of them out there, doing research, doing papers, or speaking at conferences, like, or even just meetups like the OWASP meetups that Robert and other folks have been driving. Definitely get involved. It's the right thing to do.

**49:27** And threat model all the things.

**49:29 Chris Romeo:** Threat model all the things. Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, with application security, there are many paths, but only one destination.

---

Source: https://appsecpodcast.com/izar-tarandach-and-matt-coles-threat-modeling-a-practical-guide-for-development-teams/