BSides Vancouver 2015 - Bob Fruth - Threat Modeling in the Age of Connectivity to Everything

all right uh we're going to introduce our next speaker bob ruth he's actually spoken at besides last year as well and it was a really well received i really liked it so this uh this year he's going to be talking about threat modeling in the age of connecting to everything which is incredibly relevant considering everything that we know of and love is getting an ip address so let's give a warm welcome to bob fruth thank you alex so before i launch into slides i have a question how many of you created a threat model okay for those of you who have you may get some review from those of you who haven't this might be new material

so i'm bob fruth i'm a security privacy program manager i'll note that the opinions you're hearing from me today are mine and not indicative of current future or former employers or clients we'll talk a bit about why you threat model cover some basics of and data basics of threat modeling and data flow diagrams talk about identifying threats and proposing mitigations and then i actually did a kind of a high level threat model on a car because that's what really piqued my interest that led to this talk so who am i i've been at microsoft a long time before microsoft i worked at several different companies down in silicon valley a bunch of market leading products if any of you have heard of

harvard graphics i was on that team that's a long time ago now i've done a bunch of stuff at microsoft you can read so i won't bore you with telling you about it but i will say that the threat modeling bug bit me over 10 years ago and my family watches me carefully going through airport security to make sure i'm not threat modeling it as i go through it so why should you threat model well threat models find serious problems if you ship a security design bug and it impacts your customers you have a problem you've got direct and indirect costs there's the cost of response once we just heard from the sponsor about some

of that cost of response you've got product and brand reputation and that's huge especially in the state of the internet where you do you make a faux pas the world knows about it even people who have no idea what your company does or your product does or your service does they will know that it had an issue you've got cost to customers and customers get really ornery if if your product or service costs them money other than what they're thinking that they have to pay you so again a lot of indirect and direct costs one of the goals of threat modeling is designed products and services that are secure by design so you want to understand what things

you're exposing what your attack surface is what interfaces or what have you that attackers can get to you want to understand where you've got levels of trust and more importantly boundaries between levels of trust and we'll talk about this in a little more detail in a bit the other thing and i will reference robert's talk yesterday attackers think strategically they only have to find one flaw you have to find all of them and all of us when we work on a product or service we have creator blindness our baby is the most beautiful thing ever attackers don't care how pretty your baby is they want to find the ugly bits so you've got to overcome creator

blindness and get some new perspective and threat modeling can help you do that and finally it allows engineers to find and effectively find security problems early in the process goals and threat modeling you want to describe product security in a structured way i've mentioned documenting attack services security relevant features that's kind of important to understand potential threats against resources what those resources are what assets you're protecting what mitigations you can apply against those threats and ultimately threat modeling is kind of like insurance it's a risk proposition you threat models you understand risk and then you can assess that risk and say okay this is what we need or need to do or not do in response

to it so when should you threat model i claim you should do it early if you find a design flaw at design time you can fix it right then many vulnerabilities are built in during design time and i've heard fifty percent seventy percent large high percentages on an ongoing basis if you threat model early especially you can revisit your security maintain your threat models you maintain your specs or your api documents or you can threat model late higher cost to fix more disruptive to your release cycle or you can release with known vulnerabilities that's a real great story for your customers and i'll note that some vulnerabilities cannot be patched the industry as a whole has struggled

with how to release patches for firmware for example the example i've got a little later very difficult to patch although there is one one way to do it you'll see it when we get to it and you can defer your design changes to next release then some attacker finds your design flaw exploits it and your customers are sending you email making phone calls and worse yet abandoning you for your competitor so i have a question are automatic tellers secure there's one outside in the lobby out in the bar there so the late barnaby jack hacked an atm network on stage at black hatton 2010. that's four and a half years ago i still love this example

i'm sparing you the video off of youtube you can find it go to youtube search for barnaby jack you'll see it here's a picture those are million dollar bills on the floor they have his his image on him he hacked the atms a blackhead audience which is fairly staid clapped and cheered they had loopy music playing in the background which is kind of cool too it is vegas all the slot machines make loopy music so what's wrong with an atm the money is in a safe it should be safe right well the computer that controls the spinning out of the money may or may not be in a safe okay the connectivity to the atm itself is

