Threat Modeling, Star Wars Edition

actually I think I'll just go ahead and get started how about that we'll start a little bit early maybe we'll get done early who knows so thanks everyone uh you know I'm Audrey thanks for attending my session threat modeling Star Wars edition so you know just a little bit about me um I work at Microsoft I'm a senior security software engineer I've got my master's degree from Johns Hopkins University in cyber security uh before that I got my undergrad in University of Cincinnati in computer science I like to do a whole bunch of really nerdy things so if you guys also you know like to play games Tinker actually 3D print and paint stuff you know talk to me we have a lot to say we have a lot to talk about all right so today we're gonna have our deep dive session today and the wonderful world of threat modeling so we will leave today's talk with New Perspectives and learnings and by the end of the session hopefully we will obtain a security mindset gain some threat modeling fundamentals walk through the steps to generate threat models and threat model the Death Star as well as gain some really fun nerdy security knowledge as well all right so before we kind of get into the the meat of the talk let's do a high level overview of what threat modeling is so threat modeling Works to identify communicate and understand threats and mitigations within the context of protecting something of value threat model is a structured representation of all the information that affects the security of an application or the system in essence it's a view of the system and its environment through the lens of security threat modeling can be applied to a wide range of things including software applications systems networks distributed systems Internet of Things devices your refrigerator and in this case we're going to do the threat threat modeling of the Death Star all right so who should be threat modeling so really anyone can threat model but what I typically see is software Engineers security Engineers Architects program and Technical program managers software testers basically if you have an understanding of how your system functions then you can make a threat model so when should we use threat modeling so threat modeling is best performed during design sessions and that's when it's really the easiest to make changes it's much less costly than adding mitigations and testing them after your solution has already been implemented using threat modeling whenever you design new systems or if you're updating existing ones can be really beneficial for you in the long run some examples of threat modeling includes creating like a new microservice or a new Cloud application designing a public API to provide customers access to your data adding a new feature to an existing application or completely creating some new kind of infrastructure project however the list really does go on it doesn't just stop there now what is a security mindset so security requires a particular mindset I'm sure everyone here at b-sides definitely knows what I'm talking about here good Security Professionals see the world differently we can't just walk into a store without noticing how to shoplift we can't use a computer without wondering about all the security vulnerabilities that lie within it we can't vote without thinking about hey how can we vote twice you know we just can't help it and this type of thinking is not natural for most people it's not natural for engineers good engineering involves thinking about how things can be made to work the security mindset involves thinking about how things can be made to fail it involves thinking like an attacker an adversary or a criminal however you'd like to classify that you don't have to exploit the vulnerabilities you find but if you see the world in that way that's the only way you'll ever find security problems and by adopting a security mindset you can emphasize the attacker their motive means in all the ways they can wreak havoc in your system this approach looks at all entry points and system weaknesses and allows you to focus on critical assets holding the highly confidential data for your system and when those weaknesses are discovered emphasis is placed on protecting those assets instead of the entire system or whatever your scope may be for a threat modeling exercise now I'm not going to go over a classical threat modeling perspective for you today however I think it's kind of interesting to see this is what a threat model looks like in the dod which is probably the most you know rigorous way to actually create threat models and I actually did a threat model on uh the uranium centrifuge systems you know stuxnet that's probably something that we've all heard of before and I can tell you that this is a very very long process however you know when we do threat modeling in Cloud applications or a lot of applications today we won't really go through a big long process like this instead we kind of look at threat modeling in a very small and comprehensive phase so this is the core algorithm for developing threat models within any kind of a commercial industry and with a condensed version of the classical model really anything can be pulled from the classical model to be thrown into the more condensed version it really just depends on your system your requirements and how thorough you really need to be when creating some of these threat models now let's go with over these phases one step at a time and then we'll apply those phases to threat model the Death Star so the first thing that we're going to do is we're going to analyze the existing system and this is really known as like the design phase the design phase is a starting ground for your threat modeling activities you'll gather as much data as possible about what you're building and how you can you know gather any kind of information about the system at hand so some of the high level goals when we're analyzing an existing system include developing a clear picture on how your system nominally functions you want to enumerate Services consumed in your system investigate environmental assumptions and security controls you want to gather some of those system design requirements in architectures and really want to identify some of the key stakeholders who you're going to be talking to now the second phase in the condensed threat modeling version is to design a data flow diagram so data flow diagram otherwise known as a DFD is a visual representation of how any process or system flow of information comes in and out of your system by mapping out your processes or system flow of data dfds help you better understand the processes of the system uncover its Kinks improve it and can even help Implement a new process or system some of the high-level goals when designing data flow diagrams include to understand the user and system scenarios establish trust zones and boundaries within your system identify user permissions used throughout the system life cycle and investigate protocols being used inside and outside of the system being designed here you can see some of the data flow diagram elements so these are pretty much a classic representation of anytime you make a DFD it's really common to use these these models in these designs because each interaction here is really there to help you analyze and identify potential threats and ways to reduce risk within your system using these shapes correctly also helps you receive better input from colleagues and security teams everyone will pretty much understand how the system works if you map it out correctly and it can help everyone avoid going through all the countless design documents and development plans to help them getting up and running the third phase is to identify threats this phase is where you use the data flow diagram to find potential threats against your system we will use a threat modeling framework to help find the most common threats and ways to protect against them a threat modeling framework is essentially a series of rules and guidance Associated around teasing out threats within a system or an environment threat modeling is a great technique to help you find issues early in the development life cycle and choosing the right focused approach helps you tailor to the threat modeling exercise you'll find more actionable threats and ways to solve against them so you can see I just kind of selected a handful of Yamin threat modeling Frameworks that I've used and are used commonly within our industry you know since I'm a microsofty I have to say we use stride and when we threat model the Death Star here later we're going to also be applying the stride framework to help find some kind of threats and identify some mitigation candidates against those so some high-level goals when you're actually trying to identify threats include to actually apply your security mindset we want to try to find any of those openings within our system choose whether or not you want to find ways to protect your system or if you want to understand all you can about an attacker and their motives use the data flow diagrams to find potential threats against your system apply the threat modeling Frameworks and identify system weaknesses here is another high level level overview of some common threat modeling Frameworks that I use a lot in the application security space with Cloud applications so here you can see the stride threat modeling framework you know o wasp top 10 is another really popular one and miter attack these Frameworks I use quite often however you know depending on your system these might not work for you so you can't just shoehorn everything into one specific threat modeling framework you need to be dynamic all right the next goal is to brainstorm those mitigation strategies this phase is where the fate of all threats is decided each threat modeling framework should map to security controls within your environment which often which offer different functions and types to choose from generally once mitigation candidates are created assigning a criticality or a weight to each of one to determine which mitigations need to be implemented right away and also to decide what the complexity and time to fix each mitigation candidate some of the high-level goals when brainstorming against mitigation strategies include measuring each threat against a prioritization framework or a security bug bar track each threat as a task or a work item in a backlog generate security control recommendations that are mapped to threat modeling Frameworks and select one or more security control types and functions to address each threat ensuring we map an accurate framework is pretty you know it's it's probably one of the the high level things that you need to do in when regarding creating some of those mitigation strategies here you can see how you can map stride with your dfds and I I follow this map pretty closely and I feel like it helps me Identify some of those best medications depending on what kind of applications I'm looking at yeah all right and last but not least you want to continuously iterate and verify this is the last step of the threat mulling process which often happens before the system is deployed we all know that's not true this is like the best case scenario a lot of the times people actually have to go back and threat model existing systems however always ensuring that you're continuously iterating and continuously verifying your dfds your threat maps and any other kind of architecture that comes hand in hand with creating threat models is really important um so you know some of the high level goals here are to confirm all previous and new security requirements are satisfied for the system configure Cloud providers operating systems and components to meet security requirements ensure all issues are addressed with the right security controls and take the system through manual and automated verification before deployment now you can threat model anything so you know I know you guys are all here for this session because we are going to Deep dive into threat modeling the Death Star and we're going to use all the phases that we just discussed and show you how we can actually map that together so step one was to analyze the existing system according to the U.S government and no really the U.S government actually did this the first Death Star would have cost at least 852 quadrillion US dollars to construct the Death Star took 20 years to build and because of its sheer size and complexity that takes a lot of time and money and as we all know working in big companies it's also a lot of time and a lot of money and we need to make sure that what we're building is secure and the Death Star you know as we know is a very complex piece of Machinery which contains very intricate Services which rely on each other to achieve total Destruction and induce fear throughout the Galaxy the Death Star main purpose is to function as a mobile platform for its main weapon the superlaser the Death Star structure is basically an enormous housing for the superlaser in the reactor that empowers it at a high level the Death Star is made of four major components the battle station the super laser the propulsion system and the hyper matter reactor that powers it all so just a really high level overview you know the battle station that's where we're going to input our commands to move or do anything with the Death Star itself the super laser is a massive lens built around a huge synthetic focusing Crystal obviously and is surrounded by eight tributary lasers the propulsion system is the death Star's real space propulsion system and it's made of a network of ion engines that converts and transforms reactors to power that into thrust the engine thrusters are primarily lined along the Equator of the station and last but not least the hyper matter reactor the greatest challenge in designing a death star was not creating a cannon big enough to fire a beam that can destroy a planet nor was it creating a battle station the size of a small Moon the greatest challenge was always powering a cannon big enough to fire a beam that could destroy a planet and moving a battle station the size of a small Moon now the next step is to actually design a data flow diagram as you can see here I I did this one by hand and it's really fun to kind of see all of the different research that had to go into what needed to what commands needed to go in to actually do any kind of functionality within the Death Star so a lot of these are actually used in this command station computer so a lot of the the times the Imperial you know I'm sorry it's too funny an imperial user has to actually input a command into this computer to either you know re reform the laser point it to a planet that you would like to destroy to put up the defensive Shields to move the battle station to make sure that our you know our lasers are you know functional and to make sure that that tractor beam is really up and operational now now that we have our dataflow diagram let's just kind of at a really high level this is my kind of quick and dirty attack tree and you know at a high level an attack tree really goes through all the scenarios that an attacker is going to go through to actually reach their goal of compromising something within the system so here you know I've been using the stride framework to see some of the possible threats that actually live within the Death Star and some of them you know include disabling the ion Canon systems we can you know tamper with the tractor beam only if you're a Jedi you can mind control people to really get into that battle station computer but also jamming Communications you know sending signals there's a lot you can actually do here and as we all know if we have all watched Star Wars movies you know the Security's not that great so they should have had someone threat model this thing a long time ago all right now let's actually kind of go through some of those mitigation strategies from those identified threats so here let's talk about a vulnerability a vulnerability is any system weakness in a system process or other entity that could lead to a security being compromised by a threat a threat really is any action that can disrupt harm destroy or otherwise affect an information system so here let's talk about the vulnerability of the thermal exhaust Port this action is exploitation and exploit means to take advantage of a vulnerability as we said in this example Luke Skywalker exploiting the thermal exhaust vent by launching Torpedoes into the vent impacting the core and triggering a catastrophic explosion is you know as we saw how the first Death Star came down a possible mitigation against this though could be to eliminate the two meter wide thermal exhaust port or Safeguard this exhaust vent with extra defenses perimeters maybe even you know a few types of layered approaches so that you can't you don't have just one gaping hole of a vulnerability right there in the Death Star now let's actually apply the stride framework so we're going to go through this in the stride fashion s stands for spoofing and this is like kind of fun um but spoofing you know it's an authentication property spoofing threats involve you know an adversary creating and exploiting or exploiting confusion about who is talking to whom so in this example you know impersonating Stormtroopers to hijack communication systems and save princesses as done by Han Solo and Luke Skywalker and let's face it pretty much every Star Wars movie you'll see someone impersonating someone some mitigations though against spoofing could be to authenticate principles such as users or machines by enabling more robust and multiple identity mechanisms such as MFA now T stands for tampering and this is a property of Integrity tampering threats involve an adversary modifying data usually as it flows across a network in memory on disk or in databases in this example Obi-Wan Kenobi tampering with the tractor beam system to allow the Millennium Falcon to to fly to safety this is that example a potential mitigation could include adding validation such as credentials codes and safeguards cameras guards you know limited limiting the access to this Machinery could potentially mitigate against tampering the next one is repudiation where this property is non-repudiation and you know repudiation threats they involve an adversary denying that something happened or claiming to not have performed an action so in this example Han Solo saying there's a very dangerous reactor meltdown happening an attempt to Stage a Divergence to save the princess a possible mitigation for this could include in Sharing proper observability is in place to track down adversarial behaviors and you know logging some of those behaviors the next one is uh I for information disclosure and this is the property of confidentiality so this is exposing information to someone that is not authorized to see it in this example you know jyn urso from our favorite movie Rogue one relying you know critical Death Star vulnerability information to the Rebel Alliance to get that information on the vulnerabilities that lie within the Death Star a potential mitigation against this could be a thorough understanding of your asset inventory and public exposure are also you know highly important to help with mitigating against a threat like this d stands for denial of service and this property is availability so to to deny or degrade services to users in our example Chewie is jamming transmission channels for a TIE fighter and possible mitigation can include ensuring communication channels are encrypted and only verified users can access these channels also practicing redundancy such as backup Channel availability and last but not least e is for escalation of privileges so this is a property type of authorization