Ben Oster: [00:00:00] Now you can build an attack at the samepace you can build an application using AI.

Ashish Rajan: I'vebeen in cybersecurity for at least seventeen plus years, and I don't rememberever going back to the first threat model that I did for an application.

Ben Oster: You seeabout eighty percent of the models never get revisited.

Ben Oster: Inprobably about six to nine months, you've gone from this is a multi-week,multi-month project to you can have a threat model for a complex application inhours, if not minutes. I don't think of AI as this thing that's gonna replaceeverybody's job, but I worry about the entry level jobs.

Ashish Rajan: Assecurity people, we love threat modeling, but the engineering absolutely hatesit.

Ben Oster: A smallchange that cascades across a microservice to three thousand differentlocations is not a small change, even if it feels like a small change on thatPR. Now how do I trust that the AI is getting it right? And I kinda said,"What controls do you have in place to trust your humans are getting itright?"

Ashish Rajan: I havea question for you. When was the last time you did a threat model for anapplication? Perhaps you were involved with the first [00:01:00]threat model that happened, but were you involved with the second or thirdsystem design change that happened? Were you even informed of it? Some of theseare the questions that I was trying to tackle with Ben Oster fromThreatModeler.

Ashish Rajan: We weretalking about why the shift of just doing a point in time threat model as aconcept has evolved so much than just the people who love STRIDE and any otherway of threat modeling because the way we are developing code today, wherebasically the amount of code being published into a GitHub or a GitLabrepository is just so enormous.

Ashish Rajan: AppSecpeople are already under the pressure, and this tiny little thing, which isalways assumed that, hey, someone somewhere had done a threat modeling in thebeginning and then followed up with a pen test exercise right at the end of itto make sure that those gaps were never missed. It's slowly being questionedwhether it should exist in the old way.

Ashish Rajan: So inthis episode, I had Ben Oster from ThreatModeler.ai. We were talking about theneed for change to how threat modeling is done and what is possible with AItoday if you were to just appoint a LLM model onto the systems you care [00:02:00] about. And how do you get to a point andwhy do you get to a point where you want to have a threat model of the entireorganization and not just a point in time of the application you're looking at?

Ashish Rajan: Allthat and a lot more in this episode of the podcast. As always, if you are herefor a second or third time and have been finding the episodes valuable, I wouldreally appreciate if you take a quick second to hit the follow or subscribebutton, whichever podcast platform you listen or watch this on.

Ashish Rajan: We areon all podcast platforms like Apple, Spotify, YouTube, and LinkedIn, andwherever you consume your podcasts from. I hope you enjoy this conversationwith Ben, and I'll talk to you soon. Peace. Hello, and welcome to anotherepisode of Podcast. I've got Ben with me. Hey, Ben. Thanks for coming on theshow.

Ben Oster: Hi, niceto be here.

Ashish Rajan: Well,maybe to kick things off, if you can share a bit about yourself, yourprofessional career, so people know where you're coming from and what you'vebeen doing.

Ben Oster: Yeah,great. So I've been in product management for, it feels like five yearssometimes, but almost 20 years now. Yeah. I started in privacy and compliance,and like all good product managers, kind of started with a problem statement,and just kind of from [00:03:00] there movedinto more direct cybersecurity and made the shift over to threat modeler asCPO, um, this year around shifting everything left, getting in front of thesecurity problems that we were seeing in my last role.

Ashish Rajan: Okay.And I guess threat modeling is interesting because when you and I were talkingbefore the recording, I was literally talking about the fact that threatmodeling the Idea of being continuous is super new to me. Not because it shouldnot be done, but because every threat model, like I've been in cybersecurityfor at least 17 plus years, and I don't remember ever going back to the firstthreat model that I did for an application.

Ashish Rajan: So I'mcurious as to what we have been doing for decades now, where we do look at athreat model in the beginning and then none of us ever get back. Well, okay,maybe not a fair statement. People do go back to it when there's a, quote,unquote, like I'm gonna air quotes, major changes to the architecture and blah,blah, blah.

Ashish Rajan: But howoften have people actually been called, or how often has the same person beencalled? So I see like this happening across [00:04:00]mature security programs as well. So I'm curious, why has a threat modelremained like that even though it's supposed to be like the mo- the mostimportant thing ever in the whole design process or building process?

Ben Oster: Yeah, Ithink there's a couple reasons. I think one, to your point, we see about 80%,like in traditional threat modeling and everything that we have, likehistorical data, we see about 80% of the models never get revisited, right?They, you set them up as a blueprint for where you wanna go and what you wannado, but I think the biggest burden was that they were just so hard to do, andthey were hard to do well.

