Developing a Threat Modeling Mindset

okay let's let's welcome our next speaker robber Hurlbutt and he's talking about developing a threat modeling mindset give him a warm welcome thank you good morning I've been travelling quite a bit across country seems like a lot of times I just drive the airport and I'd fly 500 miles and then come back that's one of the few times that I'm actually in my own state giving a talk in my own place so I'm living in Enfield Connecticut so it was actually an easier Drive this morning than getting on a plane and flying somewhere to do this so glad to be with you this morning so a little bit about myself I am a longtime software developer architect

worked with a lot of teams over the years a lot of as an independent consultant working with a lot of projects finance healthcare government many other industries and just recently though I years of being independent I'm now working for another company or and so I'm no longer independent but finishing out a set of talks that I'm giving at various places on threatened modeling and so welcome here today again about me I also am a co-host of the application security podcast I'm not sure if you've heard of it or seen anything about it but it's something we've been doing for now over a year and we've had a - a couple seasons and some really interesting podcast interviews

out there so I welcome you to check it out just out of curiosity how many of you have heard of threat modeling before you came here today okay how many of you it that's a very new concept you don't know much about it today okay a couple of you great how many of you are using it today in your day to day work or often in your own work now let's say often because to me if you're going to do threat modeling you need to do it a lot in in terms of how you think and how you you go about your your work you need to be thinking about threat modeling or at least the

the potential threats are coming into your system quite often and also maybe how many have you an actual program of threat modeling in your okay excellent yeah of course do you do in the back there Brian so great I hope that at the end of this and certainly going forward this is something you're going to consider more in putting in place into your own organization into your own programs and teams and so on so this is a something I saw on Twitter recently from Miko - and who is the CTO of F secure and he spent it's funny he's been treat weeding things that he wrote in 2012 five years later and they all seem

to be very relevant but this one in particular it's just not fair when the attackers cheat they really should be regulated to attack our defense is only the way we want them to anybody ever felt that way you know what is the deal why do they keep doing things we don't want them to do why aren't they playing by the rules why aren't they following some kind of guideline that we put out there instead of doing something different or trying something different but you know the reality is they're not there they're thinking of other ways of new ways to try it again get in now the reality is there's a lot of attacks that are just the basic stuff right we're not

patching so they figure out what the patch is or the opposite and do that to get in very simple stuff but there are things that we find that are really clever and interesting and so in terms of trying to defend our systems we have to think differently in order to try to defend and so that's where I think about you know this this idea of a security mindset or as we'll go further into a threat modeling mindset and in particular Bruce Schneier wrote about this back in 2008 in a post everybody familiar with Bruce Schneier heard the name he say well-known cryptographer many years ago he's written a lot of good books on cryptography be tall but

also more recently more popular security books out they're on data and other kinds of things and in particular he wrote this that security requires a particular mindset professional security professional is at least the good ones see the world differently how many of you can relate to that that once you got into security maybe you were before doing something else but once you got into security and the more you're into security you see things differently you see an open door and you know what's going on there maybe that's something we need to take care of or you see certain ports open and say well we know why are they open that doesn't make sense so you think of things and you see

things very differently a little bit later he wrote another blog post in 2012 about teaching that to others so we in the security field if you've been there for a little while at some point you realize that there's others that need to know this as well it can't be just a few of us that have this knowledge in this understanding we got to teach others and he pointed to a story about our in a paper actually about a couple of instructors at a Naval Academy that had a class of teaching cybersecurity to students and one of the things that they did was they came to the class they said alright tomorrow we're going to have a

pop quiz or a test and what it is is we're going to tell you what it is and we want you to pass however you do it whatever you need to do pass it but the the test is right pi 3.14159265 all the way down to 100 decimal places on the test and we want you to cheat we want you to come in and figure out a way to get a hundred on this test and so the next day they gave the tests and and sure enough everybody passed but the ways that they figured out how to pass were really interesting for example somebody had on the ceiling tile written out pi so they just looked up and wrote

it somebody else had a little plate with a doughnut or something and then you lift the doughnut and there was pie written on the plate in a little sheet of paper somebody brought a book with the back cover it was a book by the author and they said oh there's my book except on the back cover they had written out pie and so you couldn't really tell that it was actually part of the book cover and all kinds of other creative ways in order to cheat and pass this test not the normal way of doing things and one of the quotes that Bruce cher pointed to from that paper was this one to teach your

