As product managers, we’re taught to prioritize customer needs above all else. If that’s correct, where does threat modeling land in our list of priorities? After all, if we can’t provide a secure solution, our users will go elsewhere. Chris Romeo, CEO and co-founder of Security Journey, suggests we “shift left” to get these concepts into the conversation as soon as possible.

In this episode of the Product Momentum Podcast, Chris joins Paul and guest co-host Jonathan Coupal, ITX Chief Security Officer, for an impassioned conversation about Security and Privacy – often-overlooked dimensions of application and system quality.

“Security and privacy are rarely written ‘on the same napkin’ as the new product idea,” Chris says. “Lots of times, they end up being added later, resulting in lots of developer rework. So we use this concept of ‘shift left’ to describe the notion of moving that security mindset earlier into the development process.”

Chris’ mission is to bring security culture change to all organizations. In this episode, he discusses collaborative threat modeling and other tactics that can feed your organization’s security culture. Intuitively, we already know how to threat model, Chris adds. We just need to adopt this mindset when building our products.

Listen in to hear more from Chris Romeo about threat modeling for product managers, including:

• How security has gained importance over his career
• How to build a program of security champions
• The importance of cross-team collaboration

Podcast: Play in new window | Download

Sean [00:00:19] Hello and welcome to the Product Momentum Podcast. This is a podcast intended to entertain, educate, celebrate, and give a little back to the product leadership community.

Paul [00:00:28] As we’re working on product design as product leaders, sometimes we need to deal with these invisible threat modeling, nonfunctional requirements. So in order to deal with a real specialized topic like this, you’re going to hear a new voice on the pod today, our resident CSO, Jonathan Coupal, MCSE, Security+, CISSP. Jonathan, thanks for joining us today. Welcome.

Jonathan [00:00:53] Yeah, thanks. I’m really excited to be here. I’m especially excited to be able to spend some time with you talking to our guest, Chris Romeo. He’s been a leader in the security industry, especially when it relates to product design and bringing security as part of that product design space. He’s an advocate for threat modeling and is actually one of the signers on the Threat Modeling Manifesto. And I think we might be able to learn a lot about this approach to dealing with, not only nonfunctional requirements but dealing with threat modeling as a process.

Paul [00:01:27] Yeah, totally agree. And I’m really glad you’re here to dig into some of the real nitty-gritty details here. So why don’t we go ahead and jump right in?

Paul [00:01:37] Well, hello, and welcome to the podcast. Today we are excited to be joined by Chris Romeo. Chris is the CEO and co-founder of Security Journey. He’s the builder of security culture influencing education. His passion is to bring security culture change to all organizations, large and small, by providing gamified security programs. Chris was the Chief Security Advocate at Cisco for five years, empowering engineers to shift security left in all products and lead Cisco’s Security Belt Program, Cisco Security Ninja. Chris has 24 years of security experience, holding positions across the gamut, including app security, security engineering, and incident response. And if you want to find him online for more conversation, you can usually hit him up on Twitter at @edgeroute. Chris, welcome to the podcast. So happy to have you!

Chris [00:02:22] Yeah, thanks, Paul. I’m happy to have this opportunity to talk about product and security and kind of the interactions there.

Paul [00:02:29] Absolutely, yeah. So most of our audience are product managers and product leaders in their teams and often the other aspects of product management get the spotlight. But we really do need to start taking a look at threat modeling and how we can build security into our conversation. So let’s start there. What is this thing called threat modeling?

Chris [00:02:45] So when we think about threat modeling, here’s the definition that I’ll give you right off the top. So analyzing representations of a system to determine if there are security or privacy challenges that exist. So let’s break that down a little bit, because I know it sounds like maybe a dictionary definition. So analyzing representations of a system. So as a product manager, think about the things that make up the system from your perspective. You know, you’re specifying user stories. You know, you’re getting feature requests from a customer, you’re going to a user story. So threat modeling is, how can we use a process to look at that user story and say, “are there any dangers from a security or privacy perspective?” while we’re in the process of planning our future sprints or as engineering picks up the particular user story and starts to work on it. And so this is really the essence of threat modeling: how do we figure out what those security and privacy problems are early because the worst thing that can happen is we push to production, “oh, we forgot about security, we forgot about privacy.” We all know where that leads us right now, a lot of uncomfortable customer conversations and challenges and… All the way up to loss of revenue and other types of challenges there. So when you think about threat modeling, that’s really the core definition.