Ben Oster: And so itwould take a long time to build a threat model. That had to become your kind ofmap. But just like when you're driving on the road, sometimes there'sconstruction. And Google Maps, we're used to Google Maps now telling us,there's construction, take this other route. Yeah. When we were on paper maps,right, y- you had no idea that there was gonna be traffic or you were gonna bedelayed.

Ben Oster: And itfeels a little bit like this kind of paper map versus digital [00:05:00] map has, has shifted that conversationand, and there has to be something that gives. But honestly, I think it wasjust too hard to go back and revisit them. We built them, it took us months tobuild them, weeks or months to build them.

Ben Oster: We'd s-we'd use them as a baseline, and then the process of developing against thatthreat model would take, months or years in some cases, depending on how yourengineering org was set up. And there just wasn't really value in going back tothat because you weren't keeping it current with the day-to-day of the workthat was being done, and I think that can reset.

Ben Oster: It's hardto reset those maps when it takes another three weeks in a room.

Ashish Rajan: Yeah.It was a fair question on the time thing, but also the, I think I find that- Assecurity people, we love threat modeling, but the engineering absolutely hatesit. I wonder if people would leave a comment saying, "I love..." OrI'd be surprised if someone from security comments saying that they hate threatmodeling.

Ashish Rajan: Uh,it's just like a not a, not a thing, because the, to what you said, it's veryresource intensive in the beginning. You need the engineering- Yeah ... team inthe room, you need the [00:06:00] rightintegration people in the room as well to identify, like perhaps you have aConfluence space that you have attached onto a repo.

Ashish Rajan: I feellike with AI, perhaps maybe my understanding has shifted a bit more. I alwaysthought I can just point AI to an application and get a app, a threat model foran AI system or even like a, or not even an AI system, again, an existingenterprise application that I'm building. Is that not true today?

Ashish Rajan: Like,what would be different about, uh... Like obviously my initial knowledge mayhave been limited to how much I knew the system and everything else. Is thatdifferent now that we have AI?

Ben Oster: Yes. It'sbeen a fundamental shift in the way people are doing this, right? There's nolonger the need to take weeks or months to build these models.

Ben Oster: You talkedabout getting all the people in the room. That was a context, trying to get allthe people with the knowledge into a space that they could talk about it. Youcan now feed Your LLM all of this context. Point it to a Confluence page forsomething you wanna build, or in your example, you've got a [00:07:00] brownfield app, point it at the code repo,point it at Terraform, point it at what you have about that application.

Ben Oster: And Ithink that the LLMs now have been the biggest sea change for this industry,because in probably about six to nine months you've gone from this is a m-multi-week, multi-month project to you can have a threat model for a complexapplication in hours, if not minutes for some of the more simple pieces.

Ben Oster: Andespecially when you're looking at applications that are broken intomicroservices, you're actually threat modeling all the different pieces of it.Yeah. So you're creating these multiple threat models. So I think LLM has, hasfundamentally shifted the way you can create these threat models, which I thinkis actually a really great thing, because I don't think we were threat modelingenough.

Ben Oster: I don'tthink we were threat modeling everything, and we had, as a cybersecurityprofessional, we had just these huge gaps in our view, in our risk view, in ourthreat view of, of our applications and our technology stacks, uh, [00:08:00] because it was too hard to do. Mm. And youcouldn't get everyone at the table, and you couldn't keep it current, so it washarder for people to care about the long-term plan.

Ashish Rajan: Wouldyou say then are people feeding these... Like, I think the challenge has alwaysbeen to what you said. You can point an AI system to like a existing brownfieldapplication or... Are we still doing point in time? 'Cause going back to whatwe- Mm ... kind of started the conversation with, is that still a point intime, or are you seeing people actually going, go beyond?

Ben Oster: Uh, so theLLMs themselves are point in time, right? All we've done, we've taken a staticmodeling process that didn't work for the long term, and we've made it faster.That's a great first step, right? Yeah. Now we can threat model everything, butthen if we never go and look at those models and we never update those models,we haven't improved our actual posture.

Ben Oster: Wehaven't- Yeah ... done anything meaningful with that threat model in theenterprise. And so for me, it feels like that's a great first step and, as aproduct manager, I'm trying to solve a couple of different problems, and thefirst one [00:09:00] is, can you even threatmodel, right? Mm. Is this something you can do?