students yourself and your students to cheat we've always been taught to color inside the lines stick to the rules and never ever cheat in seeking cybersecurity you must drop that mindset and so that's what I'm talking about is that we already know the attackers we already know they're trying to cheat they're trying to circumvent the controls we have in place they're trying to get around the things that we're doing to try to protect our systems in order to circumvent that or in order to deal with that we have to also think in a similar way and I believe you know think outside of the box essentially so that's what I'm thinking about is that you know that security mindset that

thinking outside the box thinking differently than we normally do and I think that's really again where threat modeling comes in is helping us to think in a bigger picture about our system what are the potential threats and how are some ways that we can deal with it and again think about you know maybe how an attacker would look at this maybe some ways that our defenses are not set up correctly that we need to think a little bit better about and so on so what is threat Mollie well threat mulling it to me is something we already do if you're locking the door to your house you're putting down the windows you're locking the doors to your car you're already

thinking about these things because as you move away from those places you know you leave your house you leave your car you're already thinking about well what could somebody do if they came upon my house or my car and see that I've got belongings in my car and so on you're already thinking about some things and in particular you're thinking about you know what could go wrong what are the risks here of leaving things out in the open and so on acting accordingly and we again we do this a lot throughout our personal lives we we think about ways that something could happen something could go wrong and that's essentially what threat modeling is you're thinking about what

could go wrong and now what do I do now that I know that information or have that information you're probably hopefully already doing these things in your security strategy how about pin testing you have those okay vulnerability assessments something like that - tools sass tools running those kinds of things against source code and running systems and so on and then a lot of other automated tools hopefully you're doing a lot of those logging we talked about a little bit earlier in the in the previous session if you're not doing threat modeling though you're missing a lot and I can say that with confidence because guess what your pen test is never really going to understand

fully your business process all that's going to ever really find are the things on the outside and test a few things but it's not going to really know for example that your password is stored with an md5 or a sha-1 it won't know that has no clue it won't know certain things and decisions that you made inside your system just well same thing with vulnerability assessments it may find a few vulnerabilities and certainly that can maybe give it a clue about the kinds of threats that might be in your system but it won't know all the business processes it won't know all the decisions that you made underneath and the same thing with you know checking

your code you'll find some things but it won't tell you everything and that's again where threat modeling comes in where you're giving a more holistic view of what's my secure design not at the code level but at the bigger picture what are some things that we have made decisions about or will be making decisions about in how we build out our application or our system and so by definition it's essentially that process of understanding your system and the potential threats against your system I like to think of it as critical thinking about security a typical threat model includes these four things you can see variations of them but this is what I liked includ if I if I can if I'm working with

a team is that understanding of the system that may include a drawing of some sort a diagram of some sort or at least an understanding of what is it that we're building what is it that we're trying to protect any identified threats that are we might find in the system any mitigations countermeasures and so on and then also any risks associated with all those things we've found and the priorities associated with those so for example if I find a hundred threats I'm not going to fix all hundred necessarily maybe some things are more critical than others and so the risk managing that and understanding that helps you in terms of prioritizing work later on quick definitions assets are

the things we're trying to protect usually that's what a lot of people focus on when they're doing threat modeling sometimes as they think about okay what am i protecting what are the things that are important to to me into others we also think about the agent you know who is it that once to get in and who is it that wants to do something to our system and so that could be a person it could be a process that's that's trying to get in and by the way they all look like that so you have to have that in every you know at least in somewhere in the slide deck some somebody with that or the other one which I have in a

moment you'll see the threat is anything that's going to exploit the vulnerability and intentionally or accidentally and that's kind of funny in a way because a lot of times we think about the intentional attacks and the attentional threats but they're also accidental ones I mean we saw that a couple of days ago I saw an article about I think there was a problem with a fire extinguisher that that took as you're down in Europe like what and then AWS I've seen that go down because of somebody hitting a server or doing something with a server incorrectly and it took down AWS in a certain large area and there are all kinds of things that can happen

accidentally that actually can become threats and you're like well what happens if somebody does this do I ever think about that and ultimately again they can you know the threat itself can obtain a damage or destroy an asset vulnerability is the flaw in the system that X lets you realize the threat so I like to think that you know there some people use them interchangeably but to me they're not you know the threat is realized because the vulnerability is present if I'm able to mitigate the vulnerability then the threat is also minimized and so just understand that you know that we look at vulnerabilities but in terms of threat modeling we want to try to understand what is the threat

so I might have a sequel injection vulnerability in an application and website well what's the threat here well be by using the sequel injection vulnerability I'm able to get to the database and I'm able to retrieve data I'm able to change tables I'm able to do all kinds of things if I'm able to mitigate a sequel injection problem then I minimize the threat and so those two kind of work together but they're not the same thing the other thing that also helps drive your threat modeling is risk and understanding risk and that potential of the of the loss damage destruction of that asset and in the threat realizing the the vulnerability and so that's very important is