Jonathan [00:03:55] Yeah, listening to your definition, one of the things that occur to me is you’ve chosen to restrict your definition to just security and kind of that space. Is that because it’s your specialty? It seems like there’s a real possibility you could introduce threat modeling as a way to manage product design in general for those NFR, the non-functional requirements that are not necessarily just security, like threat modeling for performance problems and threat modeling for other things that might go wrong. Like how could we fit threat modeling as a more generic process, I guess, into product design?

Chris [00:04:26] Yeah, I think you can use threat modeling, the process. And so when you think about threat modeling, we’re trying to get to a mindset. Okay, we’re going to talk about this in the context of a process, a number of steps we can go through to find problems, whether they’re security, privacy, we could extend it to performance and other things. But really, what our goal is here is, how do we get people to think about these things? Versus saying, “Hey, we just have to run this process all the time.” We want the mindset to change so that over time, product managers, engineering, test, development, DevOps, production, they start to see these types of issues.

Chris [00:04:58] But yeah, it’s a great point. I mean, when I think about teaching people threat modeling, like, one of the things I always say as a caveat is, once you learn this process, it’s going to change how you approach everything. Because, for example, you walk through the airport security line, you start threat modeling. You start looking and going, “What are all the challenges in this process? Well, someone could throw a bag over there far down the way, and if somebody wasn’t watching in that closed area down there and then they could climb over the fence…” You know, things start jumping out in your entire life that are tied back to, from my case, security and privacy challenges. But that’s one of the things about threat modeling is once you grasp it, it’s something that pops up in the rest of your life in a lot of different places.

Jonathan [00:05:34] Yeah, it’s interesting that it actually gives a name to a process that I think a lot of people do intuitively. I remember I was talking to a guy that came out of the banking industry, and he described how they talk about new financial instruments. And, you know, he was coming from the audit perspective and he described, like, how we dealt with it and it was threat modeling. It’s like, how can people mess around with this instrument to subvert it? And how do we put blocks and controls in place to prevent that from being abused, essentially?

Chris [00:06:02] Yeah. And to your earlier point about, you know, using threat modeling and a lot of different kinds of perspectives, when I teach this to a group of people, one of the first points I make is, everyone in this room already knows how to threat model. People look at me and they’re like, “You know, I’m brand new in this class, what are you trying to tell me here?” Think about it, though, right? Like we threat model in our everyday lives. We just don’t call it threat modeling. The example I use all the time is like, imagine you have to walk a small child to school. You come out the front door of your house and you’re standing there, and all of a sudden you hear cars flying by on the street, driving way too fast. What do you do? You reach down, grab the child’s hand and say, “Hey, hold onto my hand here, these cars are going way too fast.” What did I just do? I threat modeled. I said there’s a threat. The child could run into the road. My mitigation is I’m going to grab the child by the hand. And so when you share it in this way to people, they start to see, “Oh, wait a minute, I already know how to do that.” And so now threat modeling is about how do we now get you to take these ideas that we all do in everyday life and focus them on our products, our applications, our features, things that we ship to customers? That’s really where threat modeling comes together.

Paul [00:07:04] Yeah. As a parent, that definitely resonates. You know, one of the things that hit me in doing some research for our conversation today has been the concept of the Threat Modeling Manifesto. And I was wondering if you could talk a bit about the story behind that concept and how that came to be. It’s obviously modeled off the Agile Manifesto in sort of format, but why did that group of signers feel so compelled to make that sort of monolith as a threat modeling concept?

Chris [00:07:28] So I’ll tell you kind of the story of how we got there to kind of answer the question. I’m going to circle around it a little bit first.