Ben Oster: And theanswer to that now should be yes to everyone, because anyone who's using AI intheir engineering process or enabling their teams with AI should be using somelevel of AI, whether it's in, you know, my product selfishly, or just a, abroader LLM, to bring these things to your engineering teams as, as a startinginput to your AI engineers or your agents as a starting input.

Ben Oster: We, Ithink in, in, we talked about this a little bit, but the idea of We used to gowith context and architecture, and then the engineers would build it. Yeah.That's great because it- we're building it at a pace that allows us to find theissues and work through it and then threat model it, it. But the threat modeloften came towards the end after we knew what we already had, right?

Ben Oster: Yeah. Andnow I think one of the things that's so exciting about threat modeling today isthat we're expanding this beyond this rigidly compliant market. The financial, [00:10:00] healthcare, all those groups have beendoing this for a long time. Yeah. But if you're using a threat model as aninput right next to your architecture to...

Ben Oster: And you'refeeding that to your LLMs and to your AI engineers, you're gonna get a betteroutput. The better instruction you can give, the better your output will be,and that's a little bit about are you giving a good enough prompt. But if yougive those LLMs all of the context at once and you say, "Go do it all atonce," it gets confused.

Ben Oster: If you canbreak up what you're trying to give it and you can say, "Instead of tryingto figure out what's in this Terraform Here's the threat model for theTerraform, and now go edit it. Right? Now go edit my application. Or here's theconfluence, now build me a threat model, and then hand the threat model and theproblem statement to the AI instead of handing it the confluence page.

Ben Oster: And c- youcan get much better and faster outputs that way.

Ashish Rajan: Wouldyou say it would work in the context of I don't know, I'm gonna throw in someelements like your AWS, containers, Terraform. You're kind of talking fullgamut, which is probably a [00:11:00] lot ofthe brownfield already that people have u- are used to.

Ashish Rajan: Whatwould threat modeling look like in that context if you were being, quote,unquote, "AI native"?

Ben Oster: Yeah. Sofor me, it, it doesn't matter if you're greenfield or brownfield, right? Ifyou're greenfield, that's great because we can start with a more securesituation. But if you're brownfield, we can... You should still be looking atyour code, your context of what you tried to build, any architecture that youhave for what you tried to build, and then comparing that to your actualdeployments and understanding where the gap in what you wanted to do and whatyou should, what you wanted to do or what you sh- what you should have done isto where you are today.

Ben Oster: And so Ithink it's important that anything you're using to build threat models shouldbe able to take effectively context from anything you wanna give it. If youhave a Visio diagram, great. If you have a Confluence page, great. If you wantto scan a repo or, or a bucket or, or something in Cloudflare, like great.

Ben Oster: We need tobe able to look at what you have and build you a threat model. You know, as aproduct [00:12:00] manager, that's what I needto be able to do. Yeah. But I think that's where the more CISOs I talk to, themore I find that they're almost all desperate to threat model more things thanthey are. Yeah. And it's just a matter of the scale has always been a problem.

Ashish Rajan: But Iguess what question always comes down to is the CISOs and everyone, at leastmost of the security community that I know, going back to we all love threatmodeling. Mm-hmm. The byproduct of threat modeling is all the issues andtickets that come out after, which no- Yeah ... which then you're sitting inthis probability argument for what is the likelihood this would happen, orwhat's the probability this would happen, and it's goes on and on.

Ashish Rajan: Does itchange with AI? Like, does it kinda like... And I'm thinking of people who loveStride or any of the- Yeah ... existing threat modeling systems, right? To whatyou said, I think I love what you said about its design. It was, uh, the Strideand other, other similar threat modeling approaches were designed for thesprint approach.

Ashish Rajan:"Hey, we're doing a two-week sprint, and the beginning I know what I w-what I'm trying to achieve. At the end, I know what, what I'm trying toachieve." But [00:13:00] I have done athreat model, like it was like the goal level threat model rather than a sprintlevel threat model. So I'm curious as to how are you seeing this kind of changeas well there in terms of w- what, I mean, the people you're talking to or the customersyou're talking to?

Ben Oster: Yeah. So Ithink people care less about the methodology, honestly, Ashish. I think thatwe... Methodologies are there to help us get through kind of the process in arepeatable and meaningful way. Yeah. And I think I'm hearing fewer people careabout STRIDE or VAST or, or whatever framework you wanna use to do the threatmodel, and they care more about how can I get to 90% done as fast as I possiblycan so that I only have to look at that last little piece?

