Layering defenses: A new hope?

for 55 minutes and then putting up a Q&A slide. This is me talking for a bit. We've got some menty meter. We've got some other things to get your in involvement and then lots of time for conversation at the end and that's by design. So I mentioned that I'm Adam Showstack. I run a company Showstack and Associates. We help people threat model. Many people today have come up to tell me what a great idea it was to hire Kimberly Price um who's here with us. Many of you know her. She's awesome. And she is part of how we are growing Showstack and Associates to help enable your threat modeling. A little bit about me. I'm an

affiliate professor at the University of Washington. I'm on the review board at Black Hat. Early in my career, I helped create the CVA and I have done a what is um I'll just say a lot of work in the area of threat modeling and I'll talk about that. That has included a couple of books. It included the elevation of privilege game to help people threat model the Microsoft SDL threat modeling tool. Um and I was an adviser to risk a company helping advance the field. And so what I really want to talk about today is the defenses that we apply as a result of threat modeling. And it turns out, and I'll talk about why I believe

this, but it turns out that most defenders have a very narrow toolkit. Um, the way they threat model tends to cluster in really predictable ways once you start to watch for it. It clusters based on their experience, what they've done in life, the sorts of technologies they've worked on. It clusters based on the position it based on a company's position in the supply chain. Right? So, if you were here for Mike and Leah a few minutes ago, the sorts of defenses that they can apply are different than the defenses that you can apply if you work at, say, a company developing mobile apps because you have less control over your platforms. Um, defenses also cluster based on the

age of the system. Bob had a question um about um history rhyming. And so I want to be thinking about defenses. I want to be thinking about the toolboxes we use as we defend. And and one of the things that I found is how we talk about that is just way less clear than I thought when I started this journey. And so what I want to do today is I want to give you a very brief introduction to threat modeling. I want to talk about the origin of this talk. I want to analyze that. I want to give you a set of working approaches to defenses that I'm not going to say this politically correctly. I'm not happy with. I think

we can do better and I hope that we collectively can do better and that's really why I'm here. Um, and I'll give you give you some possibilities. Let me start out with an overview of threat modeling because um, as Emily Troy Green said in her talk this morning, this can be a little bit of a religious war. I don't want this to be a religious war. I want this to be a big tent. And so when I think about threat modeling, I think about using models to help us think about security. I think of threat modeling is the measure twice, cut once of security. And if you work in like a wood shop, you know that you

measure twice and cut once because otherwise you end up with a pile of scrap wood in the corner that doesn't contribute to the project you're working on. And in technology that that pile of wood is um code that has to be thrown away or rebuilt. It's and and the result of that work is um projects slip. People get angry. There are escalations. People hate the security team because they say we're causing that slip. Well, if you measure twice, cut once, maybe we're not going to have that same degree of slippage. And so, I think of this as a toolkit that we can work with. And I think it applies to the technology you produce. It applies to the technology

you operate in equal measure. And so, how do we threat model? Um, while I was working on my first threat modeling book, I created this four question framework. And the four questions are what are we working on? What can go wrong? What are we going to do about it? And did we do a good job? And if you're if you think of threat modeling as something like data flow diagrams and stride, those are ways of answering these questions, right? Data flow diagrams are a way of expressing what are we working on. Stride is a way of thinking through what can go wrong. And this talk is thinking through what are we going to do about it. And so the the

four questions really help us really help people think about how threat modeling works. It helps us refine how threat modeling works. And in about 2018, a group of 15 industry experts came together. We wrote a manifesto for threat modeling talking about the patterns that we saw working across a really wide variety of technology companies, non-technology companies consultancies financial institutions. The framework because of its flexibility enables us to have really valuable conversations about how to threat model. Well, we've got a we at Chos and Associates, we've got a free white paper. There's not even a reg um about the four question framework because we think it's useful and we want people to use it. One other thing I want to say about

threat modeling is one of the things that threat modeling gives us is an opportunity to think about where the boundaries are between our system and other people's systems between um different parts of our systems. And so threat modeling helps us discover where boundaries should be, how we can make boundaries better. And that is missed often as I talk to people about threat modeling. And so I like to just bring it up. So this talk here today, um, you know, I learn I learn so much from my students. Every time I do a training, I get interesting questions that give me insight into how people are thinking about the stuff they're supposed to be learning. And it's it's a little bit