Paul [00:07:34] Yeah, please.

Chris [00:07:34] So Adam Shostak is one of the most well-known people in threat modeling. He was at Microsoft. He helped to build what we call threat modeling, at least in the tech world right now. And so he and I and another friend of ours, Mark French, we were on a phone call about two years ago now and were like, “All right, we’ve all been a part of this for a long time, like, how can we give something back to the community that would have benefit and value to people?” And we were like, “OK, we can do something threat modeling-related.”.

Chris [00:08:00] And so what we did is we reached out to a number of different people that we know across the industry. We got a group of people from academia, we got consultants, we got trainers, we got people that work in tech companies rolling out threat modeling programs. And we said, “let’s all get together and see if we can agree on, what is the essence of threat modeling?” That’s where that definition came from, the analyzing representations. And so what we did is we came up with a definition that we all agreed to. Then we said, “OK, what are some of the values that come out of this?” Just like the Agile Manifesto, you know. One of those values, as an example, is, you know, people and collaboration over processes and tools. So just like in Agile, both of those things are good, but in threat modeling, it comes down to the people collaborating together. You can deploy a tool to do it but if you don’t have a culture where product manager, dev, tester, DevOps people, are all sitting around the table together saying, “Let’s do a threat model,” you know, you’re not getting the true essence, the true value out of this.

Chris [00:08:56] So we came up with those values. We came up with some principles, put it all together, and released it to the industry to say, “Hey, if you want to understand,” I like to call it the essence of threat modeling, “here are all the things you have to understand.” And then it sets you up to be able to go into your startup, to go into your enterprise and say, “We’re going to adapt this and make threat modeling a reality in what we do.”

Paul [00:09:14] Cool. One of the things that it got me thinking about is just sort of what the size of the aperture is on what threat modeling represents. And I wonder if you could help me gauge my own understanding. When we talk about threat modeling, often we go to holding children’s hands in busy streets or TSA checkpoints and how would a bad actor get through if they really wanted to? And a lot of times we talk about threat modeling as if the threat is only a bad actor. Is the tent big enough to include also ignorant actors or poor experiences? Are those threats too?

Chris [00:09:46] Yeah, I mean, you can consider the mistakes in a threat model as well, and that’s a perfectly valid threat is to say, “Hey, someone with access and privilege to our production system makes a mistake and does this or that.” OK, how do we mitigate that? OK, well, that person should have never been on the production system. The production system should be fully automated. When something passes our build pipeline and gets pushed into production there shouldn’t be anybody on production. Right, like it should be stood up and then torn down. OK, so we identified a threat in that somebody could have made a change or been in production. Our mitigation is they shouldn’t have been able to, so how are we going to cancel that? And so it does fit into where you’re going with this as well as far as being a wider type of area that we can cover.

Jonathan [00:10:28] Yeah, that makes sense. One of the things I was initially challenged with when I was working the threat modeling process here with our own teams was that the process seemed more tuned to dealing with threat modeling in a waterfall environment. Like, you build your data flow diagram, you apply the model, you know, you play elevation of privilege against that data flow diagram or whatever with the assumption that you’ve already got an established architecture and you’re threat modeling the architecture. But what would you say like a good approach is to move from that waterfall approach to like an agile approach where you may be bringing new features and new stories into existence on a really regular basis? How do you do that without having to bring in a preponderance of people every time you introduce a new feature?

Chris [00:11:14] Yeah. So in my kind of perfect scenario, like in an agile world, I’m thinking about threat modeling at the feature or user story level.

Jonathan [00:11:23] Mm, okay.

Chris [00:11:23] So, and the other thing is, I want to enable and empower everybody to do threat modeling. So one of the challenges that we talk about in the manifesto is sometimes you’ll have this idea of a hero threat modeler, and it’s like, “OK, that’s Jane, she sits over there, she does all our threat modeling.” Well, the problem is Jane has a pile of threat models that build up because there’s the 25 people in the engineering department she’s working with and she has to threat model everybody’s stuff.