Ben Oster: And then Ithink all of this leads to how do you get engineering bought in? Mm. Because assecurity people, it's great. We've got this map, look at all the protections wehave in place, but, or look at all the requirements and the security you know,considerations we've built so that we know we're [00:14:00]secure, and then you hand 10,000 things to a developer.

Ben Oster: Like,they're not gonna do that. Yeah. Like, you have to, there has to be some kindof reasonable measure of, of where it is. We as security operators have tounderstand what risk looks like. I think that's also a big piece, and I thinkthis is where you're starting to see CISOs and CTOs come a little bit closer onthis sometimes.

Ashish Rajan: Okay.

Ben Oster: There usedto be kind of safety in volume, right? Yeah. There's so many vulnerabilitiesout in the wild, but it'd be too hard for anyone to actually go after this.It's not hard. It's not hard at all, right? Yeah, yeah. Now we can, now you canbuild an attack at the same pace you can build an application using AI, and ifthere's one thing I know about- cyber criminals, it's that they're well-funded,right?

Ben Oster: They'regoing to run, uh, you know, they're gonna run their own models even if theycan't run Anthropic, right? Mm-hmm. They're, they're gonna run it on hardwarein basement wherever they are, and they're going to be able to findvulnerabilities at [00:15:00] scale and attackvulnerabilities at scale. So that anonymization of, of risk has kind of fallenoff, and I think you're starting to see the CTO, CTOs and the CISOs cometogether on we need to bring developers more into the fold.

Ben Oster: And Ithink those CTOs love that idea. Yeah. But if we as security architects andsecurity operators keep giving them 10,000 things to do every single day,that's not gonna last, right? We have to pick and choose what we give them. Weneed to make sure that they're only the controls we really need. And I thinkit's on us to give people the tools to use repeatable controls in theirdevelopment as often as we can.

Ben Oster: So insteadof trying to build out an individual control for an individual application, Ithink we need to start thinking about this kind of like a UX team would thinkabout a design system, where everywhere we see a pie graph or a widget in theconsole, if I change that in the design system, it has to change downstream, [00:16:00] and it has to be minimally invasive to thedevelopment team.

Ashish Rajan: I, Ithink it's really interesting that, like as you said that, I'm like, mostpeople think of controls as individual application controls. They don't thinkof it- Yeah ... I'm gonna take a step back and look at the whole enterprise,for lack of a better word, and see where else this is.

Ben Oster: And forme, that's it, right? Like, I was in London a, a couple weeks ago talking to acustomer over there, and they had this moment of, "Oh, I can have onethreat model for my whole organization?" And I was like, "That's whatI want you to have." Like, you should be able to take every single thingyou're building and put it into one view, right?

Ben Oster: Yeah. Oneindividual view, and click through it and see where my reusable components foridentity and access management are impacted across the whole company. If Ichange this component, how many things are affected? And you've gotta be ableto see that kind of forest for the trees view. I was explaining this to mywife, and I joked that it's like Jurassic Park.

Ben Oster: Right? Youremember in 1996, they were trying to lock that room, and Lexi's in there. Yes.And she's got that map of the buildings, and she's [00:17:00]like, "Here's the building. Here's the room." Yeah. "Here's thelock." Yeah, yeah. Like, you need to be able to drill and maneuver throughyour organizational threats and risk- and see that whole view of yourorganization. And that, I think, is where even, you know, we haven't reallyeven gotten into the continuous piece of it, but that's where I think AI reallystarts to fail- Yeah ... on its own. Right? You can't give, OpenAI or Anthropicthe full view of your organization and expect it to not just hallucinate.

Ben Oster: Like,that's not how it's built, that's not how it's designed. Now, if those folkswanted to go and build that, I'm sure they could build anything they could everpossibly want to build. Yeah. But that's where the AI itself falls over, right?They-- We can give you a threat model, we can look at one thing, but thosecontext windows are narrow.

Ben Oster: And asCISOs and people responsible for broad organizations, we have to be able tolook at this more broadly.

Ashish Rajan: I lovethe analogy of especially the Jurassic Park one. I don't know how many peopleare old enough to even understand that anymore. Yeah. But they probably thinkof Jurassic [00:18:00] Park as the more recentone, which I don't think had the scene, or maybe it did.

Ben Oster: No, thisis, you know, 1996

Ashish Rajan:Jurassic Park. This is the OG. Yeah, this is the OG one. Yeah. Um- You