cliche to say, I learn so much from my students. But the reason that it's a little bit cliche is because it's something that teachers learn to do is you learn to understand where your students are so you can help them get where they want to be. And to help us do that when we teach, we use we tend to use a little bike system. It's a grab a bike system with some IoT and some payments and some other stuff. And we use that in part because it means that we're not sitting there threat modeling a system that someone in the room has built. This is really useful because if you're doing training, you threat model something someone in the

room has built. Someone ends up looking like this because they realize that decisions they made a few years back were not um they could have made better decisions. And so instead of learning about threat modeling, they're regretting life choices. Okay. So maybe that's an interesting thing, but it's not what we're there to teach. It's not what we're there to evoke. We're there to help them do better next time. So we use this bike system and in a training we did in December, these are people's answers to what are we going to do about it? And you've got these little yellow boxes so you don't have to read the handwriting that people wrote on whiteboards as we

were doing things. But over over in red, the mitigations and controls that these folks listed were seam and soore and edr and bass. And I just want to appreciate for a moment that they took the time to write out endpoint detection and response. Um, wow. The the video doesn't appreciate it, but I sure do. Adam's just an >> it it is. Um >> we're back. Great. Um so over here we've got these very We got one set of things and then over on the other side in the purple we've got people with special screws on the bike. We've got locked firmware. We've got remove Bluetooth. And I'll tell you, when I look at these, they look very different.

And so I asked my students to compare and contrast the lists. It was hard. Um, it was really interesting to watch them struggle to put into words what was different about the two lists. Okay, I learned so much from my students. I really do. Some people even rejected the idea that they were different at all. It was it was fascinating to watch. I went I talked to them about it and I realized that we don't necessarily have a great way to discuss the question what are we going to do about it when we get to the level of what is the defensive strategy I want you know we talk we talk for example with stride spoofing as a

violation of the authentication principle tampering is a violation of the integrity principle but going beyond those principles to what do I do to actually implement integrity in my system people struggle and so where I really come down is that people have this limited toolkit it's the toolkits they have are obscured by the language that we use the way people talk about these things make it easy to miss um the the differences in how we're approaching it. And and I do want to mention here that one of the things that I think is really important about effective threat modeling I is that everyone has something to contribute. Um, I will we will often go into a company

and we're trying to help them change their processes and how they engage with threat modeling and executives will ask me questions like, "Why am I here? This is a technical question." And and I I'll look at them and I say, "So, you're not worried about anything in this system going wrong?" And they're like, "Oh, no, no, wait, wait, wait. I am. I'm worried about this. I'm worried about this." I'm like, "Great. The technical people in the room are concerned that security isn't connected to business and you're giving me a list of problems. They're here to listen. Can we please actually value different perspectives? Um, and so I really believe and I really watch different perspectives bring so

much value to the threat modeling we do. And it's important, and this is just a side tip for all of you. Anytime somebody says, "I think X is important," and you say, "That's not what they're here for," you have just lost them forever. Um, when someone says, "I think this is important," you write it down, you track it. You might say, "We're not sure what we would do about that, but list it. Show them that you care and they will keep contributing. And so how do we think about these? I've been using the word toolkit, but that has its own issues. And when we get into what are we going to do, there's a lot of terminology.

There's words like remediation and mitigation and control and risk management. And and I asked chat GPT to give me a concise list. Um I I don't know why the AI couldn't do it. But but it really did give me a list that's actually longer than that. When I think about great threat modeling, when I think about highly effective threat models, we use tools of abstraction to help shape our thinking to help us be systematic in our approach to the questions of what are we working on, what can go wrong, what are we going to do about it. And so this layers idea is a model of defenses in the same sort of way that data flow diagrams are a model

of the systems we work on in the same sort of way that stride is a model of what can go wrong. But when I go back here, we don't have a model. We have a lot of we have a lot of very tact. It's not that's not what I want to say. It's not that we have a lot of very tactical definitions, although we do. It's that we have a lot of very different conceptualizations. And because we have different conceptualizations, people will come up with answers like, "What are we going to do about this spoofing threat? We're going to add MFA." Okay, good. I have no I have no objection to that answer. But I want their answer to be more on

the order of we're going to put in better authentication because when they get to better authentication, we can then go back into that as a group and say what are the different types of authentication we might use here that are going to give us the properties we want including usability, security, speed, cost, all of the properties which matter. Um, and so again, we're working through this. I would like your help. And I really believe that none of us are as smart as all of us. That together, united, we secure, the theme of the conference speaks to me because I'm I've been trying to figure this out for a bit. And this is also important to