Chris [00:11:45] So a better model is to say, “let’s teach everybody how to do this.” And a lot of threat modeling is teaching by doing, like in classes and stuff like that. Because it’s one of those things, it’s like going to the gym. The more you start pushing the weight up, the better you get at going to the gym, for example.

Jonathan [00:11:59] Mm-hmm.

Chris [00:11:59] And so that’s really the important part about how you can put this into action. Now, when I think about it from an agile perspective, we have to figure out, when’s the right time to do threat modeling? So do we want to try to push it back into the product management side so that threat modeling is occurring before we even schedule a user story for a particular sprint? I mean, I would love that, like as a security person who’s been doing this in, you know, startups and large engineering companies for a long time, that almost never happens. But that’s like the perfect scenario. Like, if a product manager understood threat modeling and then could bring other resources to the table during the planning as far as, “what are we going to build?” If you’re thinking about the security challenges there, that’s ultimately the least expensive, least amount of rework that’s going to happen as you go through the rest of the process.

Chris [00:12:43] Now you can assign threat models in a sprint, for example, which is what most people tend to do. Like I said, I wish it happened in a pre-stage to the sprint, but what most people do is there are hours committed to it as part of the story. So whoever is the owner of the story, like in engineering, they’re responsible for doing the threat model. Sometimes you’re going to have a small feature that’s not going to need to be threat modeled, like, you know, anything that’s CSS-related where you are changing colors and things, like there’s not any new security threat there.

Chris [00:13:11] And then what you can do is you can scale it from a resource perspective and say, “OK, we can scope it as that’s kind of small, so maybe we have one or two people kind of spend 10, 15 minutes just on a whiteboard kind of picking it apart and documenting what they do.” “Well, this is a new, gigantic feature. OK, so now we’re probably in a large category, now we probably need to bring, you know, five, six, seven people together.” So I think it’s one of those deals where you can move the levers and knobs based on what you’re actually building. And you’ve got a lot of freedom in this. Like there is no book or standard that says, “here’s how you have to do it.” Just like agile, right? I mean, everybody does agile, but…

Jonathan [00:13:44] As long as it’s agile-ish, right?

Chris [00:13:46] Yeah. There are intricacies in how you do it. So I think you can do the same thing from a threat modeling perspective, though. Be able to make it fit in your world, right? So that if you know that your resources are tight and executives are saying, “Yeah, we think this is important, but we’re not going to hire ten people to do it to the size of the organization.” So you can say, “Well, we’re going to do a light, compressed version of this so that we’re at least doing something.” We’re building that muscle inside of our team’s ability.

Paul [00:14:11] I want to pull on something you said a minute ago about, you know, wishing that product managers were essentially more empowered to drive this into user stories and carve time out for the team to do this. The thing that, this is my personal opinion, I think, is most beat into product managers’ heads is, you need to spend more time talking to users. You need to be obsessively customer-centric. And we spend a lot of our time drafting this vision for a product that meets the unmet needs of the customer, or the client, or the end-user. And I can say a flaw in my own process over the years has always been preferring that feedback over anything else. So speaking for the product managers hearing this maybe for the first time, what is a way that we can build this into our process, day-to-day?

Chris [00:14:56] Yeah. I mean, if you can get this added to the definition of done for a user story, like in a world where engineering is going to primarily drive the threat model and product management is going to be aware of the need and not necessarily be the drivers, I’ve seen adding it to the definition of done. I mean, in a pure, agile world, it can’t be done if you haven’t done those things on the list. Everybody agrees to it, right? So that’s one way.

Chris [00:15:16] Back on the front side when we think about the product management and what you’re saying about, you know, customer centricity and focusing on the end-user and the experience and everything. If you ask your constituency about security, you don’t even have to ask the question, “how important is security to you?” It’s like, “Uh, yeah, it’s…”.

Paul [00:15:34] Table stakes.

