 Thank you. Thank you It's a real pleasure to to be back in Montreal and to see so many people at an infosec conference when I when I moved away 15 years ago this this was nearly unimaginable Which is part of why I had to go and so I'm really I'm really psyched to be here And I'm psyched to see such an amazing community and have a chance to speak with you. So So thank you and today I want to talk about some pen testing and threat modeling lessons from Star Wars and I was talking with with Richard theme yesterday and we were joking that I had the advantage of choosing a movie that some of you might have seen and So really what I want to talk about today is three major things. I Want to start out by talking about what threat modeling is From there give you a simple approach Some of you raised your hands when asked if you know about threat modeling some of you didn't so I want to bring everyone up to speed and then I want to share top top 10 lessons that I've learned along the way and So let me start out With what threat modeling is and some of you raised your hands when asked if you know how to do this And some of you didn't but I'm gonna argue you all know how to threat model That if I were to ask you to help me threat model my house you would have no difficulty doing so You might start out by asking you about doors and windows You might start out by asking about family or pets or pre digital photographs or other valuables in the house And each of these has an analog in the digital world Doors and windows are the are the entry points The valuables are the assets and so We can take the things that we've learned how to do as we grow up as we mature into adults and we can bring them to the digital world and as we do so oftentimes it doesn't work quite right and So as People became more and more focused on How to threat model how to bring threat modeling into a software development process How to get non security people to threat model effectively or to know when they were outside of their depth we added complexity we added Layers of things like list all of your assumptions or start by listing your assets and these didn't necessarily work and so About ten years ago a little bit more now. I had the Opportunity to take a job at Microsoft and on my first day there My boss said the threat modeling thing is broken. Can you please fix it? And I said, what do you mean? And he said, I don't know step one is to figure that out for me and tell me and convince Me what I mean by that and then go do it and so I've had the opportunity Over the course of about of over a decade really To be yelled at by an enormous number of people Who told me that the threat modeling things I was trying to tell them didn't work? And so if any of the things I tell you don't work, please come yell at me Because that's how we learn and I'll share oops I will share the top ten lessons that I've learned along the way But before I do Well, I've talked about threat modeling and I want to I want to tie it to penetration testing Their bookends Ideally you're going to threat model before you do any other security work And ideally you're gonna pen test is a very last thing to see whether or not the things you planned the things you hoped Actually came to pass in the system that you're building the system that you're analyzing the system that you're working on in some way and so I think of them as natural compliments that a Good pen tester has learned to be a good intuitive threat modeler a good threat modeler a good threat model can help inform the Activities of a penetration test of a red team in really exciting ways, and I'll talk about that But to start out I want to talk about a simple approach to threat modeling I said we added a lot of complexity over the years, and I should mention that I've done this work Not only at Microsoft. I've done it with open source projects. I've done it with All sorts of different companies in and outside of the technology space. I've done it with some governments This is not a Microsoft-centered talk in any way With that a simple approach to threat modeling I start with four questions. What are you working on? What can go wrong? What are you gonna do about it? And did we do a good job? And the reason I like these questions is because it starts out with something that people should be able to answer If I walk into a room full of engineers and say, what are we working on here, and I can't get an answer That's problematic and I have to provide a whole different sort of help Right, and so it's a comfortable thing because people like to talk about the stuff that they're working on and so As a consultant as an advisor It's a great place to start and the place I like to start is the whiteboard and I'll come back to that in just a minute and From there we go to the question of what can go wrong and This this is the nub of threat modeling. This is the hard part It and I'll talk about why I'll give you one simple approach that you can start with and a bunch of others that you Can use and other in situations where it doesn't work What are you gonna do about it? I'm gonna speak briefly about right now You're gonna file bugs and you're gonna file bugs in the thing that the developers or the engineers or the ops people are Using to manage their system Because if you write a threat modeling report that report is gonna sit on the shelf It's gonna gather dust and it's not gonna lead to improvements in the security of the system Did you do an acceptable job is one of those engineering questions? Can you look back? Can you say yep? We did this we created a good model of the system We pen tested against that model of the system and we weren't surprised by anything we found So those four questions we start with what are you working on and Since we don't have a whiteboard. I've got a little animation Pretend this is on a whiteboard We might be threat modeling a web app So we draw that and then we've got a customer who talks to the web app in some way we got a back-end database and We can draw a little boundary around this we call it a trust boundary and The point is to say what's what's in our control and with just this simple diagram We can start asking questions about what can go wrong How does the the web app know which customer is showing up? How does the database know where to take data from and where to give it to? Right these are these are super simple questions that a diagram like this provokes We might have a content creation system that also talks to the web app to add a little complexity But these these sorts of things are an easy way if you're walking into a room and Talking to the engineers that are doing it But when you're doing a pen test, maybe you don't do that, right? You've got a different way of saying what are we working on and we use tools like nMap like TCP dump to start Analyzing the thing that we're building to start or start analyzing the thing we're taking apart excuse me and As you're doing this you can create a model in your head of what it is you're working on what it is you're doing a pen test against and The thing that I find is so rare and so powerful Is to take that model and put it on a whiteboard, especially if you're working on a team so that the data goes out of your head into something that you can point out and collaborate with and Even if you're not working on a team when I take apart systems I have a sheet of paper with me, which is just a picture of the thing Has very few words on it. It'll have some describing protocols and whatnot but I create that picture because I lose track of stuff as I learned things and So Sometimes sometimes you'll do this without a copy of the teams of the victims threat model Sometimes you'll do it with you have a glitch on the con here. Let me try Screwing that in so that it doesn't jiggle quite as much and I'll turn this So maybe it's a little less That's very exciting. I apologize for this. I am testing the idea that it's a physical problem versus a logical one Does it seem to be working? I'm gonna give this five or six more seconds of Um Sure, actually can I get one of the AV folks? To come up and give that a shot with me so that I can All right, so my Mac thinks it has a connection because it's doing the PowerPoint Speaker mode Why don't we switch back to VGA since that was at least partially working? So what I was going to show you My very next slide Olivier who spoke yesterday on the moose botnet had a Had a slide that oh you can see something I'm gonna stand far away from this look we have video I'm gonna stand far away and try not to step down the back of that in the hopes that I don't jiggle my computer Um So I was excited to see this and I spoke with Olivier after his talk and he showed me the whiteboard Diagrams, but I like I like the pretty version of this picture Diagramming what you're working on being able to point to it really helps keep make sure that everyone Involved in engagement is Doing is thinking about the same thing and oftentimes I find that just getting things on to a whiteboard provokes so many arguments about what's actually happening that you find not lots of nice Disagreements and you can exploit the heck out of that disagreement and misunderstanding between the owners of different modules You can get a little more formal. I'm gonna skip over the data flow diagram thing because I lost a little bit of time To to playing with the video and I want to move on to the question of what can go wrong and For what can go wrong? I want to encourage you to use strides strides and mnemonic It stands for spoofing tampering, repudiation, information disclosure, denial of service, and elevation, and privilege. You got that? Great. Let's move on No, it's a mnemonic, but to help you remember the mnemonic I want to walk through it a little bit more slowly So spoofing might be Someone pretending to be a stormtrooper It might be someone pretending to be a Nigerian prince. It might be someone pretending to be paypal comm Each of these is an example of pretending to be someone or something you're not so the essence stride stands for spoofing The tea and stride stands for tampering that might be Ben Kenobi Tampering with a power supply and might be someone modifying bits in a database. It might be you modifying web requests With the awesome backslash scanner that we saw yesterday In each case it involves Modifications of things so the tea and stride stands for tampering the are in stride stands for repudiation That might be Han Solo say we've had a reactor meltdown very dangerous Than everyone's fine then shooting the console. It might be someone saying I'm sorry I didn't see your email or that package never arrived in each case It's about having logs so that you can look back into the past and understand what's happened The iron stride stands for information disclosure now You might notice if the video yet the video is I Was just gonna say you might notice if the video is working then I don't have a Lego version of this slide and You know Part of that is I couldn't find a good Lego version of this online and part of this is people are very confused about What Star Wars is about? Does anyone here believe that Star Wars is about like Luke's journey to manhood or his relationship to his father? You know, this is a trap, right? That's why no one's saying yes Good for you If you believe the critics they'll say those things but the truth is Star Wars is all about information disclosure and its consequences from the very opening crawl or now even back to Rogue one where we see the plans being stolen and then the opening of episode four where we see Darth Vader ship pursuing Princess Leia All the way through the climactic final battle Star Wars is the story of information disclosure and its consequences I recommend that you go rewatch the movie in that light. I'm sure you'll enjoy it There's other for that. Oh, excuse me There's other forms of information disclosure We we saw a talk from the tour folks yesterday from David about Just the fact of communication can be an interesting thing that people want to protect We've seen talks on SSL TLS about protecting the contents of those communications. And so The I in stride stands for information disclosure The D in stride stands for denial of service and whether that's freezing Han Solo in carbonite or Taking over half a million Webcams and using them to knock a DNS provider off the internet Each of these involves breaking availability in some way And finally the Ian stride is elevation of privilege that might be Ben Kenobi saying these aren't the droids You're looking for it might be someone finding a hidden web admin. It might be remote code execution In a file service protocol, that's for some reason exposed to the internet who knows so When you think about what goes wrong as Security folks, I encourage you to remember stride as a mnemonic to help you think through the different sorts of attacks that you might execute or the different sorts of attacks that you might want to defend against so Brings moving to question three. What are you gonna do about it? There's a bunch of different answers If you're building a system Then there's a set of tools you can use and the thing this this table is Down the left-hand side. It's the stride Attacks the middle column is the property that those attacks violate and then there's an approach Mitigating that a standard sort of way to dealing with those problems, but you can also think about this in terms of pen testing You can say oh There might be a spoofing attack. What sort of tool do I want to pull out of my toolbox to start Executing those attacks to start seeing whether or not the system is vulnerable to these things And so the same sorts of models can be used to help you understand Attacking a system from an attacker perspective or from a defender perspective With that with that I want to switch to the top ten lessons. I mentioned I've been yelled at by a lot of people and The reason that people tend to yell at me is because they want this stuff to work They want to be able to protect their systems. They want to be able to build defenses and When we give them advice that doesn't help them they get frustrated and so I've started to see these lessons as Traps I've started to see that each of these involves something that well-meaning people do that doesn't work the way they want it to and so my first example is Search your feelings Now in Star Wars whenever someone says search your feelings Someone makes a bad decision Again, watch the movie again. You'll see and so search your feelings is an excellent plot device and a really bad engineering tool and the the engineering equivalent of saying search your feelings is to say think like an attacker and I'll tell you a quick story about this. I was in a meeting. This is about 2006 And I said to someone think like an attacker and He sort of scowled at me and went to his laptop and didn't participate through the rest of the meeting and then after the meeting He he grabbed me in the hallway and politely said Adam I'm a little concerned about the way you expressed that. No wait. That's not what he said This was Microsoft. This was 2006. He said that was the most bleeping annoying bleep bleep bleep. I've ever bleep and heard I Was a little taken aback people have been saying think like an attacker to me for 10 years before that it seemed like a natural thing to say in the circumstances and What I when I got him calm down. He said What he said to me boiled down to two things one was He didn't know what to do and Two I made it sound like he was an idiot for asking and he didn't want to be made to feel like an idiot again It was a hard lesson for me. Um, I was doing something. I didn't think was doing any harm and This guy shut down Because he didn't know how to respond to what I was asking him to do and so When I'm working with security folks, I will say think like an attacker When I'm working with people outside of security, I Look for structures. Um, I Look for ways to help them get through the things that I'm asking them to do So trap number two is to say you're never done threat modeling. I Feel that way. I really do and In a sense, it's true. You can always go and find one more problem All right, you you're never done pen testing either. You always can find one more good bug and the trouble that we face is that if I go to a VP of development and I say We should threat model as part of your process or we should do a pen test as part of your process They'll say great. How long will it take and I say you're never done pen testing They'll say great. Don't let the door hit you on the way out and So we need to unroll this and this by the way I should mention is is the same four questions just drawn in a little hamster wheel of pain Model, what are you working on? Um What what word is there identify threats what can go wrong? Mitigate what are you gonna do about it validate? Did you do a good job, right? It's the same questions and I drew this I drew this when I thought I was simplifying things and I added a problem inadvertently and so now I like to unroll this and think about this in terms of We're gonna we're gonna build a little time box for each of these activities and when I first tried to do that It felt really worrisome. I'm like, what if What if we go through and we're still finding great attacks? You know what the answer I found is if you go to an executive and you say we're still finding a lot of really good stuff a Lot of times they give you more time to work on it The fact that you put a time budget in front of them is an enabler In a lot of circumstances where otherwise you're not making the progress you'd like to make so Trap number three the way to threat model is Used to be people would come to me and say, how do I threat model my whatever and I would say well you use data flow diagrams You use stride and what I've learned is that people do all sorts of different projects if someone were to come to me and say hey, I'm building a Device driver you might want to use C. I'm building an insecure website. You should use PHP different languages have different strengths and so Rather than saying the way to threat model is I'm much more focused on How do we help people find interesting threats? How do we customize the things we're asking them to do in a way that maximizes their strengths and I think in a similar fashion we can say there's no one pen test methodology that's going to Address everything you need Right this morning. We heard from someone from the privacy commissioner's office Talking about dropping a new root cert into the things they're looking at so they can man in the middle them Is that really a threat if you own the device I sort of think you should be able to drop your own cert onto it and man in the middle Let it seems like a reasonable thing to want to do occasionally Um, but the way you threat model the way you pen test different systems should be focused on that system Rather than on the way you'd like to approach it So a variant of this is monolithic processes Um, you might have thought that the Legos were just there for fun They're not the Legos were there because I actually think of Legos is sort of fundamental Sort of fundamental I think of Legos is fundamental to the way in which I approach these problems, which is how can we break them down Into the smallest useful building blocks we can And so we can develop different building blocks for modeling We can use data flow diagrams. We can use nmap. We can use lsof We can use swim lanes. We can use all sorts Of different ways to break out the system that we're looking at to gain an understanding of it And we can complement those with different ways of identifying problems with different depths of identifying problems Do you need to Find a crash or do you need to actually develop a proof of concept? Do you need to weaponize it? Um, you can apply different building blocks to the process of identifying a threat um And you know attack trees kill chains k peck the mitre common attack pattern Enumeration and categorization Is an interesting one. I'll talk more about in just a minute. I'm going to skip over privacy threats Um, again just in the interest of time But if you have questions, I'm happy to talk about it a bit later so when I think about When I think about different ways to identify threats, I like to think about who's using them And so we've got a continuum here And at the far right side, you've got security mavens and then at the far left You've got experts in other areas, which is a bit of a tongue twister And the reason that there's a tongue twister there is I used to say non-expert Until I realized I was insulting the heck out of people who had expertise in databases Expertise in usability Expertise in networking expertise in scalability. There were all of these Non-experts who I was just saying They've got no expertise. So now I've got a bit of a tongue twister and if you're in security Then stride allows you to think about what's going to go wrong with a system and it can be very helpful Attack trees allow you to organize your thinking about how someone might execute towards a goal And that can be a very helpful way of attacking a system Capek is sort of in the middle For those of you who are not familiar with Capek, it's a pattern library. And so the pattern Description for SQL injection has subsections like SQL injection is code data confusion. Where does it occur? It occurs Usually around web servers that are talking to a database back end. How do you test for it? You use these insertion attacks. How do you correct it? Here are some patterns for fixing it My guess is that most people in this room Who have a few years of experience are likely to look at Capek and say I know all of this stuff It's a very heavy weight. It doesn't help me It's not intended to help you. It's intended to help people who are getting exposed to these problems for the first time Get an understanding of them um The kill chain the kill chain is another great model It's very helpful as you're thinking about organizing red team activity as you're thinking about defending against red team activity um But when you bring the kill chain to people who aren't security experts Even the names of the phases like reconnaissance and lateral movement require explanation Um And then the last one one more thing I want to talk about About the way to threat model is is about checklists I'm often working with customers talk to them about threat modeling and they say adam Do you just have a list of everything that can go wrong in my system? Do you have a list of everything you're going to pen test for? I'm like, are you doing something new and cool? They're like, oh, yeah Whatever it is they're working on and I'm like great I'm going to find new and cool attacks against that I don't have a list beforehand Of what's going to go wrong and I used to really have a a thing against checklists Because of this and then I read a lovely little book called the checklist manifesto. Has anyone here read the checklist manifesto? One Wow, okay, maybe two um So lovely little book Um, and when I read the checklist manifesto what I learned is the difference between a good checklist and a bad checklist A good checklist consists of five to seven items that can quickly be answered. Yes or no That address commonly made mistakes during a process So for example If you're landing a plane the checklist says things like did you talk to the Ground air traffic control ground control? Did you lower the landing gear and have you raised the flaps? Now that's all lovely and you can hand me that checklist But you should not want me flying your plane because I don't know how to fly a plane um A checklist Helps experts avoid problems And so one of the things I did in my book on threat modeling is I put lots of checklists throughout To help people see whether or not they were doing the right thing and some of them were very hard to do because Short five to seven items. Yes or no common problems And so that brings me to to an insight that I had um Which is that PCI which we often derived as checklist security Has absolutely none of the problem none of the properties of a good checklist It's 12 items with a bunch of sub items There is no element of PCI which you can't find yourself arguing about with an assessor um And the question of whether or not these are common problems I refer you to like 6.4.12 or whatever it is about cryptographic random number generators with proper seeds um And so maybe that's why we have one of the reasons we have problems with PCI um Not of course the only one so Track number four is to treat threat modeling as a single skill Someone might say I should learn to threat model But there's a lot of skills involved in threat modeling Um, and when I think about this, I think a lot about techniques I've talked a lot about techniques about drawing diagrams about using stride about k-pack There's also repertoire. There's also knowing the things that you should know um And the repertoire can include tools and how to use them it can include stories and you use all of this To analogize and reason about new systems to say, huh, I'm breaking into this iot device Let me look and see if it's got a listener that I can just connect to Let me See if it's got an admin admin password right you look for these common problems first because they recur um And that's part of developing the skill is starting to use this repertoire starting to use this knowledge And one of the things about repertoire is that um When you're when you're looking at a system you'll often find and I see this at both ends The early side the threat modeling the late side of penetration testing the Operational side of red teaming where someone will look at a finding and say but no one would ever do that Some of you have heard that I can tell because you're grimacing some of you have heard that I can tell because you're laughing but um, it used to be when someone said but no one would ever do that I would say Here's an example and sometimes that worked and sometimes it didn't and I was confused by this and So what I realized is that people mean two entirely disjoint things when they say no one would ever do that the first is But no one would ever do that and the second is I don't have time to fix this And and so now When someone says no one ever do that I say if I can give you an example of a time someone did this Well, we agree that it should be fixed And then I know which conversation I need to have and which arguments are going to work and which ones don't so Trap number five is thinking that threat modeling is easy that thinking that penetration testing is easy um It can feel a little bit like uh, like taking your x-wing out of a swamp or You know, it can feel a little bit like a musical instrument It's if you hand me a violin, please don't but if you were to hand me a violin It would be hard for me to make music out of it. There's lots of skills. I would need to learn About thing holding my fingers in the right position. I would go through easy songs And some people handed a violin Want to become a virtuoso Some people well no one handed but some people handed a guitar just want to play with their friends on the weekend And both of those places are okay with an instrument Both of those places are okay with threat modeling with penetration testing Where you can say I want to learn a little of this Great develop those skills to a point that makes you happy But don't think it's necessarily going to be an easy journey Um, so trap number six is thinking that all of this is for specialists Um that you've got your one guy out front who's got a totally different set of skills than everyone else Um, but what I want to do is I want to make it a little bit more like version control I want to be able to say, you know, if I went into a big tech company today And they asked me a question about git and I said, you know, I've heard about this version control thing It's not for me. I just back up my home directory once a week It works The interview would be over pretty quickly It'd be done Uh, but if I asked a question about threat modeling And they said, you know, I've heard about this. It's not for me Odds are the the interview would keep going and this is a bit of a stretch goal It's a goal for me As someone who's passionate about threat modeling is that I want to make it a more Unusual thing for people to know nothing about it. And that's why Um, that's why I dedicate so much time to doing talks like this Trap number seven is all about the wrong focus um And I'm going to use a little bit of a build in this slide because I want to talk about some of these things and Some of them might some of them upset people when I talk about them. So I'm going to talk about them one at a time um And the first wrong focus is to say is to start from your assets And this seems like a natural thing, right? Let's make a list Of our assets and go after them And if we don't have such if we have gotten no assets, why are we bothering? Why are we bothering to threat model? Why are we bothering to pen test? To borrow a line from this morning This vibrator doesn't have any personal information about you Um, why bother? And the reason that I don't like starting threat modeling from assets Is because it fails on a regular basis People are set told make a list and they start making a list of things like here's the money in the bank or here's our password And here's our reputation Those are three entirely disjoint things, right? One is something an attacker wants to steal One is something that an attacker wants is a stepping stone And one is very diffuse and can be damaged But it's hard to defend right your reputation doesn't exist in a single place And so you create this list and then what do you do with it? Well, you start thinking about how to attack it Why not start from the thinking about how you might attack it rather than starting by making a list of these disjoint things? The second the second wrong focus that I see really frequently Is to start by thinking about attackers. This is also natural, right? If no one's going to attack this thing Why would we bother? So let's start by thinking about those people who will attack it And last summer I was reading an article in the Atlantic. It was a long interview with president obama And he said something that really struck me what he said was We it was it was an eight-year retrospective by the way across his entire presidency And what he said was we underestimated the impact of tribalism in libya And that really struck me because the united states has been involved militarily in libya For long enough that it's part of the marine him which starts from the halls of montezuma to the shores of triple a Libya is an open society people go there. They write books. They write sociology. They write travel logs. They study The society of libya And number three the president of the united states has one of the largest analytical capabilities in the world available to him And they underestimate the impact of tribalism in libya if he can do that What hope do you have of guessing how the Soldiers in 63 198 in china or 8200 in israel have no one's written books about those People don't go out and write tell-alls. So how are you going to know? What their motivations are how they're going to respond to the pressures that we put on them I'm not saying it's impossible. I'm saying it's a very hard task And starting your project with a very hard task, which is easy to get wrong Well, it's about as good as search your feelings as an engineering technique um so Thinking that threat modeling should focus on finding threats Seems sort of natural And this is actually an interesting disjointedness between threat modeling and pen testing When I threat model, I want to make sure there's time to fix those threats not just to find them But when I come in on a pen test engagement when I come in on a red team engagement My goal is to capture flags. My goal is to find bones And then I hand them over And so there's an interesting The symmetry breaks down a little bit in a way that surprised me when I was thinking about this um And before I leave this wrong focus, I want to call back to trap number three the way to threat model is I know people who are really really good At threat modeling from an asset list. I know people who are amazing when they start out with a list of attackers It works for them. Who am I to say they should change? But If it works for them and it doesn't work for the organization they're trying to help It's worth considering So trap number eight is not having an alliance Is is thinking that you've got to do it all And this one this one hits all across security um If And let me explain first so along the supply chain if you're by if you're building an internet thing If you're building a toaster that connects to the internet, you're going to buy a chip From shenzhen and you're going to put it in your toaster Excuse me You're going to put it in your toaster and if that chip Can validate a signature as part of its bootloader Then there's a whole bunch of problems that go away and if it can't Because the chip that can validate the the file that it's loading costs twice as much as the one that doesn't Um, then there's a whole bunch of threats that are really hard to fix And once you're developing the operating system once you're developing the the internet connectivity for that thing That system on a chip decision has already been made And similarly if you're sending something out into the world You're releasing an open source project for example It's going to run in customer environments. You don't get to see the logs unless your customers want you to And so it's important to talk back and forth about what your expectations are and what You know, you can do what you can't do Um And so while rebellions are built on hope, I think security is built on threat modeling It's validated by pen testing And so you need to be able to talk and two of the tools I like to use for this purpose Or a security ops guide And a non-requirements document and so a security operations guide is precisely that Um Early as you're building a system write the security operations guide hand it to a security person If you're doing a pen test ask for this document Because the things that it's missing should be the first things you attack um The the non-requirements I had the pleasure of while I was at microsoft I worked on a document entitled the 10 immutable laws of security version 2 um And the 10 immutable laws of security are things like if An attacker can run code on your computer. It's not your computer anymore If an attacker has physical access to your device, it's not your device anymore And well, that's true of microsoft and it was true of windows This is an iphone And on an iphone neither of those things are true the fbi made a big deal last summer About how neither of those things were true and they really wanted access to the device But what the what those 10 immutable laws really were Is an expression of microsoft's threat model If an attacker can run code on your windows computer Back in the came out Windows 95 98 it wasn't your computer anymore. There was there wasn't even an admin account really There was but um But it communicated what problems microsoft worried about and if those problems didn't Make sense to you You might say Windows isn't a suitable thing for me. It was communication along the supply chain and it was actually reasonably effective so Trap number nine is a laser-like focus on threats I believe that there's an important interplay between requirements threats and mitigations I'm going to walk through these i'm going to walk through these uh one two at a time and so When you're thinking about threats You might say the plans for this battle station should not fall into enemy hands Great. We have a we have a confidentiality requirement. We know that information disclosure threats are important Awesome. You might also say With enough eyes all bugs are shallow We should publish the plans for this death star so that the good citizens of the galaxy can help us find out Whether or not it's safe You know who knows maybe the empire is full of open source advocates Um Whichever way you start you can have a useful conversation about the intersection of threats and requirements Um And when we flip that around it's important to think about what the requirements are While I was listening to the talk from the privacy commissioner's office He talked about certificate pinning a little bit And I said who are we protecting this device from? Is it really required if I have physical access to my light bulb and I install a new certificate on it so I can sniff it Do I need to protect it against that? Is that a requirement? Is that a threat? And is the mitigation of certificate pinning the best place that we can put our security dollars? and this is important because Threats can be threats can be mitigated to go back to the example of my house If i'm worried about someone coming in through my door, I put a lock on the door and then i'm done Right. No, obviously not. Someone can drill the lock. They can pick the lock They can kick the door down. They can go around to the back door All of these can be bypassed and there's a back and forth between these things that Is where a lot of interesting penetration testing happens you find one mitigation you go to another area um But more importantly, it's where a lot of not more importantly Also importantly, it's where a lot of security engineering effort gets laid down And so that back and forth is important and let me go to the third thing here, which is That if there's no mitigation You should change or simplify your requirements And what that means is if you don't need to continue the example If you don't need to protect against a man someone replacing the certificate on their device Then you can spend the energy that you would spend on certificate pinning and dealing with the potential problems after somebody Locks themselves out or your Your pin fails for whatever reason you can spend that on other security requirements which are more important and When when the snowden documents came out people used to say our threat model has changed Yeah, your threat model didn't change if your threat model didn't tell you people could listen to a network connection You had a bad threat model if someone didn't tell you that someone might want to drop malware or Implants or whatever they want to call it on your computer. You had a bad threat model And this may sound a little nitpicky But the reason I point it out Is that when someone says the threat model has changed It's our responsibility as security engineers to think about this whole triangle and to say If the threat if that threat now matters or if that threat doesn't matter, what does that mean for my requirements? and What does that mean for the system as a whole? and similarly If you're if you're red teaming something if you're pen testing a device And someone says oh that threat doesn't matter You should think about this triangle and find places where they're investing energy and variance of that threat And say so why did you bother with that defense? because a lot of times the That threat doesn't matter or the threat model has changed that threat doesn't matter Really means I don't want to spend time fixing that. It's an inconsistency In what they're working on It leads to wasted security effort. It leads to ineffective security effort and it helps you identify that misused effort And help people that you're helping refocus their effort Into more important places So when you hear the threat model has changed when you hear that threat doesn't matter Jump on it and think about this triangle um Because this interplay between attacks and mitigations and requirements Is one of the constant underpinnings of a lot of what we do And thinking about it in something resembling this way can really help you Get a little bit more Strategic and a little bit more effective in the penetration tests you're doing Now the last thing I want to say about this slide before moving on I drew this diagram when I was working on the threat modeling book And I was really bummed because when I drew it there were only five arrows And I'm like it should be symmetrical. What's going on here? And so I looked at it and I'm like what the heck is a what the heck is a mitigation That has to be in place Whether or not there's a threat and I said oh that sounds like an outstanding description of compliance and Part of the reason that I think our community tends to find compliance so frustrating Is that it ends up being a lot of wasted effort And that you know it's wasted effort because you walk by those systems on a pen test, right? You you're just like oh, yeah Look, here's here's this thing I'm just going to go over here and do what I want to do even though that defensive technology is in place Because it's not put in place with a clear understanding of how the threats The mitigations and the requirements interact for that organization So the final trap Is threat modeling at the wrong time? You don't want to be like grand moff Tarkin when this guy comes up and says sir We've analyzed their attack pattern and there is a danger. Should I prepare your ship? Um, that was a very bad day That was evidence that they neither threat modeled nor pen tested nor red teamed this thing Before putting it into production Um You want to do each of those activities at the right time you want them to build on one another In ways that help protect the systems that we're trying to protect So to summarize Anyone can threat model and everyone should and Even if you just find your job as pen testing or red teaming I want to encourage you to go out and start with those four questions. What are you working on? What can go wrong? What are you going to do about it? Just a little bit And I want to encourage you to do it soon Because the things that I hope you learn today will fade with time You'll remember less of them a month from now than you do a week from now And so give it a shot see if it helps you because I believe That the skills the techniques the the repertoire these are things that can be learned But there are lots of traps that have inhibited a lot of people from trying um And I believe I've been uh I've been doing threat modeling in various forms for 20 years now And I really believe it is the most effective way To drive security through your product through your service through your system whatever it is you're working on Or to demonstrate that those that thinking never happened um When you succeed when you break in what you're doing is you're proving that there wasn't good threat modeling so there's really of great complementariness between these two skill sets and Lastly, I think models are useful for engaging with leadership for engaging with management About what's going on and why because it takes away the details It takes away some of the hard to understand bits and a model helps you understand the world and Leads me to this quote by george box george box was a statistician who said all models are wrong And some models are useful And they're all wrong because all models eliminate detail the territory is not the the map is not the territory. Excuse me um But I want to encourage you to focus in on the useful kind So go out and remember the four questions. What are you working on? What can go wrong? What are you going to do about it? Did you do a good job? Be proactive find this stuff early Fix them before you pen test make your life a little bit more difficult, but maybe you'll have more fun on the pen test um, and go Go drive threat modeling for your organization um And so with that I'm happy to take questions. I'll be around for a little while after after There's also the book and I blog about this stuff on a regular basis. So thank you very much for your time You