BSidesSF 2023 - FAIR STRIDE - Building Business Relevant Threat Models (Arthur Loris)

so thank you all for coming uh I can't tell you how happy I am to be speaking here this is my favorite conference so to be able to just be standing here is awesome uh my name is Arthur I manage one of the appsec teams at Ping Identity and here I'm here today to tell you all about Fair stride which is a framework louder closer to the mic all right so I'm here today to tell you all about Fair stride which is a framework we developed uh to um to have engineering threats and the business be able to speak Apples to Apples when threat modeling uh so just an agenda slide uh I'm going to talk a little bit about the background of uh how I got to this material and then I'll talk about the components that came into building this thing first I'll talk about stride and how we threat model with it then I'll talk about uh quantitative methods and fair and Monte Carlo simulations and uh why they matter and how they differ from how we do things typically in engineering and then I'll give a little demo so you guys have some uh some sort of tactical stuff to go home with and uh then we'll close it up uh so back in 2019 I was at rmisc which is a conference out in Colorado which is where I live um the keynote was Miko hipponen who's the head of research for f-secure he uh he had uh during his keynote on the the state of the net uh slide that was massive that had uh tires perpetually burning and he said in security when we do our jobs right nothing happens um that was very disheartening I'd just gotten promoted to management and um you know my job is to make my team successful and to align the the success of the individuals on the team with the the interests of the business and so to hear that the best that I could do is nothing was a problem that I couldn't ignore we tried a lot of things during that year as far as measuring our success but nothing really seemed to to hit the mark for me um until about a year later when I came to this very conference before the world shut down and uh Clint gave a uh his keynote on how to 10x your security without the series d uh the general thesis of the talk is if you're able to remove bug classes from your code base then you gain time and you move the needle measurably as far as the risk posture of your applications uh he centered this around two main use cases uh the first one was Secure by default Frameworks and the second one was semgap rules to make sure that your code doesn't reintroduce vulnerabilities now this was really encouraging because uh for the first time I was like oh we could actually actually have a path upwards from where we are now but then I came to another realization which is I don't know what the hell risk is I don't know how to measure it I don't know how to perceive it I don't really know anything about it apart from some people talk about it and apparently bad things happen one risk is involved occasionally uh so I picked up this book called how to measure anything in cyber security risk which is absolutely phenomenal it's very complete it has a lot of resources that have to do with quantitative methods to be able to evaluate and use risk in your Enterprise a lot of what they talk about and how they um how they position things in that book is very much from a CSO View and what we're going to do today is we're going to bring that down to the appsec level so it's really just a re-scoping of all the techniques that are that are in that book I got the audiobook it was like nine bucks so if you got nine bucks you should get that uh the last thing that I had to put up here uh is the the fair you uh risk lens Tool uh I'm not sponsored by them or anything like that uh but it is really awesome and very easy to use uh and you can get kind of a very elegant view of how far works and how quantitative methods work uh with like a very small amount of effort relative to reading that whole book so if you want to give it a shot give it a shot it's awesome all right so what are we doing today as far as modeling threats um there are many approaches to uh to threat modeling but today I'm going to talk about stride so stride was invented at Microsoft in the early 2000s as a part of their secure Computing initiatives uh there are as I mentioned other methods more artistic than others to be able to to model threats but stride is really good because it's a repeatable framework and if you're going to train a team of more than say two or three people it's really good to have a way to go about training them and if you have developers that are interested in uh in security and in threat modeling and you can give them a framework again it's better for for being able to share that knowledge uh it's not rocket science but it is awesome uh what you do is uh you build a data flow diagram of your application you draw trust boundaries and processes and data stores and arrows that show how the data goes from A to B to C and then you enumerate threats that fit in the stride buckets so the stride buckets follow that acronym it's spoofing tampering repudiation information disclosure denial of service and elevation of privilege is great right we actually have a systematic way to go about seeing what might go wrong with our application even if it's not implemented yet the output from this is a list of uh things that could go wrong or a risk registry and then we have to prioritize how we fix things do you guys hear those uh bumps in the thing uh so we have to prioritize how we fix things after we've already enumerated them and as far as I can tell in the industry we follow some some modification or some version of CVSs score calculators so you find a threat you go to the nist website you say the attack Vector is the network and the impact to confidentiality is low and then you know you click a bunch of buttons and that creates a score from 0 to 10 of uh on the CVSs scale uh that 0 to 10 then gets mapped to a high medium or low depending on what bracket you fall into so this is pretty good right but it's not very sophisticated and I mean that from a mathematical perspective so a high medium low critical informational those are what's called ordinal scales which means that they're very good at putting things Jesus Christ what is this I put it down okay okay sounds good um so high medium low critical informational those are all um those are those are an ordinal scale which means that they're very good at putting things in order so a high is higher than a medium and a medium is higher than a low but they're not very good at combining elements in each one of these buckets so you can't compare five mediums to a high and you can't compare a thousand lows to a high either neither can you compare the mediums with one another so your your security expertise might say hey this one is more important than that one but that's not a product of the scale that you're using uh to drive that point home uh Bishop Fox put out this uh this e-book called uh the wolf in sheep's clothing uh which is really fantastic um the this is basically a recollection of a whole bunch of uh nasty things that their uh Consultants did uh with a bunch of lows so from an offensive perspective and a technical perspective uh you can combine a bunch of lows in the the kill chain but when we look at it from a risk perspective and a risk registry on the on the defensive side we don't combine them so just from that perspective we're starting already on the back foot so how can we do better um today I'm going to propose that we do things better by looking at the impact of vulnerabilities on the business rather than on the applications themselves so uh if we think about how uh you know an appsec program is built you have a whole bunch of things that generate findings you got tools you got pen testers you have bug Bounty programs you got your internal developers that find things that are weird you got your security team that's going and trying to break stuff and all those things kind of funnel into your security team uh your appsec team can then go and say all right uh these four don't worry about them we know about a compensating control move them aside and then these two we should actually send them over to the to the remediation team and so then that gets passed over to the remediation team they go and spend some time which costs money uh to be able to uh to go fix the thing uh depending on uh you know your setup and your sdlc you might have some QA cycles that have to uh that have to that you have to go through you might have some uh some release uh you know documentation cycles that you have to you have to go through there and all these things cost people hours which cost money um you might also have to notify your customers right if something is really bad and you have to tell them you have to set up a campaign and you have to go and uh work with people throughout your business and take their time away from their job to be able to go and fix the the thing that you found and then you also have uh people escalating up to your support team and your customer success team saying hey this thing is broken can you please help me be reassured about my posture so all this to say we're going to look at it from a process perspective rather than a RC against uh your application perspective uh just a quick note about Fair uh fair is super elegant uh it's a way to break down risk um in in a way that's specific to infosec um I mentioned before that this is very much at the CSO View and we're going to scope this down to the uh to the application View uh if you Google for fair you're going to find this uh this tree I added a dotted line in the middle there because I just wanted to make a point that um if you need to break things down further in the tree you can go ahead and do that but it's not necessary so you don't have to make your way all the way down to contact frequency you could just stop at loss event frequency if you if it makes sense for the way that you're estimating things and I'm going to walk through each one of these here in a sec so let's talk about lost magnitude uh loss magnitude is the amount of money that is going to cost when something goes wrong or when a loss event occurs um this is always expressed as a 90 confidence interval now what that means is that the accuracy of your estimation is going to come from uh the the the percentage of your confidence meaning that if you create a 90 confidence interval you want to be 90 sure that there will be that the value that will occur over the next 12 months will be in that interval versus trying to be as precise as possible with your interval and making it as tight as possible so that your your um you can get the sort of the best idea of what your value is actually going to be so as an example if I'm going to estimate the price of a gallon of gas in San Francisco in 12 months I could say oh it's going to be 550. but I'm going to be wrong a lot of the times sometimes it's going to be six bucks sometimes it's or it might be uh 450 it might be five dollars but if I say it's going to be in the neighborhood or I'm 90 sure that it's going to be anywhere from 350 to seven dollars pending any kind of geopolitical issues or pandemics or anything like that I actually have a good range where I'm confident uh that I'm 90 confident that it'll fall in that value and we allow for five percent outliers on the top and on the bottom side of that estimation foreign magnitude is broken down into primary and secondary losses primary losses are losses that happen every time that a loss event occurs and they're usually inflicted by the business upon itself secondary losses are losses that are usually inflicted on the business by a third party and that they do not occur every time a loss event occurs a lot of what we're going to see today as far as primary losses go are going to be security engineering Cycles because all the findings will make their way into the security team to be triaged but not all of them will will have to pay a bounty for or not all of them will have to trigger engineering Cycles to go fix things on the other side we have a loss event frequency so loss of infrequency is the probability that something bad that will cause a loss will occur within the next 12 months and we're going to use 12 months here because uh scoping the time of your probability is very very important in in the way that you get the Strategic insights out of this modeling as well as the actual probability that you're going to get so the probability that your company is going to get owned tomorrow is very very close to zero but the probability that your company is going to get owned in the next 15 years is very close to 100. so scoping this appropriately is going to give you um is going to give you a different number as I mentioned we're going to be using 12 months here and I'll talk a little bit more about why that is as we go through loss event frequency is broken down into threat event frequency and vulnerability so threat event frequencies the frequency with which you perceive a threat from an external actor so this could be seeing a cross-site scripting payload and vulnerability is the com is the the conversion of that into a loss event vulnerability is uh broken down and actually vulnerability is defined differently in in Fair than it is inside of the usual security engineering community uh here vulnerability is not a security bug it is the relationship between the strength of your controls and the strength of your adversaries and the strength of their attacks so vulnerability will tell us if the threat event has been converted into a loss event vulnerability is actually a quite complicated uh area of Affair that can warrant a talk and you know by itself but suffice it to say that you can think of this as uh the strength of a Dam versus a hurricane or the strength of your DDOS protection against a bunch of traffic uh threat event frequency is broken down into contact frequency and probability of action contact frequencies the frequency with which a threat actor makes contact with your asset so this can be some Recon building out a site map etc etc and then when that cross-site scripting payload gets delivered that gets converted into a threat event and so the probability of action is the probability of that occurring so what do we do with with all this stuff we we've estimated a bunch of things uh what do we actually do with it we're going to feed all this stuff into a Monte Carlo simulation so Monte Carlo simulations were invented by John Von Neumann and stanisla ulam at the Manhattan Project they needed a way to educate their decision making so that you know based on their understanding and with a complete lack of historical data they wouldn't make any kind of egregious mistakes when you know building the dangerous things that they built in the Manhattan Project um it's uh they called it everything had to had a had to have a code name and they called it Monte Carlo simulations after the casino Apparently one of the researchers had uh some an uncle that had some gambling problems and they said they figured they could use it afterwards to figure out how much money he might have to borrow from the family um the general idea of the Monte Carlo simulation is that we're going to take our uncertainty about our position through the the estimations that I talked about before and we're going to generate for all intents and purposes historical data so Computing has existed for you know Linux time started in 1970 the security industry is maybe 30 years old with these methods we can generate a thousand years of data 10 000 years of data and then use that data to analyze uh or that we can then analyze that data as if it was historical and then as we make changes the data is going to change and our analysis is going to change so these simulations are always taking the form of picking points on probability distributions for today we're only going to be talking about log normal distributions to model the dollars lost for each one of the loss types that we're going to enumerate log normal distributions are suitable for this because they have no negative values which means you're not going to lose negative dollars which is good and they also have very long tails which means that they'll pick up outlier events on the top side um and pay no attention to the numbers on the scale they mean absolutely nothing um just as an example uh these are the the black curve could be for example the the model of your um your bug Bounty payouts the blue curve might be your engineering cycles and the red curve might be for PR campaigns they all look a little bit different but they share those same uh properties and the reason they look different is because the inputs to these curves are the estimations that we had as far as lost magnitude and also when I do the demo I'll show you uh exactly what this means so what's the tldr uh for if you want to do Fair stride the tldr is that you're going to model threats with stride you're going to feed the output from your threat model into a Monte Carlo simulation rather than a set of CVSs score calculators and then you're going to use los exceedance curves which are the output from the model to define a baseline a goal post and to measure your progress from where you're at to where you want to be and you'll I'll show you what exactly what Allah succeedings curve is in the demo foreign so we're going to do a quick demo here I'm going to show you a big spreadsheet it's going to look really gross but I'll walk you through it um it's not again it's not rocket science none of the data that I'm going to show you or the threats or anything like that are pertinent to uh to Ping Identity everything is completely uh completely fake um just to prove a point here and this is you know credit where credit is due this is um basically the one for one substitution model that Hubbard and searson make available for free on how to measureanything.com cyber security so if you want to use the actual simulation here you can go and download it there for free or you can hit me up after this talk and I can give you this version of it all right bear with me here when I do the display thing that's not right it's gross isn't it um can you all read this or do you need me to zoom in more it's good all right um so you'll see here on the left uh these merge cells these are the different threats that we've enumerated during uh during threat modeling so you'll see here we have S1 for spoofing one uh we got some tampering down here we got some repudiation some information disclosure we got some denial of service and we got some elevation of privilege now instead of having the output of this be a high medium or a low we actually have a list of things that can go wrong also known as loss types so these are all things that can cost money and that don't always cost money I mentioned earlier primary and secondary losses they have um you know secondary losses have a probability of occurring that is not a hundred percent primary losses will occur every time so you'll see here the the primary losses that we have are essentially just security engineering Cycles now you'll note here that uh that it doesn't say a hundred percent that says twenty percent um that is the probability of the event occurring over the next 12 months now the 20 here is just making a point so if for example you're implementing best practices and you have um let's say you you have TLS uh implemented everywhere which is pretty standard these days and somebody uh is starting to to move data uh confidential data in transit through that um you know if you were to go to your engineering team and say what are we going to do to make that better they're going to say we're already doing the best thing you know please go away and do something else but that doesn't mean that best practice today won't be best practice tomor