Chris [00:15:35] …crucial, like, if you don’t give me a secure solution, I will go somewhere else, done.” Right. And so if you’re in a situation where you’re like, as a product manager, I want to see us do threat modeling, I want the product managers to be a part of the threat modeling process, and you’re getting pushback… There’s not as much pushback as there was early in my career. There used to be a lot of pushback about security and privacy, like, “what are you even talking about? Like that’s not going to sell us any more product.” But that’s changed now. But I think as a product manager, you can also help to channel what your user population and customers are thinking about security. You can even ask them, “Hey,” and you got to be careful in that one, right? Because you don’t want them to come away going, “these people don’t have security figured out at all,” but you want to be able to understand what their expectations are as well and be able to bring that into your process.

Jonathan [00:16:17] Yeah, there’s a lot of value in vocalizing those expectations and associating it with its apparent cost, especially if you’re doing the development consultatively as opposed to doing it as an in-house team. Somebody’s got to fund it, unfortunately. One of the things that I’ve seen in your writing has been the idea of security champions. Can you talk a little bit about what you mean by a security champion?

Chris [00:16:38] Yeah. So in the last probably few years, security champions has become a very popular term. Really, the idea of a security champion program is let’s have a virtual team of people who are security interested. So it may just be that there’s somebody who just says, “oh, this security thing, I’ve heard a little bit about what we’re doing here, I just want to learn more about it.” Sometimes, you know, they’re kind of told or they’re volunteered by their management structure to be a part of it.

Chris [00:17:03] But the idea is, let’s build this community of people that are willing to share best practices. You know, this is a group of people inside your organization, so you’re inside the walls. We can talk openly and freely, and it’s an opportunity for people to say, “Hey, we were focused on trying to get this security feature done for this customer,” let me share a little case study about what we did.” And then one of the other things you can do is you can bring in outside folks to speak. You know, I speak at people’s security champions meetings all the time. Especially in a virtual world, you know, it’s easy to bring other people in that have different expertise to educate your people.

Chris [00:17:34] But really, at the end of the day, this is about security culture. That’s what we’re trying to change is inside of your organization, there is a security culture. Now, if you’re sitting here, listening to this going, “I don’t think we have one.” Well, you have one. Don’t worry, everybody has one, it’s just where are you on the scale of 0 to 10? If you think, “we don’t even have one here,” you’re probably closer to the zero or one. But security champions are about, at the end of the day, we want to be able to make our security culture better, and by having people who are championing security, but yet are not part of a central security team, that’s another key. Because you’re never going to have enough security people for the number of products you’re building. It’s just the reality of the world.

Chris [00:18:10] So you have to empower other people from different teams, whether it’s product management, whether it’s dev, whether it’s test, whether it’s DevOps, wherever they’re coming from, you have to empower them so that they become people who are out, part of the process, putting their hand up and going, “Hey, we talked about this at a security champions meeting, we should probably get some other insight from maybe somebody on the security team or…” You know, so they become eyes and ears, but not in a bad way like they’re reporting back and where security has a clipboard of, you know, who’s not doing things correctly. It’s really more about, how do we change the culture? How do we all get better at doing security and privacy things?

Jonathan [00:18:45] Okay. So it’s almost like you’re bringing folks on the team to the problem with a new lens like, oh, you’re a performance champion, for instance. So they might be looking at the refinement process not only as a developer, but as a person who thinks a lot about performance. And the same way with security? Like, is that the reason for the approach and how do you kind of start a program like that?

Chris [00:19:05] Yeah, I mean, definitely the reason is to be able to share those best practices. And even when you think about performance and security, what you just described, a performance problem can be the result of a security issue, right? Like, we still have distributed denial of service scenarios in the world where all of a sudden you get 100 gigabits per second of traffic sent inbound into your production application. Right. Like, it’s a performance problem and a security problem. So there’s even avenues for people to collaborate in different ways there.

Chris [00:19:32] But really a good way to start one of these is it’s good to have some type of executive sponsor for this because you are asking people to do something else above and beyond their existing job description. So it’s very seldom have I seen an organization where they write champions into the job profiles and descriptions.