me because I think defenses are better than risk management. Um when we have effective ways to prevent, detect or respond to something, we see the words risk management invoked less. When we have effective technology, we see people in process invoked less. And I like technology for a couple of reasons. The first reason I like technology is technology scales. Technology when it's reliable is way more reliable than a process where some human is going to do something and then attests that it's been done. And so I like to have these technology answers because they give us more secure systems. The other reason I like technology is it's often easier to budget. When we get to the question of

how are we going to scale this, the answer is usually in technology of various forms. Um, so I I've been I I've been pleased. A couple of people have come up and said they really liked my keynote here last year. If you didn't see that, there's a more recent version of a similar talk that I gave as a keynote at um OAS Global AppSc in DC. You've got you've got the uh the link there. By the way, these slides will be available um by Monday. You're of course welcome to take pictures, but they'll also be there so you can click on links. So, I think defenses are better than risk management. And when I think about

these layers of defenses, I think it might be worth getting uh what's the word? Getting specific about what they might be. And so if for example what we're working on is a battle station that will keep the systems in line, um then we might think that what can go wrong is a set of X-wing fighters. And if we think that um then the answer to what are we going to do about it might start with architectural improvements. Um we might put some blowout panels into the um into the battle station. And um it turns out that you have to actually realize that the battle station might blow up. Someone might shoot a torpedo into it.

Um, it's really hard to retrofit. Um, and even if you do retrofit, there's probably going to be high casualty levels as chunks of your battle station blow out into space. So, this isn't a great idea, and we want to think about other types of defenses that we might put in place. So, we might have laser cannons along the trenches. This would be good. um they weren't approved. The Empire didn't see small one-man fighters as a threat. Um and the other thing is we we've been talking a lot today. Everyone's been talking a lot about AI. These uh these images are courtesy of uh Gemini. Thank you very much. Um and also the the plans called for more ventilation shafts.

Um, I I think there's a misunderstanding of what the threat here is or the AI is really working for for the good guys. We might also add a steel wall. And this was this was sort of fun because when I asked Gemini to put a steel wall in front of the thermal exhaust port, it had a lot of trouble with that idea. um at first put a short wall that isn't actually in the way of the thermal exhaust port, so has absolutely no defensive value. I asked it again and it um put another short wall in and and I asked it a third time and finally I put a wall in place that actually protects the thermal exhaust

port while completely shutting down its value as a thermal exhaust port. Um, and so when you ask me if we're ready to have AI do all of our threat modeling, folks Gemini.

And so the key point here is that there are many ways to actually improve the defenses around your thermal exhaust ports. And if we have the language, the models, the the ability to have a good conversation about these things, then we will have better outcomes from our threat modeling. And so when I think about this, I really think one of the one of the huge shifts um over the last 20 years in how we threat model is we have moved from adversarial thinking to structures that help us engage in structured and systematic analysis. And this is so important. This is um I talked to Emily a little bit in the hallway and she was saying I hope you don't you're you're

not upset by the religious debate thing that that she had said in her talk. No, I'm not upset at all. The only place that I get upset at threat modeling is when I hear people who want threat modeling to be this special thing that only a certain special subset of people can do because they have a security mindset. And the reason I get frustrated with that is security mindset is not a thing we can teach. It's not a thing we can scale. It's not a thing we can infuse through engineering and operations organizations. And if we want to go back to the first thing I said about measure twice, cut once, the people doing the engineering work have to be

able to do the engineering work, including measuring twice and cutting once. And so I I'm really at the point of what defensive model should we have to help them think about what the design space is, think about what tradeoffs are, and think about how do we help people learn to do this so that when I go into an engineering meeting and say, "How are you thinking about defenses?" I get consistent types of answers where people are having useful conversations rather than talking past each other or worse yelling past each other. So there's three models that I want to share with you. These are a toolkit, they are um layers and they are um engineering stages. Sorry, I'm just

looking at my timing and I'm confused by what PowerPoint is telling me. I think I'm about halfway through. Okay, thank you. And so I have two mechanisms for polling because none of us is as smart of all of us. I'm going to de dig into each of these. I have two polling mechanisms. The first is a here in the room polling mechanism. If you like something, I want you to hum. I like humming because it doesn't require anyone to commit by raising their hand. Um, I've been that person. I assume many of you have been that person who I'm not sure what I want to say. And if we're just humming, then you can express yourself without