not in a safe otherwise it would not be connectivity so kind of by design uh in the case of many of atms especially standalone models the key to get inside the atm is the same the atm companies figure well i've got some guy servicing three thousand atms or whatever number they service they wanna juggle three thousand keys we'll give them one the passcode is not changed on a regular basis or not changed at all you can find the defaults on the internet and the particular flaw that barnaby used to update the firmware was what was very simple the firmware update process was based on bad crypto i don't know exactly what algorithm was involved it hopefully was something as

recent as md5 but who knows barnaby found that anybody could install their own atm software if they could get to that connectivity a threat model could have saved them i can see this threat model in my head i could see it back when i first saw the video of barnaby and saw him at a subsequent event demoing the same demo so what else can you threat model simple web apps okay that's kind of vanilla at this at this point apps on your devices we all have phones we all have smartphones we all have apps on them complex systems internet retailers front ends back ends both together large search engines i happen to think about that one fairly

constantly your child's doll this is kayla it's marketed in the uk bbc news late last year talking doll kayla is hacked what did she say she as a parent do you really want to have your children's doll saying things that probably aren't appropriate for your son or daughter or your car this is what peaked my interest a general motors ad that was talking about wi-fi hotspots in your vehicle gee driving down the street surfing the internet um or maybe your passengers are because if you're driving you probably shouldn't be yeah um we'll we'll get to this but and this actually i saw the ad in the united states but this is from the canadian general motors

website all right let's talk about some threat modeling basics threat models are effective when there's a network involved or the web multiple user contacts or privileges are present so for instance if you have administrative mode versus non-administrative mode or guest versus system or what have you multiple processes sharing information and i would claim that most anything that is at all interesting has multiple processes involved layered architectures at a historical point the threat models originated into three tier client server enterprise applications in this day and age those applications are pretty well understood the threat model can be described relatively simply but we've gone beyond that you need to remember what it is you're protecting secrets those are kind of important customer

data gee financial data medical data that's kind of really important because there's all kinds of things like legal ramifications and regulatory ramifications especially with medical or financial data yeah let's lose our customers credit cards we all know about all the well-known hacks and breaches where that has happened child's privacy child safety controls when i look at that kayla doll i'm immediately thinking okay if a parent what what does what control does that doll give the parent the responsiveness responsiveness of a car to the driver that's kind of important in the in the car example so i've talked about this already what you can find by throughout modeling design problems which you can correct early preferably before you get too deep

into coding you can quantify and qualify your attack surface figure out what your risky areas are what your not so risky areas are robert and his talk yesterday have talked about aspects of the threat model where you choose not to mitigate you have to know what those aspects are in order to make that decision you have to you have to figure out what inputs you're taking from either the web or from a user or from administrator and i claim that if it's coming from anywhere outside of the system you assume it is evil you hate calling your users and your customers evil but you have to figure that their data might be and finally early awareness of

implementation gotchas in the web space knowing that you have a sql backend is a really useful thing to know so you can mitigate against sql injection you need to set expectations when you create a threat model figure out what you can't protect against can you protect against evil administrators i've always claimed that an evil administrator is not a technical problem it is a management and human resources problem but it's still something that we should mitigate against as much as we can what about physical possession you know the the one of the immutable laws of security is if somebody has your device it's no longer your device now we're moving into the realm of bitlocker and trusted modules and so

forth that particular particular rule is quite not as not it's not as strong as it was you need to know what you're dependent on you may not may or may not be able to control how you use it but you need to know what it is and understand the properties you know openssl is a fine library if you depend on openssl it's good to know that you're doing that you're making that dependency because when openssl gets broken you can take appropriate action finally part of doing a threat model is listing your assumptions and then you go back and validate them so data flow diagrams efficiently represent something a system a component an app a feature a car a

doll a web app a phone app the smartphone itself you include processes data flows data stores and trust boundaries and we'll talk about each of these in a little bit you can create a data flow for every scenario you can do it per system per component it's pretty flexible in that way i've talked about assumptions and dependencies already here are your basic elements processes do things two things the part of a car that controls braking is a process the web browser is a process you can claim that the operating system underneath the web browser is a process as well although you quickly would disseminate into a whole pile of processes you have users and external entities

these are these are things outside the system that impact it or that are served by the system users being the classic example you have data stores which can be anything from files to registries to databases to what have you and then you have data flowing through all of these things