Jonathan [00:19:49] Yeah.

Chris [00:19:49] A lot of times, unfortunately, it’s nights and weekends for some people, but the catch is you get people who are passionate about security. They’ll put in a little extra effort to do it. So getting some type of an executive sponsor and then really it funnels out of that initial monthly meeting, having a meeting once a month where you’re having a forum to share security things. You want to get the security team involved as well because they have things they want to share with the community about, “Hey, we have a new tool that’s going to help you, you know, scan your application quicker and so we just want everybody to know about it.”.

Chris [00:20:18] And then over time, as people start to get more comfortable, you could start to have these case studies and, “Hey, let’s talk about this new feature that we did, let’s talk about how we handle authentication in this feature in a new way we’ve never done it before here.” Oh, Team B is sitting here listening, going, “Wait, we got that same problem.” Team A and Team B aren’t necessarily going to collaborate organically, but when they’re in that forum, they could be, “Oh, let’s go talk to those folks, like they have already gone down the road of trying to solve this problem, and we don’t have to do it from scratch.”.

Chris [00:20:42] And so that’s really, for me, it’s the executive sponsor and then the monthly meeting is really the core place. And, you know, from a recruiting perspective, like I was responsible for Cisco’s, we called it a security advocate when I was there, and it had kind of started and died and then started and died. And I was kind of like the third person trying to reinvigorate it. And I literally flew out to San Jose. This was, you know, back in the mid-2000s, I made a list of people and I went literally building to building and I knocked on people’s cube doors. I said, “Hi, my name is Chris, I’m restarting the security advocate team. Do you want to be a part of it?” And so I ended up getting like twenty-five people out of this crazy cube cold calling thing. But I got a group of people that, you know, some had been part of the previous generations of this, and they were like starting to get excited about it again.

Chris [00:21:26] So, you know, it’s just being creative in how you reach people and how you bring them to the table and then provide them value. You know, that’s one of the other keys in this idea of champions is like, so often, people think about, “well, as the company, the champions program exists for me so we’re better at security.”

Jonathan [00:21:40] Yeah.

Chris [00:21:40] Flip it back around and say, “How are we going to make your job as a product manager, your job as a developer, easier, better, or teach you more about the things that you need to do your job?” And when you start to think about it like that, that’s when you start to see these programs really take off because it’s not about the company, it’s about us helping you to improve your career, improve your future, whether it’s security, privacy, performance, whatever angle.

Jonathan [00:22:02] Yeah, it’s kind of funny to hear you tell stories about Cisco not being super excited about security. It makes me feel a little better about where we are.

Chris [00:22:10] Yeah, I got to see Cisco go through a real transformation. Like now, Cisco is very security-focused inside, across the organization. But you know, in the early days of my time there, that wasn’t the case, but that was the case for everybody in the industry.

Jonathan [00:22:21] Yeah.

Chris [00:22:21] This is, you know, post a number of different Microsoft worms and things that got a lot of attention from everybody in the industry. I’m starting a date myself here as first when I got into this business, you know, but everybody was in the same boat back in those days from a security perspective, and I got a chance to be at Cisco while we were making this transformation to really everybody being super excited and passionate about security.

Paul [00:22:41] You know, a couple of things that have stood out to me just in hearing this story, this journey, has been just how people-centric this is. You talked about really being passionate and getting into this room and sort of beating up ideas and not beating up people. And the cold calling cubicle, that’s just like a beautiful story of like, you know, it’s not about the system, it’s not about the elegance, it’s about the people. And really, when you have a culture of conversation and a culture where people can express that passion that they bring to the table in a way that helps others out, I think that’s a really cool aspect of this whole journey that you’ve been down. I’ve got one last question to wrap it up and it’s really, you know, a phrase that appeared in your bio. I’m not sure who coined it, but this concept of shifting left, maybe we can talk for a minute about what this means. I think it speaks to the definition of done and user stories, but I think it’s bigger than just when something happens. We use it in the context of accessibility. If it doesn’t meet WCAG standards, we want to make sure that those kinds of things that, honestly, tend to become afterthoughts, are pushed left. What does it mean to you to shift left in this conversation?