understanding risk and that helps drive a lot of things that we do in security anyway I don't know about you but I think the mouse has a chance how about you he does and this is the other the other thing you have to have in a slide is is this guy with the you know the cowl and everything and the attack is a motivator sufficiently skilled trade agent and I like to think about this in terms of that can vary among different areas the motivations can be very different you know the nation-state hacker can be very different than the the hacktivists the the person who's trying to make a point with your site and changing it and

then of course the sufficiently skilled threat agent you know that can vary as well they can be a script kitty that we ought used to hear about years ago all the way up into the nation-state hackers and attackers that are essentially on a job I mean they're paid a salary they have you know if you ever watch they say that in some places if you watch where the attackers are come coming from they have certain hours just like we do eight hours that they're working and doing their job because they have a job they go in they attack they go home and they get their paycheck or something like that very funny and interesting but all

of these again taking advantage of a vulnerability in terms of vocabulary this is something that John Steven put together some time ago it just shows you how everything's gonna related to each other and that's important just to understand in terms of this this whole idea of threat modeling a few approaches to threat modeling one is the software centric which is the one I focus mostly on I work with developer teams a lot and trying to help them understand the the process understand okay what is it that we're doing in the system how does it interact with other things and then build our our threat model from that and it's focused again on secure design it's

focused on data flow diagrams which we'll see in a moment another way is this asset centric way a lot of times people use asset are very attacked trees to try to figure out how do I get from point A to point B to finally get to my goal and kind of a decision tree to get there I will see that some people say well I that's how I start with an asset and that's okay and certain in certain cases it makes a lot of sense especially if you have a system that's already been built but if you have nothing built yet and you're starting from scratch you may say for example I want to build an

e-commerce site well okay what are you going to do with that well I'm gonna have credit cards want to take credit cards I'm going to take payments well where are you gonna store it well I may either store it in a database that I own and then I'm going to do my own PCI compliance and all those kinds of things or I may say I don't want to manage that I want to move it off to somewhere else and now those assets are somewhere else and it's somebody else is handling that so then your threat model can be very different depending on if you host the asset or you let somebody else host the asset so I'd like to say that for asset

centric threat modeling it's I think it more in line if you already have something but if you're designing from scratch I'd like to look at the process first and then you'll uncover where the assets go and then finally another way is the attacker centric method which is basically focusing on the profile of the attacker the different patterns that they're using sometimes I'll use this as well but I use it at the very end I like to try to figure out all the other things first and then figure out okay who's interested in this and see if that might filter out my threat model too maybe point to some things that are more likely in this particular system this is

something that I've been thinking about for a little while is teach threat modeling to your teams you know conduct training in your companies like like what we're doing here help teams threat model their own projects work with them if you haven't done this before just sitting down with a group of developers or engineers other engineers system engineers and thinking through a lot of these things I find that it's really beneficial there are some things that maybe they didn't even realize about the entire system yeah maybe for a developer they are working on the UI they don't know how the database works the middle tier doesn't know how the UI and the and the database necessarily works or at least fully and

how it maybe interact with other parts of the system but if you have a team and put them together and and try to build a threat model you'll find that there's a lot of things that they learn really well and then encourage beginning threat modeling with each project each new feature so you may have never done this and teams may never have done this before but if you encourage them that now okay now you know something about threat modeling now let's continue to do this and add it to every new thing that you do that's also another way of making sure that threat modeling is integrated throughout your system and then follow up make sure that they they understand

it make sure they're working with it I'm working with some teams that have made commitments to say that now every team must have a threat model every project must have a threat model and it must be reviewed and and so on so it's that encouragement that you know it's not just something we talk about but it's something that we do so a typical threat modeling session like if I was doing a workshop and you know it's a hands-on what we usually do is we try to figure out what's the domain who knows what's going on in the system get the team together not just one person's job how many of it's just one person's job to do

security today that's all you know there's one person doing everything go figure out the rest of our system anybody doing that probably my goal is not to that my goal is to try to get people together and because they know it better than you do typically you know the developers know something and when you do that and you get a team together and you ask to see the architect how's this set up what's your system look like and the architect says well it does this and does that and the developers say no doesn't not really there are a couple things that we change or a couple shortcuts that we took that we're not so obvious and so everybody

learned something from that also focus on business and technical goals the business goals may be different than your security goals for example I remember working with a financial company where we talked about implementing some kind of two-factor authentication for their users and they had two sets of users the admin or managers and regular users and we talked about that I said you need to have that for everybody I mean this is a financial company why don't you have it already that's my goal they said to me that you know we have different schedules what we'd like to do is try to put two-factor authentication in for the managers first get that in place see how that works and