Ben Oster: didn't saythe magic word.

Ashish Rajan: Yeah.The, the, um, the thing I was gonna point out here is I definitely find thatthe idea of looking at a threat model for an organization could be hard forpeople to fathom. Also because and where I'm going with this is that people whoprobably are builders and have been doing some Claude Code or Codex or whateverwould look at this as a, "Hey, I can create this."

Ashish Rajan: And Ilove that you brought the continuous aspect in here as a, as a conversation.Kind of piggybacking on what we start, where we started the conversation, wherewe were talking about point in time is not good enough anymore. So what's thedifference? What's the leap for that I cannot do it myself or build myself?

Ashish Rajan: That ifI can build a threat model for a point in time, what's stopping me from makingit continuous? Is it the capability of the model or is it something else?

Ben Oster: So I thinkthere's... Honestly, I [00:19:00] think there'sjust the structure and cost. Okay. I don't know that there's anythingtechnically stopping you from doing it, but you'd have to build it.

Ben Oster: And I goback to I've had this conversation a couple times, obviously internally, right,at, at, at threat model where we're talking through what's the future of ourproduct. And I go back to good to great, right? Mm-hmm. And, and this kind ofthe, the idea of the hedgehog and a former mentor of mine, I don't think I'llever forget the hedgehog.

Ben Oster: I don't...We spent so much time on the hedgehog. But this idea of what can you be thebest in the world at- Yeah ... I think is just kind of central to thetraditional build versus buy conversation anywhere, right? If your business isbanking, are you gonna ever be the best in the world at building and managingthreat modeling across your organization?

Ben Oster: Are youever gonna be the best in the world at building, EVs, right? You're not. That'snot the part of your hedgehog that's gonna make your business successful. Andso I come back to that a little bit and the cost to build and maintainsomething that ongoing in any organization is going to be very high, even [00:20:00] though we can vibe code it and do it now.

Ben Oster: So yeah,you could build a threat model and you could build a, you know, a web hook on,you know, an internal application that any time a repo or a Confluence pagechanges, we remodel. But now you're managing versioning and you're managing theweb hooks and you're making sure your repos are connected. And there's so muchdownstream work that if you believe continuous is the answer, which I think weshould get there, right, as you set out your map and you needed to take adetour, you need to mark that you took a detour or your map is wrong the nexttime too.

Ben Oster: Yeah. Andso I think where the continuous nature of threat modeling, I think, is reallyresonating with practitioners. Yeah. And I know that it's resonated with you,and we've talked about that before, but you've gotta be able to build all ofthe work downstream to do that. And- We as security operators have always hadissues keeping up with how much threat modeling we need to do, and now you'veadded the maintenance of the system in place, and I don't think it'ssustainable for most organizations.

Ben Oster: So couldyou do it? [00:21:00] Yes. Should you do it? Iwould argue no, because... And selfishly, right? I'm selling you something.Yeah. But selfishly, I would argue no, because I think we can do that for lessin a better way, because our goal is to be the best in the world at this. Andso if we can do that meaningfully for you, there's no reason for you to have tobuild it yourself.

Ben Oster: If, now,if I come in and say, "Hey, it's... Ashish, it's $14 million to dothis," like, come on. Nobody, n- no one's gonna do it, right? There has tobe a cost benefit to the customer here, but-

Ashish Rajan: Yeah.

Ben Oster: But yeah,I think that there's... It's just not worth it for most people, and I thinkthere's a lot of things that get lost when you try and do that yourself.

Ashish Rajan: ButI'll probably double down on something here as well then, 'cause a lot ofpeople would say, "But Ben, I've got MCPs. All my security productcompanies have basically told me that we have an MCP. Use that MCP, solve yourproblem." And so does that change the situation if I have AI-builtintegrations across my entire ecosystem?[00:22:00]

Ashish Rajan: 'Causeto, to your point, I've always... as I've said this, I've also made anassumption that everything that we have in an enterprise is API-enabled too inthe first place. Right. Let's just... I'm not even talking about MCP. Let'sjust talk about API-enabled in the first place.

Ashish Rajan: Andlike, once we cross the chasm of how many are API-enabled and how many wouldhave MCPs and stuff, keeping that aside, if I were to just look at the oneswhich are API-enabled and perhaps can have an MCP, does that change the picturefor continuous DI, like do it myself a situation? Or-

Ben Oster: I thinkit's how people are doing it when they talk about doing it themselves.

Ashish Rajan: Okay.