Chris [00:23:46] Shift left is about, how do we get security and privacy into the conversation from the time where we have an idea about a product? Because so often, even in this modern day and age, security and privacy are not something that’s thought about on the napkin when somebody has an idea for a new product. And it ends up being added in somewhere later into the process. And so we’re using shift left in the same way you’re describing it from an accessibility perspective. It’s like, when we think about the lifecycle of the product being what we’re shifting, instead of thinking about security and privacy at the production stage when we’re getting ready for customers to start using this, we’re shifting left as far back as we possibly can.

Chris [00:24:22] If we can get to the product idea, that just speaks to the strength of our security culture. I mean, in a very strong security culture, there’s a security and privacy conversation at the light bulb phase. Like, the light bulb goes on over somebody’s head, they’re like, “We could do this and this and this, oh, but that’s a lot of customer data and so we’d have to make sure it was protected properly and…” You know, so it’s all about, how do we get security and privacy being considered as early as possible because we know developers don’t like rework. And what happens if security and privacy move closer to production, closer to kind of shipping, and further away from when things are being designed and coded and tested? We end up in this world where we’re constantly fixing things later in the process. And at the end of the day, do you want to talk about making developers unhappy? That’s one of the things that makes them unhappy. They like to put their head down, do something, make it work, ship it, and then go work on the next thing. They hate switching tasks back and forth like, “Oh, let me load that thing up again that I worked on two weeks ago and now you’re saying has a security vulnerability?”

Jonathan [00:25:20] Gotcha. So I’m kind of a visual learner, so I’m going to ask you if there’s a good, like, book that you could recommend that’s more product development-centric rather than, like, specifically security-centric? Or alternatively, you know, is there something that you’re working on that you’d like to kind of plug or promote that would be interesting for our listeners so that they can learn more about threat modeling in general?

Chris [00:25:43] A couple of different things to think about as far as resources that you consider in the threat modeling world. I will recommend a book and then I’ve got a couple of podcast things I’ll mention from the Application Security podcast, the podcast that I do. There’s not a resource that I’ve seen that’s tailored to product managers. Unfortunately. I wish there was a book, like I wish I could say it was like “Threat Modeling for Product Managers,” but it’s not a part of anything that I’ve ever seen.

Chris [00:26:06] But I will share a book by a couple of co-Threat Modeling Manifesto authors, Threat Modeling: A Practical Guide for Development Teams. So this is by Izar Tarandach and Matthew Coles. It’s the latest book that’s been written about threat modeling and it just gives you a lot of high-level detail. I think there’s something in there for everybody. Product managers might not want to go to the depth of understanding all the methodologies and things, but there is a lot of good stuff about how does threat modeling fit into agile, DevOps, and, you know, a little more context about what it is and how to put it in perspective.

Chris [00:26:33] On the Application Security podcast, the podcast that I co-host, we talk about threat modeling probably about a third of the time. So if you go and look up Application Security podcast and just search for threat modeling, you’ll see we’ve got different backgrounds and perspectives of people. You know, we’ve got an episode with a guy from Segment about how he rolled out his threat modeling program, somebody from GitLab about how they rolled out their threat modeling program, and then we’ve got, you know, executives like Jim Ralph, who’s built software security programs at like five different gigantic companies and kind of getting his perspective from a high level. So some different perspectives for how you can understand this at kind of different levels and even hear how other companies are doing this from a best practice perspective.

Jonathan [00:27:13] Thank you.

Paul [00:27:13] That’s great. And if anyone’s listening in the car, we’ll definitely link your podcast in the show notes so people can find it later and look up more about threat modeling and other security-related concerns. Chris, it’s been a blast chatting with you, I learned a ton, so thanks for taking the time out of your day to be here with us.

Chris [00:27:27] Thank you.

Paul [00:27:28] Cheers.

Paul [00:27:31] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world just like you’re doing. Thanks, everyone. We’ll see you next episode.