then eventually get the users because you know we just want to gradually get them there that was their business goal slightly different than my security goal but that's okay and that you know we built a threat model around that that okay here's our time period here and here's our time period here that our threat model may change as a as a result technical goals you know everybody makes a decision about platforms about products that they're using about third-party libraries for example struts I know there's a company that we hear about the news lately that you know made a decision about struts whatever you know third-party library that you select it impacts your threat model it impacts

what you're doing because every third-party library or anything else that you bring in they now become your responsibility and they change your threat model they change the things that potentially could make you vulnerable in your system based on the fact that you made a decision of bringing that in and so now you need to understand how does that impact your threat model for your particular application or your particular system and so really threat modeling must support all these goals not the other way around you don't come in and say well you know I who cares what you want to do let's do it this way no you need to understand where everybody else is coming from and then

understand okay can we meet somewhere where security is important but it also helps support what you're doing as well meeting dates and times pretty focused sessions I like to do and then very important I've learned this over time is you know be honest leave ego at the door and no blaming because when you're doing this discovery situation or session you you want to make sure that people are not feeling I can't talk about this I can't say it because then everybody will point at me and say you know why did you mess that up why did you not do it right or what you know it's really about discovery so I always say you know be

honest and and you know if it's something that was wrong say it and now you know and now you can go fix it so very simple tools to start with really there is no tool today an automated tool of some sort that I can fire up and point to my system and and push a button say build me a threat model it doesn't happen instead you you really need to understand the process and even the tools that are out there you need to understand something about the process to use them and I always say the simplest thing is the simplest thing white board some kind of graphing tool to record what you what you drew and

what you came up with Word or Excel or something like that to record your findings there's a great resource from Dennis Cruz that's out there it's this page simple page to record your drawing record some information threats and so on and then on the back some information about you know basic threat modeling and and for example stride which we'll talk about a little bit and different things like that and I like to hand these out when I do a workshop a training workshop where people are doing hands-on I just hand this out so they can look at this and it helps them understand the concepts you can record things in a simple way as I said this is an example

worksheet that I've used where you record the threats the countermeasures that you find some follow-up and this ID I like to record just to relate back to if wanted to to JIRA or something like that where you're tracking these kinds of things several tools out there there's the most famous I guess are well known as the Microsoft rep modeling tool which is a windows-based tool but there's some others the threat mauler the iris risk tools are paid tools threat money tool is free but these other two are not and then the latest one is this Oh a threat dragon which is a really interesting project a wasp project it's a free tool that's in progress right now that's out there

so to get started when I'm working with a team and helping them understand threat modeling I like to go over the security principles defend in depth and least privilege and so on being reluctant to trust and so on just to make sure that there have some kind of ground grounding a great paper I like to point to is this I Triple E Computer Society Center for secure design avoiding the top 10 software security design flaws a lot of people have heard about oh wasps top-10 this one kind of looks at that in a similar way in terms of top 10 something but in this case its security flaws design flaws so for example not getting cryptography correct

and you know mixing up a ten ocation authorization a lot of people do that where they'll reverse them or they'll think that their authentication is the same thing as the authorization it's not and so it talks about that a lot but mainly what is was doing is trying to point out the difference between a bug and a flaw a bugs and implementation level software problems so there's a mistake that's been made an imp one type of problem versus a flaw where you've made a decision at some point that has impacted your design so for example as I mentioned before a common when I see is and I ask this of all teams what are you

doing to store passwords what are you using and many times I'll see a company that's been around for 10 years or more and they tell me I'm using md5 I'm using sha-1 and and does anybody ever know that did anybody know actually nobody really knew that except for you know the people that are using it in developers and so on and so that again is a flaw in your design made some time ago and now you've got to think about well how does that impact my design and my application are my system today and so now we get into the actual process itself the threat mounting process itself and the way I like to do

this again I'm a software person and I focus a lot on software applications and design for secure systems but this is the way I followed it follows a lot of others that have said the same thing or the way they've done this essentially is understand your system you know what are you building what is that that's out there the threats and I like to use these questions and answers just ask questions probing questions at times and then determine the mitigations the countermeasures and the risks and then some kind of follow-through so don't just go through the exercise but actually you know have a follow up for it anybody you have a guess what this is