in throughout modeling we use dashed lines to indicate location of trust boundaries and diagrams you can also use them to indicate process boundaries system boundaries etc the the key here is i'm talking specifically truss boundaries the key is that the trust boundary marks where you've got a trust difference or where there is a trust decision that is made as the data flows across that boundary data originating outside the boundary is untrusted if you have data that you originate inside the trust boundary and traverse it outside it's no longer trusted because it's gone outside your trust boundary the question you ask with trust boundaries is what interfaces are you exposing

so you add your trust boundaries to your diagram we'll talk about diagrams and actually look at a diagram in a moment you evaluate your users and external processes you don't trust users do you trust administrators that's a question that's a risk question how much do you trust external processes in some regards if you're writing an app for the iphone or the android phone or the windows phone or the blackberry you have to trust that those platforms do the do what you expect them to do we've talked about where data comes from you have to figure out whether you trust it or not the key point of this slide is that trust is relative you're moving data from one trust level

to another it's a relational thing

so here's a diagram of a simple web server i'm almost embarrassed to to display this because it's so bloody simple you've got the browser on the left it talks to the web server back and forth you assume that to the that there is a user using that browser traversing the internet making authentication authorization claims and calls and decisions and so forth on the back end the web server talks to an administrator now the administrator probably is assumed to be in the same environment as the web server you'll notice there's another trust boundary there where there's some authentication and authorization step that is done that administrator is logging into the web server into whatever management console

it provides and there's some way of authenticating with that and some way of being authorized for it at least you hope so if you're writing if you're actually deploying this in your environment

so with dataflow diagrams you do multiple levels you start off with a context diagram the previous slide was an example of a context diagram very high level your processes represented by or your target system represented by a single process bubble or circle or what have you it describes the overall system you then move to level zero and i have an example of these later on in the talk showing major subsystems and then you go on down to level one level two level three level n what have you showing the components of each of those processes or the process that you're threat modeling moving on down often you'll find that the context diagram and the level z

zero diagram are one and the same and that's fine the key here is to be accurate and complete not to draw lots of pretty pictures needlessly so how many levels do you need well you always need to create at least one diagram otherwise why bother level one diagrams are good for creating you know to model complex subsystems you need to use enough levels to understand those subsystems and the risks if you get to a point where say you're doing a complex system you're down at level five and you get to a diagram where you've got a subsystem with no trust boundaries you're done a diagram with no trust boundaries is kind of boring because there's nothing

to talk about there if you understand the risks you've gone deep enough and there's no real real rule i can give you other about when you say i understand the risk well enough except to kind of as you work through the throat model you got to appointments like okay here are a bunch of risks articulated here's some vulnerabilities here's some mitigations i think we're we're done and then you have somebody else look at your work and ask asking them whether they think you're done some basic rules between with external entities traditionally data flow between external entities was outside the scope of diagrams so for instance you never assumed when you're modeling a you know a complex client server

application that the end user and administrator actually ever talked now external entities can only talk to processes because ultimately the entity does something to data by a process to some regard the rules for external entities have changed somewhat with the internet of things you need to consider data flow between external entities when you threat model something this internet of things so that that that rule has changed flows are unidirectional data flows from one point a to point b or from process a to process b or from process b to data store c or from process b to end user bob they don't flow the other way there's a separate data flow that flows back some basic rules on processes a process

without input is a miracle it how did it actually make data from nothing a process without output is a black hole gee let's send data to this process and drop it it's like why bother the sending the data at that point the process does something with it it stores it somewhere it displays it to somebody it munches it and sends it back that's a great question and actually repeat that question when i pulled the demo up in about 20 minutes because there is a part in the diagram where i have exact i violate that rule completely a good question the question is um what happens if you you have a process that just ends for later functionality

some basic rules with data stores data stores don't move data data stores get data written to them and they write and they provide it for reading processes get and put data and i've already talked about end users and external entities don't access data stores directly even if you think of the manual process of taking a piece of paper and putting it into a filing cabinet you are the end user you are the external entity the filing cabinets the data store but the act of putting the paper in the filing cabinet is the process although how many of us haven't have filing cabinets anymore some common problems if you have too many processes in your diagram you're

probably drawing level two detail in a level one diagram you'll know if you can't look at a diagram and kind of see the whole thing you probably have gotten too far down in the weeds if you've got overly complex data flows this picture here for example probably indicates may indicate a fundamental design problem or may indicate that you need to move up a level and do the previous level diagram first if you cannot doc document your product or service with a data flow diagram it would be very difficult to threat model and it will be very difficult to secure so in summary data flow diagrams are an effective modeling tool trust boundaries highlight relationships between things