Ben Oster: Um, and Iknow I'll probably get roasted for saying there's no difference between API andMCP- ... because there's obviously a technical difference. Yeah. But there'snot. The goal is we're connecting two systems in a meaningful way, right? Yeah.That's what we... That's the problem we're solving with both of those tools.

Ben Oster: That'sright. But I think that it doesn't matter if it's API or MCP. You absolutelycould build that. You can build the connection to GitHub Enterprise or GitLaband say, "Hey, if this repo changes, great." But there's... That'ssuch an oversimplification of the [00:23:00]broader problem these organizations face, right?

Ben Oster: You havean application that might have 10, 15, 20 repos in it Right? You might have,uh, an application that's running 10 or 15 different microservices. You mighthave multiple applications that are sharing microservices. How are you makingsure that even in a continuous way, you're now building individual continuouswork for every single one of these applications, and you're maintaining thatindividual continuous work for every one of these applications?

Ben Oster: Becauseyour first application that's calling 15 different microservices, if one ofthose microservices changes- ... that application has had to monitor and updatefrom that microservice. Yeah. And then every other application, which could bein the thousands, right? We see literally thousands of, of applications inthese organizations, would have to change themselves.

Ben Oster: Whereas ifyou can have a microservice that shifts and you can see where that looks likeand you can push that work down, not only can you do it in a more deterministicway, which I think is a big difference, is a [00:24:00]big key here, you can look at the overall view, not only with the LLM, becauseI know we all have experienced it tells you one thing on Monday and a differentthing on Wednesday to the same- Yeah

Ben Oster: exactquestion. But it gives you that kind of, one, you can see everything, you cansee how everything interrelates instead of thinking about your applications asislands of themselves, so you have a better and more holistic view of, of whatyour organization looks like. But you're also able to do that monitoring andthose updates in a more non-deterministic way.

Ben Oster: So if youhave a change that comes in in a microservice, instead of just kicking offevery single LLM that's monitoring that service and giving each one of yourapplications a slightly different answer, you can give everyone the exact sameanswer. You can make it reusable. It makes it easier for your developers topull down the components they need, pull down the requirements they need, useyour custom controls across the entire organization instead of hope the AI'sgetting it right.

Ashish Rajan: I guessto what you said about the continuous part, this kind of [00:25:00] doubles down here as well a bit, becauseas you said that about the microservices changing at one place, and you, thatripple effects are felt everywhere. And to going back to where we started, thisis probably one of the reason why threat modeling has always been a point intime thing, 'cause there is this ask of how big or how significant is thechange- We'd never really have a great estimate of it.

Ashish Rajan: It'sbasically a finger in the air in most cases. It's like, oh yeah, I guess it'sprobably... Is it really a design change? Well, it's a design change if Ichange my Oracle database to a SQL Server database. Right. It's not a designchange if it's still a database. Right. Uh, we, we start finding reasons forwhy it doesn't require another threat model.

Ashish Rajan: But Iguess to what you said- But where is that

Ben Oster: database?How is it hosted? How are you accessing it, right? How are you authenticatingagainst it?

Ashish Rajan:Literally.

Ben Oster: Where areyour secrets being stored? Yeah. Yeah. Yeah.

Ashish Rajan: And I,and I think to extend that example a bit more, I realize that the whole idea ofhaving one threat model that looks across the organization, is this kind ofchanging the [00:26:00] way people look atsecurity programs?

Ashish Rajan: Becausetraditionally the reason, and the reason I use that example specifically isbecause having done a security architect job back, back in the day, I realizemy day to day, I would get involved in a threat model exercise perhaps in thebeginning of a building of an application, but by the time the application isbuilt and ready to go into production, I'm working on another application.

Ashish Rajan: Andsomeone, like say Ben comes along and looks at, "Oh, Ashish has looked atit. You just turn your chair around, talk to me for a bit, and go, 'Was thereanything obvious in here that you saw that I should have kept, paid attentionto?' 'Nah, nothing obvious.' Right? 'Oh, sweet.' Like, let's do a pen test andcall it a day."

Ashish Rajan: Andlike, it basically was- Yeah ... like, and I, I imagine a lot of people wouldrelate to this scenario 'cause it is very true for s- so many organizationseven today, because a lot of times the threat model is, that's one of thereasons why it's point in time. But bringing it back to the continuous part andbringing it back to- that I have moved on from that first threat model toanother threat model.