yeah sure it's a website anybody ever seen where these been handed one of these and say this is our system yeah the three layer tier three tiered layers great yeah how much do I know about the security of the system though one thing I do know it's got HTTPS that's all I need to know right I'm good oh that's true that's true very good so now I know a little bit more right now I know a little bit more about the security of the system now you know we have roams I may have more than that but well the reality is as I said you're not going to know much about this at all and

if somebody gives you this you know from a team and says hey this is our application that's not enough you need to understand a little bit more about the different decisions that are made inside the system the different business processes and how they're impacted by security or impacting security one way to do that and this is a method that's come out a number of years ago and and people still talk about the data flow diagrams but the reality is you can use whatever I don't really care if I'm working with a team and I ask so give me a diagram of something show me something go you know show me a firewall show me you know network

devices or whatever I don't care how you do it doesn't matter to me but show me something so that we can at least have a discussion about what's there and see how things move across the system and then we can ask some questions about it but this is one way especially for software applications you'll see is this data flow diagram and the idea being that the somin klaich err we use external entity represent a user or some kind of somebody using the system in some way a process or multi processes so let's say send email okay that's a process and how is that done datastore two lines some kind of straight line with an arrow of some sort porting where

the data flows through the system and then there's also this concept of a trust boundary which is an interesting thing it represents the idea that on one part of my system it's untrusted in another part of my system it's trusted maybe there's a authentication happening across the system maybe there's a some access control of some sort others can also have said that's kind of a a act so sorry attack surface it represents something that where you're more vulnerable for example you know what's your what's your attack service of a submarine well it's the outside right it's the whole but is that the only attack surface no there are many inside for example the captain's safe and so

you can identify many different places in your system where you're more vulnerable where you're exposing systems exposing through you know ports and so on and things like that and so this dotted line kind of helps you understand and identify some areas that are more sensitive than other places so as I said drawing this kind of stuff helps you understand a bits of your system and where the data is flowing so you get started you say okay let's let's start at a high level view is I've got users and I've got admins okay there was a couple users or interactors within our system entities if you will in our system I have a server that represents a lot of

processes that are happening inside and I've got data flow that's moving around in the system and some boundaries here as well that's a high level view ideally you want to move in a little further and so going back to that idea of the the web application more likely there's other things going on there's a lot of services that are being called there's a lot of databases or files and so on that may be involved inside the application and so you want to try to draw some of that and ideally when I'm working with a team I may even go a little further than this and I might say let's look at the authentication service there may be five

other things they're going on there and let's drill into that and see what's going on there and so on but at some point you start with a high level and then you drill a little further in and so once you start to draw your your diagram the next thing you want to do is label some of these things about what is happening you know there's a request going on here there's some audit data being saved to the from the audit service to the the database where the audit tables are and so on and those kinds of things may be happening and then you want to decide or determine where are some boundaries where are some

places that were more vulnerable or tax surface is more prominent and then you might also identify and numerate those kinds of things especially if you have a larger model where it continues to have a lot of things added to it and if you're diagramming this stuff you might have numbers that represent things and then on the side you might say okay this is these are the users these are this process and so on so you do that sort of thing as well and so at that point you know what we have there was just a diagram not much different than an architecture diagram that you might receive you know from a group great but it but it helps you at least to get

started it's not your threat model yet you know some people will say well I got a data flow diagram therefore I got a threat model know you've got a data flow diagram or you've got a some kind of representation of your system that's all you have next step is really to understand what the threats are which of course is the most important part of threat modeling it's also most difficult and many ways to do this one way as I mentioned earlier is the attack trees is to figure out a decision tree you know I want to get to something and how do I get there if I want to do a CSRF attack what needs to be in place in

order to get there and be able to execute it as an example you can look at some threat libraries to help you think about the kinds of threats that you might have in a system different checklists that are available out there you can also use use cases and misuse cases for example a use case would be as a user I want to be able to log into the system a misuse case as a user I should not be able to log in as an admin or should not be able to have access to admin pages if I'm not logged in I like to say that misuse cases really help you with this you ever heard that before if

you're you're mentioning a scenario and they come back and say well no one would ever do that right and who would ever do that and why would they ever do that nobody would ever think about doing that well that helps you in terms of again developing your threat model to understand what it's maybe possible and also what's plausible I mean those are there's some differences between the two do you know that possible and plausible possible that on Mars I might be attacked by a bear is it possible probably not you know there are not very many bears as far as I know on Mars if I go to Mars but there's a possibility there is one but

the plausibility of it is probably not likely and so it kind of helps you with that to think about you know what could happen and what's really likely to happen most well-known in threat modeling is this use this this mnemonic called stride that helps you think about threats essentially so spoofing pretending to be somebody else tampering is really dealing with data that's been modified in some way repudiation somebody claiming or claiming they haven't done something that they have or haven't done something information disclosure exposing that information denial of service of course affecting availability and an elevation of privilege which is the most dangerous one which is somebody being able to do things that they're not supposed to be