data flow diagrams make your team think through what it is they're designing the technique has proven very valuable in understanding attack surface so let's identify some threats and talk about vulnerabilities and mitigations the process is a nutshell you have a vision of what you're building you you start to design it you create your diagram you identify threats you mitigate you validate the mitigations and you rinse and repeat next release cycle mitigation is the point of threat modeling you address or alleviate problems you protect your customers and their data you want to design a secure product or service as you can you know why bother you create a great threat model gee we had lots of threats and we have

beautiful diagrams and it's all nicely documented and it's accurate and then you don't do anything else you find the pr the point is you want to find the problems and fix them so for threat identification i i'd use the stride model there are other nomenclatures out there i'm familiar with strides that's what i've chosen to talk about stride is an acronym for spoofing tampering repudiation information disclosure denial service and elevation of privilege they all refer to properties that you want these are threats against those properties let's talk about some details so spoofing is the act of impersonating something or someone else it is an attack against authentication you're pretty intending to be a specific web service or pretending to be

bill gates i don't think bill's here today so uh we can all pretend to be bill i guess um tampering modifying data or code it's an attack against integrity magnifying a packet as it traverses the network the network in in your building the network over the internet the network and the car what have you repudiation is probably the most difficult to understand it's claiming to not have performed an action as in is and the property you're attacking is non-repudiation examples i didn't make that change in software and services the main mitigation for for repudiation is to log everything i didn't make that change well that's nice here we have the log on source control that shows you dead

last tuesday at three o'clock in the afternoon information disclosure is the privacy privacy related type of vulnerability or threat it's exposing information to somebody who's not authorized to see it um it is an attack against confidentiality very important in this day and age of privacy denial service is pretty self-explanatory it's to deny or degrade service to end users it's attacking the property of availability and finally elevation of privilege is attacking authorization it's where you get capabilities where you aren't authorized to have them and the classic examples are a remote user running commands or going from limited user to root if you can get rude on a system where you started out as guest you've definitely done some elevation or

privilege

so you've got your diagram you use your trust boundaries in your diagram to analyze the data flowing from one trust level to another especially want to be wary of trusted processes reading data from untrusted processes assuming inputs are evil or highly trusted processes running to low we've had many examples where a highly trusted process has put out a very informative error message to a not as highly trusted process which is then used that information to carry out an attack so let's do a mitigation example the the threat is that my car is parked out front it's going to get stolen somebody's going to open the door and steal a car start it and steal it

well i can mitigate it somewhat if i lock the doors no but the thief could pick the lock or i could leave the door unlocked which is kind of a deployment issue if you will an operational issue because i didn't use the mitigation that was provided then the user i'm sorry the thief could pick the lock hot wire the car whatever ah but we can mitigate this most modern automobiles require a fob which has an electronic code that between the fob and the and the vehicle that blocks the ignition without that fob being present so the thief comes along with a tow truck there's your vulnerability you get towed or do you you could get a hold of a

wheel restraining device and put that on your car which would make it much more difficult to tow

so you've come up with a list of threats using the stride acronym or whatever nomenclature you want to use now you need to address them the whole point of coming up with this set of threats is to actually go through and mitigate them there are four basic ways to mitigate a threat you can redesign to eliminate this is a fine thing to do it is much easier to do it during design time than to do it a week before you ship something pretty huge you can apply standard mitigations the classic example in web traffic is using https instead of http you know what if someone if you're building something what have similar apps components systems services etc

done has that mitigation worked out for them and actually in the backup slides on the talk i've got some example mitigation so i want to make that note you can invent new mitigations not always easy might require some specific knowledge or skills i mentioned https http https is built on crypto crypto is a very specialized skill any number of us have seen people do it poorly

or you can accept the vulnerability gee we have this design issue we cannot mitigate we are choosing to release with that vulnerability you assess the risk how likely are users to be impacted by this if they are impacted what is what is the extent of that impact you discuss that issue with with your management with customers and help them make the informed decision at that point your work is done here's the vulnerability here's the risk here's my recommendation it's a business decision at that point the customer may look at you and say we can't accept that risk management may look at you and say our customers can't accept that risk or management will look at you and say