being feeling like you're sticking out. A friend of mine who's a professor of computer science suggested this and I want to give it a try. Second method is a little bit more traditional. We've got a menty meter survey. And I'm going to ask you as I as I talk about what's in this menty meter to grab your phone to open this QR code which goes to menty.com. Um, and we're going to ask essentially five questions. Not essentially, we're going to ask actually five questions. Um, those are which do you like best? It's a multiple choice question. You pick one. We're going to ask about toolkit versus layers versus stages. We're going to ask is there another

frame you think we should be thinking about? And is there related work that you think we should be aware of? Um, please take a picture of the menty now. If you haven't, I'll give you another minute because it's not on every slide because I made it big so that you can get it to it from the back of the room. Um, so we'll give you a minute to do that.

All right. So each of these defenses is similar. They each of them gives us a way to think about things like design and architecture, defensive coding practices, protective products like firewalls and IDS's and e um rasp or wfts and some of them are sort of product integration. They're things like uh seam or identity and access management. And so we can call the as we change what we call them, we might actually get different layers, right? Or not different layers, we might get different um groupings. That's the word I want. We might get get different groupings. Those different groupings may be positive or negative. If you're looking at one of these models and you say, "Wow, that really takes everything I do

and sticks it into a single bucket, and I think it should have more buckets." Please tell me that's use that's really useful information. So option one is a toolkit. If you like like the toolkit idea, please hum. We'll see if there's any humming. All right. All right. Um, so in my mind, some of the pros are it's an easy metaphor. The visuals are easy. You know, you can have Gemini draw you a little toolkit. It's easy to extend. We add things to our toolkits all the time and we get to put duct tape into our metaphor and that's always fun. The cons are it's not particularly tied to tech, right? It's just a metaphor. It

doesn't give us anything else. Um, it's unstructured and there are people who think that duct tape is the solution to all their engineering problems, whatever they may be. Um, and if you're one of the mythbusters, then that's accurate. And if not, then it's probably not accurate. So, I think duct duct tape is both a pro and a con. The second option is thinking about layering. Hum if you like layers. Oo. Oo. All right. I like this mechanism. It's sort of fun. Um, so some of the pros of of thinking about met some of the pros of thinking about layers, there we go. are um that it's simple. It gives us a um some structure to think about it. There's one

layer then the next layer then the next and attacks might go through them. We might build defenses in depth. We get to use cake visuals. Who doesn't like cake? Um some of the cons people jump to the defense in depth part of this and that worries me a little bit. um it leads to sort of an operations product split in ways that I'm not sure I love. Um and it's not very deep. So the third metaphor is a defensive strategy. And here I've got a little visual and let me explain it before I ask you to hum. Um so the um the dark blue are the stages of a waterfall sort of development process. They are surround

so design development shipping um or launching and if you ship it goes to customers who layer on their own sets of defenses. Each of these stages is surrounded by a lighter color field in light blue of isolation, defensive code, which are the defenses that surround it. Um, and so let me ask you to hum if you like this one. All right, I'm going to say that that's a number two is the is the winner for right now. Uh, but that's okay. We learned something. So um I think I have another slide on the pros and cons here. I have another slide on the pros and cons. So the pro is that it ties to a traditional um

traditional product life cycle. The cons are that traditional product life cycle is very waterfall. And those of you who live in an agile world are saying, "Dude, that's so waterfall 2001. I can't believe you even put it on a slide." um it's more complicated. The different life cycles across different organizations mean mean something important and the language is different. And so to summarize, models are a tool of great threat modeling. We leverage all sorts of models to do our work. And the best threat modelers have a good set of models that they bring to bear to help themselves be consistent, to help teach the people around them by giving them cubby holes, mental cubby holes,

concepts so that they form the right concepts and they use the right concepts to deliver more secure, more private products and systems. The words we use are really important. Um again none of us are as smart as all of us. United we secure. I am here because I am working how to express all of this. In addition to today I am hoping that today we're going to have a great conversation and I'm hoping that this will actually stick in your memory a little bit. We're and um I was thinking about using uh a Google form and putting a Google form here and Kimberly said that's really putting us at the center of all of the