able to do and really the opposite of that is what we want you know that's what we're trying to deal with and when we're doing straw method is is to try to figure out the opposite things that are missing which are for spoofing authentication tampering we we need to have some integrity data integrity repudiation non repudiation or auditing and logging if you will information disclosure we want some confidentiality in place that may not be there then all the service of course availability we want elevation of privileges authorization or access control and if you've been in security a while hope you recognize these things or the CIA right the confidentiality integrity and availability the two A's

the authentication and authorization and then finally the non repudiation or somebody some people call it auditing so maybe three days there and so that's really what we're trying to help people understand and so when when you teach stride to somebody who may not know security very well what you're trying to do is help them understand the opposite of these things that might mean that I need to put these things in place to make sure that I've you know been able to deal with the threats another way is to use this pasta method which is combining stride attacks and a lot of risk analysis it's out there there's a good book on that the other thing I like

to do when I'm doing a threat model with a team is just ask a lot of functional questions around these kinds of things as well especially for example configuration management I asked questions about cryptography as I said I always ask about passwords and encryption and key management and how are they doing those things that are hidden really from the outside world you may not know that these things are happening but they're they're inside the secure design so I asked about those things I asked about for example going back to the attacker who would be interested in these things what kind of goals do they might have assets and so on that are that are available different

methods they might use and then also are there any attack surfaces anything that we missed as we're going through a threat model I asked about authentication between callers and services you know again authorization so I may ask so specifically cryptography and so on one of the best questions that I heard this yesterday I was at a couple days at a conference and this kept coming up but is there anything keeping you up at night and this person was giving a keynote and they kept saying these are the things that keep me up at night these are the things that keep me up at night so I kind of knew what what was keeping her up at night but you know that's an

interesting question to ask a team you know is there something that you're not telling us it's here something that we need to know about for example a back door that's in the system a test button that's still there you know a debug setting that you just didn't realize was there I remember working with a team and they told me that you know actually we have this way of testing our site that we keep live all the time because it's really easier to have it out there in production so that we can test all these things about our site but oh yeah that's right it's in production yeah well we don't have a link to it what do you mean

okay but it's still there I mean does it need to be there I mean really so that can impact your threat model as well here's an example I like to when I'm talking with teams that are their focus so much on micro services these days is this idea of the confused deputy problem everybody recognize this guy okay remember how with sometimes he would be somebody's in the jail cell and and hey can you help me out can you give me the key I need to go to the bathroom or something yeah sure here you go go ahead and then somehow another Barney gets locked in the jail right that happens quite often in the episodes well

the idea behind the confused deputy problem is that you have a lot of services that are out in the system and some that are doing one thing and anonymous essentially and then others that are more secure they at least they should be and they're doing more privileged operations and the idea being that if I can say a calls B call C and sees the the secure operation what's to prevent me from a calling C or you know making B do something that it shouldn't do and call D or something like that and so there's some interesting things about that and and we've seen this a few times and examples and the way to deal with

that is you know through acts permissions and capabilities and so forth but the idea is that there's some potential implied trust that's in the system that we may not realize this there and so it's something that comes up quite often talking about configuration management if we look back at my web dfd that I put together if you look at and think about where the configuration where's configuration happening for a website typically it's in data files config files of some sort what's contained in those files typically secrets passwords web services other kinds of things that they're calling right and so if I wanted to do a threat model against that I would ask or first of all you know identify you have

configuration files in your system and then I would review okay what are some security principles here be reluctant to trust assume secrets not safe and with that in mind and I asked some questions how does the app handle those files and do what do they do with those files because it's still data input you know we think a lot about the input that comes from the outside but we don't always think about the input that comes from the inside you know from our files and from our databases you know if you've heard of reflective or stored rather XSS right being able to store an XSS attack in the database and then simply pulling that data back into the

website and then and then acted on the website so it's all data input so how does it use those configuration files and what would happen if somebody changed something in those files you know change to point to a different database or change the password or change to point to a different service what would happen how do we know is there some kind of implied trust usually there is possible controls and mitigation kind of jumping ahead a little bit you'd set permissions on those configuration files we was changing them perhaps and then validate all the data that goes into those files to make sure that you know it's valid and so forth using tests fuzz testing and so on so