we can accept that risk because if we have to go back and patch it will cost more than it would cost to redesign now okay so you've got your throat model you've got a bunch of threats you've got mitigations now you need to validate it does the data flow diagram match what you built if it doesn't you've just threat modeled something else have you enumerated your threats and tools are very useful for doing this i'll demo a tool in a moment at a minimum you have the stride for element for every element the test touches a truss boundary or is adjacent to a truss boundary or especially the flows that go across test boundaries and the threats describe the context

the attack the vulnerability and the impact if you're working with a test engineer or test group did they participate in developing the threat model full disclosure i'm married to a test engineer in fact she tested my code at one point in our careers she found some good bugs they got fixed test has a different perspective they like breaking things they find issues they ask questions you don't want that that you as a developer or program manager or designer or architect don't necessarily want to answer that make you squirm the point is that if they ask those questions and you answer them you have a better product or service on the back end and of course tess can a good test

engineer can take a threat model and say ah here's the vulnerabilities there's the mitigations here's the test cases very straightforward process okay you've listed a bunch of threats have you mitigated them do the mitigate mitigations describe what you're going to do to mitigate did you implement them correctly do they work can you prove that they work if you can't prove they work i would claim that you probably didn't mitigate correctly did you check these early if you did your release time frame will be more predictable and you'll have fewer all-nighters if you are working on a complex schedule or multiple releases what's your plan for rechecking the mitigations as you update your product or service

you want to validate that you've got your dependencies all listed you know what they are you know what security functions you're depending on and i would actually say are you sure of that and can't and why are you sure and then you've made some assumptions things that you noted when you were developing the threat model gee ssl v3 is a secure well it used to be i claimed that that's no longer a valid exemption as evidenced by some of the stuff that was announced in mid-october in the window space a valid assumption today is that cryptgen random gives us strong randomness i know several engineers on the windows team who have staked their careers on

that um if that isn't true then it's a bigger issue than any individual product if the design changes you update the design spec you update the threat model you update the test cases repeat the validation process my point here is that a threat model is like a design spec or an api spec or documentation in your product it is as living as the product itself okay i talked about earlier about threat modeling a car i've got a simple threat model i'll show you in a moment threat modeling tools have come a long way in the past 13 years i know this for a fact because i used a version one threat modeling tool where the most important thing that it did was

it generated a report at the end so i could look at and say yes we threat modeled the process of generating to the point where i could generate that report was extremely painful i would say i recommend always choose tools that meet your goals i happen to like this particular throttle modeling tool because i'm very familiar with it it has met my needs your mileage may vary i went to threat model at microsoft so i use the microsoft threat modeling tools the one you're about to see is available on the web on microsoft.com and the url for getting it is in the in the deck okay so now i'm going to get out of powerpoint mode for a moment

and i'm going to bring this oops help if i bring it up the right way

so this is the microsoft sdl threat modeling tool um 2014 which is basically a version 4 tool here i have threat modeled a car or actually parts of a car and i've simplified it greatly because frankly with the research i did showing that most cars have about somewhere between 50 and 100 electronic control units that's a lot of threat models but we're gonna we're gonna since it was wi-fi that kind of piqued my interest we're gonna focus on the wi-fi unfortunately the screen resolution i can't show you the entire threat model of the entire diagram at once so bear with me as i scroll you through it this is the human user the driver or a passenger

and this in this and this is the context diagram sorry this is the high level diagram the human user will do only a couple things they may have a smartphone app that they can talk to to control the car or they'll have a bunch of manual controls g a key in the lock press the ignition put the car in drive or in first let out the clutch turn the steering wheel turn on the headlights apply the brakes check the tire pressure what have you the smartphone app will talk over the cellular network to the vehicle whatever vehicle wireless interfaces the vehicle exposes to that network we could do a whole threat model just on this piece here the smartphone network

and the cellular carrier and the interface to the car but we're not going to do that here within the vehicle physical boundary you've got the manual controls and display you've got vehicle systems i alluded to a number of these braking steering ignition tire pressure you've got the wireless interfaces to those systems as well as the manual interfaces to those systems you know if you apply the brake pedal you expect the braking system to actually do something if it doesn't that's either a vulnerability or time to take the car to the shop on the back end also talking these wireless interfaces are a bunch of services over the internet which is a trust boundary this frankly scares me