Ashish Rajan: Are youseeing that the [00:27:00] role of people whohave traditionally done threat modeling in organizations evolve into, like,what would that look like in a continuous threat modeling world? I guess that'ssome point. Take today, my team is designed in a way that Ashish has done thatone point in time threat model.

Ashish Rajan: He'smoved on to another project, and then another one, and another one, 'cause wehave tickets ongoing, applications are being built ongoingly, and that's why wealways had a point in time. Let me know if there's a big sig- significantchange, otherwise don't bother me, right? Yeah. That's what the approach was.

Ashish Rajan: But ifyou're saying it's continuous, who's looking at this and how is that changingcompany roles?

Ben Oster: Yeah. So Ithink it depends on what you want to set up inside of your own organization,right? Right. If you want every single change, no matter how big or small, tobe reviewed, you could do that. I don't think anybody wants to do that- no

Ben Oster: let's behonest, right? Yeah. So what we need to do, and this is where I think AI isvery helpful, is it can tell you if this is a meaningful change or not. Mm.Like, it doesn't have to give you the exact map and the exact [00:28:00] control. It just needs to say, "Hey,have I reasoned through this with the context that's been given to me?

Ben Oster: And can Itell you, is this a meaningful shift? Is this something that needs to change?And if so, what do I need to do about it?" And it can makerecommendations, but you need that human in the loop to validate it. But Ithink this is basically I don't think of AI as this thing that's gonna replaceeverybody's job, but I worry about the entry-level jobs.

Ben Oster: Becausethese are the things that you would give to somebody that's very junior, that'snot, you know, hasn't spent a bunch of time, where they're gonna look at it andsay, "Oh, here's a change. Oh, this is the impact. Okay, let me tellAshish about this." And now Claude is gonna send you an email that says,"Hey, you need to take a look at this.

Ben Oster: This is ameaningful change." And so I worry about those kind of entry-level roles,but that's exactly where AI in, in our product and in any threat modelingprocess really can shine. It's good at context and reasoning in these windows.So if you're saying, "Hey, there was a change to this repo," great. [00:29:00] What's this PR look like?

Ben Oster: Mm. Is...Let me reason through if there's a meaningful change, and if there is, let metell a security architect about it, and we'll say, "Here's ourrecommendation for that change," and they can just say yes or no, or editit and push it back. And you end up in this kind of infinity grid betweenengineering and, and architects, where we can constantly be pushing informationto each other- Yeah

Ben Oster: in aseamless way into the workflows we already have.

Ashish Rajan: But Iguess to your point then, CISOs probably should also, when they build asecurity program, should consider the fact that moving forward there would be alot more continuous threat model rather than a point in time. 'Cause anormal... the way I would have designed a program back in, like, I'll saypre-AI, but let's just say six years, three, four years ago- Yeah

Ashish Rajan: wouldhave been d- a lot more about the fact that, oh, I have, I don't know, foursecurity architects or 10 security architects ag- across 10 application.However the thing may be, the threat modeling piece was always a assumedcomponent in there, and now we're basically saying, well, it just can't be apoint in [00:30:00] time.

Ashish Rajan: It hasto be continuous. And but in saying that, AI can help people get to a pointwhere every time there's a pull request into a GitHub repository, whether it'scloud or MCP or whatever the change may be, they would still be able to atleast reason with it to understand how significant the design change is.

Ashish Rajan: Wouldthat be fair statement?

Ben Oster: Yeah, Ithink so. I think that you're... The way I use AI is as kind of that chief ofstaff, that junior assistant that can go through and give me like, "Hey,here's what changed. Give me that update." Yeah. And I think thecontinuous nature of that is really important in a modern world because youneed to understand the development is moving so fast.

Ben Oster: It used tobe we'd build a threat model and it would go stale. And yeah, it would go stalethe minute you left the room, but really the pace at engin- of engineering, itwould go stale in six months, eight months. It would go stale once we made ourfirst deviation from the map. Yeah. And now, if you're using Cursor withdifferent models on the back end, that thing can be stale by the time you'veplugged it into Cursor.

Ben Oster: Yeah. [00:31:00] And,

Ashish Rajan: Yeah...

Ben Oster: and so Ithink that the continuous nature of it is, I believe, a requirement so you canactually build a security posture and then architect your organization againstthat security posture. I think that you need to be able to see where you'vedrifted away. You need to be able to see where you can improve, where your gapsare, and you're never gonna get that if the map you have is an atlas from 1996-

Ben Oster: and you'retrying to drive through downtown, you know, Chicago. It's different than it wasin 1996.