like I said a lot of different ways to identify threats and like I said I like to use these answers to questions and try to you know the probe and what's going on with your system once you've figured out the opposite of these things as I said spoofing you may say well well now we need to know or we need to put in some authentication and so on you have a few options what to do and these are pretty well known the four options leave it as is you found some problems leave it as is we know it's broken leave it it's okay remove it you know we know there's a problem here we're just going to remove

that particular feature so that it's not available yet until we fix it you can remedy with a countermeasure you can put something in place to deal with the issue that's ideal and then finally there's the warn user which I call the pass the buck method which is to give some kind of disclaimer and say look we know it's a problem use at your own risk if you go into a coffee shop with a Wi-Fi completely wide open there's again you might see sometimes a disclaimer that says by the way use at your own risk anybody can sniff the the connection that you're making out there in the world when you're using our free Wi-Fi so that's a warn user method so then you

want in trying to figure out you know where the risk associated with the vulnerabilities and threats that you found and sometimes you will kind of reverse you'll find the risk first of the threat to then determine the mitigation or maybe the other way around to define or to determine risk essentially you would apply some kind of risk management and I said very early on you want to think about how risk drives a lot of your threat modeling different ways to do this one is that's actually becoming more and more popular as to use the fair approach anybody heard of that okay a few certainly more prevalent nowadays in the financial industry I keep seeing it there but it's a very

analytical way of determining risks some other ways are cbss another way of scoring a risk rating and then Dredd is one that used to be around with Microsoft but they've dropped it lately where try to figure out risk that way the simplest way is really just high medium low and you'll see a lot of tools that use that it's not very complicated but it's definitely more subjective I mean really all you're doing there is you're trying to determine how easy is it to exploit this threat and then also the business impact as a result so the ease of exploitation high is if a lot of users can be able to do this thing and lo is if they need special skills the

business impact of a lot of users for example are impacted and your reputation and so on very high and versus low that not very many users and your reputation and so on is they may not be impacted to to a high degree you put those two together and you can come up with at least again subjectively somewhat but you know what does we feel as the risk here in in terms of our rating here's an example of a CSRF attack or threat and we say okay you know here's our the threat here the the description of it and some countermeasures some things as affecting we consider to be a medium and so that's again a threat model of that

particular situation going back to our configuration management issue you might think about the risk rating of this thing I like to say that you know if we own the box we're in control of it the risk may be actually more medium or low if we're not in control of that file in the configuration that we're setting I would say like for example on a cloud or some other service that we don't own we don't manage somebody else does that I would say the risk rating on this particular situation is higher because we need to make sure that we protect the data and and make sure we know who changes the configuration files and so on

and so that's a threat model right there of all the things we know about the system we know some principles we've asked some questions we have a denim a/b identify maybe some threats that could happen if somebody changes the file we've identified some mitigations and we've also determined the risk and that helps us drive what we're gonna do next do we put these kind of things in place or do we say it's okay we understand it's a risk but we'll live with it we're not gonna do anything more so that's another part of our threat model here finally the follow-through is documenting what you found filing bugs or requirements verifying they're fixed and then also if we miss anything review

again now what are you done with threat modeling never yeah you need to keep going you keep doing this you keep thinking anytime you add something new you need to review it again you need to look at your threat model it changes your threat model if you add a new library if you add new devices if you you expand ports or whatever your threat model has changed and you need to update it and keep it going and so what I like to say is that as you do that ultimately what you have is what I call this living threat model it's not something an exercise that you did one time and you're done but it's something that you

should be thinking about quite often and again as we said it the title of this is that threat modeling mindset this is something you need to be thinking about just like you do on a personal basis every day about your own systems you need to be thinking about these things and helping to integrate it within your own system your own company and with a lot of people not just the security people I think but also developers and others that should be understanding about these principles finally I want to leave this with you this is really an interesting article I saw last year that came out from John Lambert works at Microsoft but in particular he wrote

this article pointing to the fact that the security controls themselves actually can create vulnerability and why because it gives a clue to attackers what is important to you and so what he wrote in this article and I very much encourage you to go read it it's it's just pretty eye-opening especially having thought about some of these things because a lot of times we think about as security people we think about lists right we got a checklist and we add this control and we have that control attacker doesn't think that way an attacker thinks and graphs they're trying to figure out from point A to point B to Point C to figure out what's your system they don't know everything

in your system so they've got to graph it out and figure it out right well how are they going to do that well one way is to look at your controls to figure out what is important to you that you now have a control protecting it because it's important to you and so what he was saying in this article is that you know the selection of controls just saying I have a control is not enough now I need to understand what happens if somebody circumvents that control what's next where do they go next are you slowing them down are you monitoring them are you doing other things to think about how the threat model changes once that control has been