information flow. Why don't we use something else so that people can actually talk to each other and we can listen? And so we're going to use LinkedIn for this. Um, we'll post some stuff to LinkedIn and when I get the blog post about this talk up after the conference, I will have an exact link to that in the hopes of giving you a chance. If you if as I hope you find yourself thinking about this, you have more to say that gives everyone a place to have that conversation. And so with that, I want to say thank you very much for your attention. I appreciate it. And

I am happy to take questions. Yeah. Can >> you Can you f that? >> I actually prizes for people. So >> yes, and we have prizes. First question right over here. Except >> I'm also going to tell you some of the things that are in the men's meter. Uh, we have a question that I'm going to grab here while I walk over, which is, uh, how are these contrasted or why couldn't we use the miter defend matrix? >> Why couldn't we use the miter defend matrix? The MITER defend matrix is great and the MITER defend matrix is very focused on I'm going to exaggerate a little bit for effect but it's for Microsoft's customers who are deploying Microsoft's

product with glue between them rather than people who build technology. Um and that's an important subset that that's an important large subset of the world. There's a lot of very important companies who live in that space. But I don't think it's complete, right? I think there are choices that you can't make if you are not building the tech which are not reflected in defend. >> Um so I hummed for toolkit because there's I feel that there's elegance in simplicity and toolkit opens itself up to metaphor. So my question is really around this paradigm shift that we all find ourselves in directly or indirectly where no longer are the magicians and the sorcerers and the engineers the ones

creating. We now have the sorcerers apprentice Mickey Mouse all of the nontechnical people >> in the business who AI has empowered to create the autonomous mops and brooms that could go sideways. How do you think about the simp the simplification of the concepts to be able to speak to those parts of the business who know nothing about SPLC but who absolutely need to participate? >> Uh you you ask how do I think about that? Could I rephrase your question slightly? >> Have you thought about that? No, I haven't. >> Uh so thank you. I'd love to brainstorm with you. >> Yeah. No, it's a great question. I love it. And I think this is really an

element of who our customers are, right? Our customers are not the one our customers are the traditional software engineering, operation engineering sorts of organizations, not the folks who are using AI. So yeah, thank you for the question and I wish and yeah, let's talk. All right. So, I'm gonna get my steps in. I'm gonna come back to Bob and I'm back of the room on purpose. Also, this buys me time to say that's not true. We have AI throughout our classes. >> It's true. Yeah, I'm good. >> Thank you. Bob Bob says Kim is a great hireer and I agree. So kind of looking at this especially I was wondering if you consider that the

toolkit is actually a part of the layer system itself since we contribute like for example with enterprise services you have a defense me so you have the pretty much the Microsoft providing their Azure and stuff like that then you have blue and so on so on they're each individual toolkit they get built into each individual layer to kind of create Swiss cheese layer wouldn't it be more integrative as part of a layer system then or Um, quite possibly. Yes. And and also you you mentioned Swiss cheese which calls in like James Rez Swiss cheese model of safety. Um, which also because I had been doing this with a small group had not been thinking about and so once again none of

us is as smart as all of us. So thank you. Love it. >> Okay. Okay, so I should actually explain to people I am handing out four question frame four question modeling framework cards and I have a ton of these. Everyone can have one. I have a limited number of magic security dust that you can sprinkle on all your security problems. >> Kim, if you would like to wave around some magic security dust before Bob asks a question. I just want to explain that that we created this because people would come to us and say this threat modeling thing is hard. Do you have something simpler? And being customer centric, we felt we should be able to give them magic

security dust. >> So have I don't have a question. I have a challenge. Uh >> oh. >> Many of us in this room either cut our teeth on working on technology or work in technology today. I've spent the last seven years in life sciences, agriculture, pharmacological research, consumer health, etc. We've got AI being used up the yin-yang. We've got technology we're building. Gee, why are we building software for researching drugs? Because you can model things in software that help you do your clinical trials. >> And when you get to stage three, that's kind of exciting because you can talk about it publicly. If you don't, the FDA and other federal agencies worldwide get grumpy. The challenge is take layering

defenses, take threat modeling and apply it outside of tech. So what so two two thank you um applying threat modeling outside of tech is actually something we do with a fair number of our customers and and the thing I want to say here is you're arguing for a simple model that people whose skills are not in technology will get you quickly and and to be direct that's a little bit at odds with the gent in the back who's arguing for a more nuanced model or the person who asked about defend. Um these are um no no model the the quote that opens my book all models are wrong some models are useful. Um maybe we end up with more than one