Ashish Rajan: Yeah.So- would you say, uh, well, another thing you called out, which I'll doubledown on for one hot second as well, the pull request piece as well. A lot oftimes threat modeling is never part of that thread, that pull request.

Ashish Rajan: Mm-hmm.Threat modeling is a, I'm about to build an application, or I'm making asignificant change in the application. Those are the only two scenarios whenthreat model comes in So the, you're almost asking people to go revisit thesoftware development life cycle to also go... Pull request is also a point intime where you need to assess, [00:32:00] isthis a significant change?

Ashish Rajan: Is,does, should we be threat modeling? Because I can't rely on a developer to havethe understanding of security to be, even make that call.

Ben Oster: Yeah,exactly that. I mean, we've... I was in a room with a customer and they said,you know, "How do I trust that the AI's getting it right?" And Ikinda said, "What controls do you have in place to trust your humans aregetting it right?"

Ben Oster: And helooked back across the table kind of sheepishly and said, "Well, you'reright. We're trusting the humans." And I think that's where we shouldstill put our trust. Yeah. But there isn't, most places that, and most peoplethat I've talked to don't have a clear, "This is how I know whether or notthe work I'm doing fundamentally shifts something for the security team."

Ben Oster: Mm.Because, and maybe this is a people hedgehog instead of a business hedgehog,right? Yeah. But that is not what you hired that developer to do. That's right.A developer is not in your organization to be a security expert. They shouldn'tbe the ones making the decision about, is this change I'm making to theapplication, does it meaningfully impact security across this application oracross other [00:33:00] applications?

Ben Oster: Becauseyou also have a small change that cascades across a microservice to 3,000different locations is not a small change, even if it feels like a small changeon that PR. And so for me, y- you've really got to get something in that loopthat's checking every single one of them and telling you if there's ameaningful change or something to review.

Ben Oster: Becauseyou can't, I don't believe you can rely on somebody whose job it isn't to dothat.

Ashish Rajan: No,well said, man. Uh, that's all the technical questions I had for you guys, man.I think I'm, I'm just curious in terms of where can people hear more about thethreat modeling pieces, 'cause it's a big change of even thinking about threatmodeling differently, especially people who love Stride and just, I lo- lovefilling a whiteboard with it.

Ashish Rajan: Uh,it's like I wonder- Yeah ... if they wanted to connect with you and, uh,probably have more information about what you guys do at Threat Modeler, wherecan they find more relevant information, where can they connect with you totalk more?

Ben Oster: Yeah. SoI'm, I'm Ben Oster on LinkedIn, you can find me there, but [00:34:00] threatmodeler.ai is our company's website.

Ben Oster: There's aton of information available there, on-demand resources on-demand webinars.We've got a another big, uh, product launch that we're doing in the next kindof week or so. Nice. And so there'll be a bunch of, of material coming therethrough the threatmodeler.ai site and the Threat Modeler LinkedIn social.

Ben Oster: So checkthose out. We'll keep- This coming both from a, we want you to think about howwe're doing it from a product perspective, but also as an organization that'sbeen threat modeling and been a, a leader in the space for, 15 years, it'simportant for us to kind of keep out in front of that from a leadership, athought leadership perspective as well.

Ben Oster: So tons ofgreat stuff at, at the Threat Modeler LinkedIn.

Ashish Rajan: I'llput the link, uh, li- your LinkedIn link as well as a link to thethreatmodeler.ai website as well. Thanks so much for coming on the show, Ben. Ireally appreciate it.

Ben Oster: Awesome.Thanks Ashish. Have a great day.

Ashish Rajan: Thankseveryone. Talk to you soon.

Ashish Rajan: Thankyou for listening or watching this episode of Cloud Security Podcast. This wasbrought to you by techriot.io. If you are enjoying episodes on cloud security,you can find more [00:35:00] episodes likethese on cloudsecuritypodcast.tv, our website, or on social media platformslike YouTube, LinkedIn and Apple Spotify.

Ashish Rajan: In caseyou are interested in learning about AI security as well, do check out oursister podcast called AI Security Podcast, which is available on YouTube,LinkedIn, Spotify, Apple as well, where we talk to other CISOs andpractitioners about what's the latest in the world of AI security. Finally, ifyou are after a newsletter that just gives you top news and insight from allthe experts we talk to at Cloud Security Podcast, you can check that out oncloudsecuritynewsletter.com.

Ashish Rajan: I'llsee you next episode.

Peace.

‍