circumvented where do they go next what's next in the graph and so again just a interesting article interesting thoughts about this idea of recursive threat modeling not just doing this once but thinking it various levels and layers in our system about how does my threat model change now that that particular control has been circumvented where do they go next what could happen next what could go wrong and as he said you know controls come with risks and must be treated accordingly so again I encourage you to take a look at that article and other things that John Lambert has been writing about just really fascinating stuff about some things that he's thinking about and analyzing about what is going on with

attackers today so to wrap up you know your challenge pursue this threat modeling mindset don't just let it be something you heard about but actually something you continue to do secure design before new features also let it drive your testing I find that especially for testers for red teams for others threat modeling is absolutely a useful tool to think about the system and how can we now that we know a better threat model how can we then test accordingly to find out is this really true or do we have these particular vulnerabilities do we have these particular issues in our system that we may never even thought about and then also threat modeling is going to help

you with understanding the bigger picture and I it's why I like to to teach it and help others know about it is because I think there's some value in understanding the bigger picture and how things fit together lots of resources out there tools other tools and that's my contact info I have made slides available already they're available out there so if you're interested go ahead and pick those up my contact info I'm on Twitter I'm also on LinkedIn if you want to you know connect with me on LinkedIn just let me know that you you know saw the presentation at Abby sides and you know be happy to connect any questions yeah oh yeah absolutely absolutely sure well

I mean ideally you know to start slow you want to do you want to do an easy thing first you don't want to overwhelm but as your threat model matures as you get more information what I find is that kind of information can come in and help refine your threat model it can certainly help refine the risk you know how do I determine risk well I don't know what could happen here so how do I determine with that you know I don't know but your your information like that coming in from those teams and say you know this is what we are thinking this is what we're we know is happening or it could happen I think can help refine

your threat model another good thing I would mention is there are some work or is some work rather being done right now on some tools that allow you to take threat intelligence and plug it into your threat model so you can build a threat model and then allow some of that threat intelligence to come back and validate what threats we identified to say are they really true or not and so that's a really nice way of refining that kind of a completing the circle so that's another thing I've seen as well yes how does work come back and yeah sure there's a if you look up I'll tell you where it first came out at least I heard

about it was dev set con in Boston Kevin Green look up Kevin Green look up his particular keynote but he pointed to some tools that he's working on but essentially as I understand it they go out and look at your system and try to do at least a mapping of what you have and then you can refine it and then you plug in to you know any of the threat intelligence tools that are out there and get some data and then they try to map what they find oK you've identified this firewall or something and we've identified there's a lot of things that are coming against that firewall we've identified some things that are real

threats and others that are just you know negatives or whatever and then try to do that mapping now it's a work in progress you know I don't know all the details but that's what I understand for what he described how they're trying to to put it together and it should be interesting to see as they move along and that comes out yes the question yep sure right yeah mine doesn't include that but I have done that with teams in terms of thinking about deployment and what does that mean so I just draw a different kind of model or a different type of diagram I'll point to you that there is a I can't remember the NIST

number but there's a new NIST document out there on security of containers and they actually use what's called a data centric threat modeling process and then there's also another NIST a document that covers that as well and it's really interesting so they considered that containers are essentially data it's holding data it's holding assets and so I would I would follow some of that methodology in terms of maybe looking at assets looking at data is handled and and and go from there so that may be helpful to see how you could actually do a threat model against containers and deployment and so on yes to mess okay

there's some differences I mean like for example the fair approach some people do threat modeling through using fair basically because in that case in their situation a threat is considered to be anything I may have value that I can lose those saw like a numerical value associated with it so in that case for example if I determine that I have a $10,000 threat but it's a hundred thousand dollars to fix it well then I may not do it you know so everything has a dollar value so as I see it I think threat modeling and and risk management can complement each other but risk management usually is not focused on applications not focus focus on more you know if I do something what

happens as a result whereas threat modeling is more the system but you need to I think you need the two in order to help inform each other yes

quite a bit I mean how is it or how could it be or oh absolutely yeah absolutely and I do that all often I've worked in health care I worked in finance and I've worked with these different companies and teams to look for the things that make sense for their particular organization and for example I've used the microsoft threat modeling tool which you can customize for stencils that make sense in the finance that makes sense in the healthcare and use that and the same thing with if you're just drawing out things there are certain things that make more sense in that industry and that helps everybody get a hold of it too if that makes sense

so absolutely I think that's it we're gonna have lunch here in a moment so I'll be around for a little bit I'll be here after lunch for a little while but then I need to head out but if you have any questions feel free come I'm farming thank you [Applause]