because the internet is both wonderful and beautiful and really evil so a couple other things about this diagram is actually i've left out a lot of detail it's a context diagram after all you'll notice in this particular tool human user is in gray i have grayed out the human user because i will claim you can't threaten model humans and actually if i bring up the make the properties window bigger you'll see i'm going to assume the driver is authenticated and authorized to the car and actually i'll show you in a moment i have that assumption documented similarly similarly the smartphone app the cellular carrier i've grayed them out we're not threatening those in this threat model so they're

out of scope that's called yeah it's defining your scope knowing what it is you're trying to do what you're threat modeling here and what you're not going to do and i've also grayed out the world wide web because and the services because again this threat model is about the car it's not about the the services that are talking to it i would actually claim that nobody has actually threat modeled the world wide web i'm not sure you could i suppose you could do a context diagram it would rather complicated so that's a level zero diagram basic basic high level i've lumped every system in the car into one process bubble lost my mouse there for a moment level

zero again highly simplified there's our human user now the user is the driver or a passenger you know they've got some physical possession that's a trust bound that's a trust boundary i have the key or the lock to unlock the car or the fob or what have you i can start the car with that fabric key if i press the brake pedal the brakes get applied you'll notice i've left out a whole bunch of detail all of these are unidirectional data well all universal data flows there's no return flow i've left that out because it's not important for this particular threat model and to the gentleman's point here here's the braking system which is a black hole

for the purposes of this threat model that's fine i'm not threat modeling the braking system i'm what i've left out here on the back end is that the braking system actually applied the brakes and you could claim that the brakes are an external entity or you could represent them as an external entity perhaps as a data store or something so but but the braking system is a great thing to consider when you're threat modeling an entire car because if you are able to get from wi-fi to the braking system that's a pretty cool thing from an elevation of privilege perspective terrifies me

okay so let's go on here and somehow i have messed up my there we go scrolling to the right okay at the bottom here you have human user whether it's the driver or the passenger they're providing human input to their device their smartphone their tablet whatever it is they're going to talk to use the onboard wi-fi to talk to the web the user's device again is out of scope we're not that modeling your ipad here we're throttling the car's wi-fi system that wi-fi device talks to the onboard wi-fi probably over some sort of an authentication and authorization step or boundary i would certainly hope that was the case and then that onboard wi-fi through whatever means whether it's a cellular

carrier or onstar network or something some signal eventually talks the world wide web so let's go on board on down to the onboard wi-fi again here's our human user here's their device here's where they're talking to the onboard wi-fi over authenticated and authorized trust boundary that onboard wi-fi hotspot how is it protected now i'll admit i haven't gone and read the specs or gotten a hold of a manual for whatever late model general motors card is that is advertising on board wi-fi but i would hope that they don't prov don't permit customers to set their onboard wi-fi to have no authorization and authentication i suspect they probably do because the average driver doesn't really want

to bother with all that stuff they just want it to work of course if they can make it work without authentication authorization for their passengers they can also make it work without authentication authorization for anybody who's standing outside the car whom they've never met before who may have different motives

okay so the onboard wi-fi is talking to the world wide web over some sort of set of trust boundaries the internet as a boundary you hope that this is somehow authenticated and authorized but the other interesting thing is that your onboard wi-fi is talking the world wide web what else is the onboard wi-fi talking to in the car itself if i can get on the onboard wi-fi and talk to other systems in the car that's kind of a bad thing i could talk to the tire pressure system that'd be kind of cool i could tell the user their tires were fine when i they happen to be flat or i could tell them they're flat when

they happen to be fine or i could tell the braking system to apply the brakes every time the car goes over five kilometers an hour again the point of this threat model i mean what piqued my interest was gee onboard wi-fi what could possibly go wrong my threat modeling's like i'm raising a whole bunch of questions i would hope that the automotive industry has done this kind of analysis i suspect that a good number of the manufacturers have because if they haven't i think their legal departments would probably advise them that the liability involved but that advertising really just raised some questions in my mind and ultimately when it comes to a vehicle the most important things to me

is that it starts when it needs to start it stops when it needs to stop and when i turn the wheel it goes the direction i turn the wheel the fact that it has a radio or onboard wi-fi or bluetooth or anything else those are all dandy features but fundamentally it still has to be drivable see there are a couple other things i wanted to show you here we talked about things out of scope let me bring up the threat model information dialogue i know when i review throttle models i like having this all filled out especially this high level description because in theory if you've written a dandy a really complete threat model and you have the one paragraph