model. But I will say that the four qu going around to the executives at your company and asking them what can go wrong and what are we going to do about it requires zero technical skill. it requires no technical knowledge and it's one of the advantages of the framework is that we shift the the attention away from tools that I find very natural like stride and DFDs to these very broad questions that open up a conversation and thinking about how do we talk about this you know are there may maybe some of the answer is metaphors that work within a particular vertical. And I think that the drug discovery side of things might be more amendable to this than some of

the others because I do a lot of work with medical device makers and they are very very focused on yeah the device carries some risk and we're using it to save someone's life. So we really want to ship soon so we save those lives even with the cyber security tradeoffs that we might have to make. And so maybe there's different answers in different in different verticals. >> This may be a bit simplistic for the level that you're coming in at but I switched at some point in my life from working security under DoD rules to working under banking rules. and the DoD have an absolute model of sweat. If there is a vulnerability, somebody will

come through it. And the banks just say, "How much money are we losing?" And they do fight about that. It was a horrible shock. One of the things that I haven't seen in for instance the layer thing is a sense of the completeness of any layer. And when I originally went into D rules, they said a firewall is worth 1.15 protection factor. What this means, two firewalls is worth 1.3 or three firewalls is worth 1.4. 45 and if you can get to 2.0 you're certified. Obviously laughable. So when a formalism that says we have layers but that each layer is as near complete as possible and therefore these layers are truly cumulative because I feel like a blue

team needs that whereas a red team just needs to find one scatter shop hole and therefore a toolkit may suit a red team better. layers means completeness of each layer. >> Actually add on that too because I just had this additional thought. >> Yeah. So I just wanted to to add on that too because what I was sitting here thinking was um all of these models have a place but especially thinking that the um the layer like what if the layers had a toolkit and that way you you know what you're using on each layer as you as you come at it. So that was my additional >> all these things need to work together

like that. >> Yeah. And I even the other your even your final threat model was just I I think you keeping it um that would be kind of hard to explain explain to like all all like an entire department or an entire like organization. >> There's one. >> Yes. But did you want to respond to that while I watch this? >> I h I almost don't want to respond. I almost want to desenter myself out of this conversation. I I recognize that there's this weird dichotomy of I'm in the front of the room and you're all looking at me and I'm talking about how I value your input and then it's all star conversation. So

go ahead over here. >> So nothing earthshattering from my perspective. Uh I agree with what other people have been saying that toolkits existing within lance seems to make sense. Uh one of the things that I brought up like I filled out the the thing online. >> Thank you. >> Um one of the things I found in practice is like a thing that I've liked and a thing that I haven't liked. uh when it comes down to stages and layers, I prefer layers. And one of the reasons why I like layers is a bit of a human factor where for some reason in the layering process, I found that I I brought more people along on the

security journey as we went through the process of going through the layers, implementing things and improving things. And I also thought it was something that was much easier to do as a reiterative process. Now I understand that the engineering stages are supposed to be a reiterative process but I find that practically as the security importance of security is important and waines within a company.

you have the the the security theater and you have the the the the um you know going through the motions of going and doing a security thing but operationally things don't tend to uh fall into place because in a layered model you basically have to have an architecture set up as you go and you improve it as you go where in the engineering stages it's kind of like you know fail fast sometimes >> and that just doesn't work with me but I'm a blue teamer. So yeah, whatever. >> Okay. So, so the operational model, the operational model ties into the completeness concept and improvement over time in a way that maybe the engineering model doesn't

>> I didn't know he wasn't done here. >> And he gets to improve his team >> and and for some reason I feel like my team improves and gets to be more involved and gets to upskill >> by going through the process. you don't have the old wise bearded man in the room doing saying whatever and evangelizing like it's it's it's an actual practical process and you're bringing and you're working with people on the as you go >> so important so important >> it's really hard not to be opinionated and just walk around >> you can be opinionated >> because so often security is the house of no we show up with all this heavyweight stuff and so if you show up

with something really lightweight like a tool kit and then let the people you're working with say, "Hey, I'd really like more structure." Well, let me tell you about layers. >> Um, so something that goes into all of these different models, whether it's a toolkit, a layer, an engineering stage, has to start with like participation of the stakeholders that you're working with. And something that you brought up in your presentation was, hey, we don't want to make a threat modeling program or threatening exercise that really relies on security being like the ones to guide and the ones to make these decisions. We want to incorporate these stakeholders. We want them to help build out these defenses with us versus us

dictating. Do you have any advice or any experience on how do we get that buy in from those teams? Because in my organization something that we see a lot is you guys are the experts help us figure out help a solution. >> Yeah. So um th this is this is its own specialtity and we we help customers all the time go through this journey. But it involves getting an understanding of the forces which are driving change at the executive level. You know in in the previous in in the previous talk they talked about how Satia's directs approved some of the work they were doing and there's both the executive buyin but there's also the proof points. And so

often times what we can do um to you know to to to tell a story of very ancient history there's all of this stuff about Bill Gates wrote a trustworthy computing memo and then Microsoft started doing security that is true but it leaves out the work done by a lot of teams before that memo including a net security standown where the VP was willing to say yeah that was a good idea and So understanding why people are saying we don't want to do this. That's often we don't understand what you want us to do. We don't understand what good looks like. We're scared to be doing something that we're not good at, especially around security

where we don't want to mess it up. You've got to build the credibility that they can do it. And then you've got to build management belief that they have to do it because the security team can't scale to run around and jump into every single development cycle and have useful answers at at a speed that's that's feasible. >> We have a a freelance instructor with Showstto and Associates named Jamie Dicken and she gave a talk at RSA a year ago. two years, two years now. >> Um, and if you ping us, me, whatever through LinkedIn, I will send you a link um to that video. But it's like a 30 minute talk about how they not only got

the engineers of their company to do threat modeling, but like it. Um, so

>> the thing that uh we found most helpful when we're doing threat modeling, especially with people who've never done it before, we have to introduce it is uh what we'll call playbooks. >> Okay. >> Um because you need to give somebody something they can run through, right? They might not have a whole lot of preparation. Uh might be a new facilitator or you're an experienced facilitator, but you need to hand off facilitation to somebody else, right? So, uh, it's questions to ask, it's how to do things. Um, and somewhere between the toolkit and layers comes in, right? I I think in like sim and sore tools. So, you know, you you you have the boxes

in times or whatever else. And just kind of being able to draw that and maybe you have enrichment at each step, okay, >> where you're making sure you have the right people in the room. Okay, what does that look like? How do we do that? How do we make sure that we have the right people in the room? Okay, we need to make sure that we've identified the controls. How do we do that? Um, and so a toolkit is maybe more helpful for that kind of metaphor and and just like a whole package that you can give to somebody as opposed to um like an answer or use this model. It'll be fine. >> Okay, so run books. Thank you.

>> Also, hum, if you love times, oh my god, that's so awesome. >> They're not paying me. >> I know they don't pay me either. And we got so much use out of that in my last corporate job. All righty. Okay. So, uh I work predominantly with people who are doing what uh I refer to as foundational steps towards security. Meaning, uh usually I work with R&D teams. They have no concept of what security is. They've never heard of it. And I'll get brought in on things like um the security team is telling us that we need to do testing and we're telling them what we're going to test in production because we can't do testing

unless we have user data and they won't let us do that because the security team and the AI team have a really different concept of what testing is. So for that situation um none of these help because you're into somebody who doesn't understand >> literally what you're talking about. They don't have any model of the world of security. >> Okay. Um the place where I've found the most traction is to be really tactical to be like write down like what data is in this app like not a data flow diagram they don't know what that is like like run these three tools right and then you're allowed to talk to a person like you know step one step two

step three um that sort of level I think really reaches the developers and the the scientists the people you are never going to get on board. I in order of preference of how I use these also I like layers if you're talking to people who understand what an application is, engineering stages if you're talking to an R&D team and toolkits if you're talking to people who literally only speak in tools. But they're all on some level valuable, but we probably don't have to pick one. We probably need all of them anymore. Quick shout out for LLMs to create synthetic data so that people do not have to test in prime >> and I love the fact that the audience

called no. >> So I'll just comment about what you just said. Absolutely start with the data because when you said test production I kind of okay but think about it every major service in the planet test production because you only have one google.com or one Microsoft Azure. they don't have six unless you have geographical dispersions and that's a whole different conversation involving regulatory but when you talk about the data um I work in pharma medical financial all the all the interesting data so one of the things that gets me out of bed in the morning and so I agree with that approach >> all right so I we have to actually cut it off um for

>> but I do have I do have more four question framework cards everyone can have one whether you had a question or everyone can get it. >> Um, so I just want to say thank you again. Really appreciate all of the comments. Um, and I'm really really excited to continue this conversation both here over the next day and then online uh going forward. So, thank you