elevator pitch for what it is you're this it's actually representing somebody who's never seen your product or service before and has never read your design spec should be able to understand what it is you've modeled assumptions yeah you can't threaten model humans i am again i mentioned about authenticated authorized drive the vehicle external dependencies the cellular carrier the smartphone hardware and os the the car application on the smartphone your ipad the app on the ipad etc etc etc i didn't articulate all the dependencies there for a vehicle you could actually if you're trying a car from top to bottom you need to include the oil the brake fluid the transmission fluid the gasoline etc or diesel if it's a diesel

vehicle the other thing that i will show you i haven't actually fleshed these out but this particular tool you change from i just went to the view menu and changed from design view to analysis view it actually automatically generates your threats really cool so let's see spoofing the human user we'll take the first one human user may be spoofed by an attacker now this is a threat against where the human use the data flow between the human user and the manual controls and displays you can see that highlighted in the diagram above you'd either say it was mitigated in this case you might say it was mitigated because the user has has possession of the fob

or it's not but in this case we'll say okay possession of the fob mitigates it and then you the tool very nicely says gee if you're going to say something's mitigated you need to say why so the beauty of this tool for me is that because it generates the threats automatically the process of completing the throttle model the first step is to go through all the threats that are there and either say okay i've mitigated them or i haven't they're not applicable i need to investigate further or what have you and at the the end goal of course is to have everything either mitigated or not applicable now if you have something that's not that needs investigation or not started

that may be a risk it may be a vulnerability you're not choosing to to mitigate and that's fine this is a way of assessing where you are with your design before i leave this are there any questions on this particular part of my talk okay i'll go back to slide where

it would help if i'd remove the throttle mounting tool from the screen so we'll close that go back to slideware success so in summary what makes an effective threat model accurate unambiguous diagrams done to sufficient depth to thoroughly document what it is you're building you've stated your assumptions you know what your dependencies are i picked on openssl because it's an easy target but it's a very appropriate a very pertinent target because it is something that so many things use and when it goes sideways the internet tends to go sideways too your threats are well thought out your mitigations are chosen and implemented appropriately to actually address those threats there's nothing worse than doing a great throttle model

and choosing a mitigation that doesn't work gives you a false sense of security some resources this is the latest bible on threat modeling written by a good friend of mine named adam shostak who spoke at this conference two years ago um at the time he was at microsoft my comment when he first talked to me about this project and then eventually got the book finished and published was that there were any number of us at microsoft who could have written this book the right one of us did adam has forgotten more about threat modeling than many of us know other resources i mentioned the tool there's the url for it in my bio i talked about the secure

development security development life cycle there's the link to it it's not any better or worse than others it's a tool a resource for your use owasp.org talks about threat risk modeling again kind of the same idea let's go assess things and assess risk last year at defcon which unfortunately did not have the privilege of going to for a variety of reasons but there were a couple presentations that are really pertinent to the example threat model i showed one was playing with carf romer or how to break your car and this guy this italian guy went out and he found the physical connector behind the glove box for updating the car's firmware long story short he managed to brick the

car for three months it was his girlfriend my my sources told me it was his girlfriend's car not sure if she's still dating him or not uh apparently he ended up taking the car to the dealer and saying what's wrong with it it broke and won't work and it took him three months to figure out that they needed to replace all the electronics in it um i wish i'd sat through that thought i said that talk it sounded like a scream the slides which are the the link there were an interesting read very much a sense of humor tongue-in-cheek and all that but the bottom line is you break the car the second one is written was a

paper written by one of the directors of penetration testing at io active and charlie miller who is well known in fuzzing circles i believe he's at twitter these days they basically wrote a paper that looked at automotive attack surfaces for about 15 different types of cars and they i mentioned tire pressure gauge tire pressure meters they actually addressed that in that that talk that document they found a vulnerability or a potential vulnerability where you could go in through some other system and get to the tire pressure gauge or the tire pressure meter it was an interesting read all right any questions thank you i did address your question didn't i okay all right well for no further questions

i thank you for your for your uh attention i also wanted to thank alex and the rest of the b-sides crew this is year three i've been here all three years we started in a room about the size of the uh had about enough chairs for these padded chairs up front now we're in a theater well done thank you you