Threat Model The World

all right evening everyone thanks for sticking around so my name is Karen Conliffe I work for Liberty IT we're an IT company based here in Belfast and Dublin we're owned by Liberty Mutual I've been working in software development for about 20 years now and for the last half of that I've been working in that sort of gray area between development and security so they have sack ups application security and security development has been a lot of my focus now it's secure development I would define as teaching developers how to code securely which is a tricky business some of it's about skills most of it's about mentality most of us about getting people into that sort of

constructive paranoia state that makes for a good security and I find that threat modeling is a really great way to get that sort of threat focused thinking into design into construction into all the phases of creating software threat modeling was also really useful for us because we used to have a real problem like years and years and years ago where the development team spoke one language and the security team effectively spoke a different language so you'd have a meeting then you'd spend about like half an hour just getting up to speed and what et as we're talking about and threat modeling is a great way of loading security knowledge into the developers so that they're able to talk

intelligently to security people just good so as a Manson like I've been threat modeling for seven or eight years we've been doing it as a company for about that long and we've got a lot of experience in it we've had a lot of pitfalls we've learned a lot of things along the way and I would like to share those all with you here today I would I really would but there is a problem hands up anyone here who's signed an NDA yeah for those of you haven't the first time you said in NDA this is about what it feels like it's kind of a terrifying prospect but the thing is like for very good and sensible reasons I can't

actually show you any of the threat models that we've worked on over the last eight years because well actually this is a general problem insecurity discourse in general a general problem in general great but the issue is that it's easy to talk about attacks it's fairly fairly easy to talk about active defense but talking about passive defense is not something that we can do that easily because you worry about compromising your defenses and it's this whole big gap in the experience that our people are sharing and the things they're talking about you don't get these real-life lessons communicated well but I have a solution I'm just going to tell you some stories in fact what I'm gonna do is I'm gonna

give you some fictional context for the real life lessons learned so I'm gonna talk about for companies for places for scenarios for threat modeling that aren't like anything I've ever worked on though they may bear some relation to some real-life things but you can figure that out for yourself so but what I'm going to talk about is a smart home heating system I'm going to talk about a smart car I'm gonna talk about a Bitcoin exchange I'm going to talk about hospital and we're gonna see what real-life lessons we can apply to threat modeling these types of things so let's start with the borrow smart home heating system the best fictional home heating system on the market the next

time you want to heat your fictional home get a borrow so actually a quick tech who here has done threat modeling okay most years so I don't need to get too much into the basics but the benefit rest is like the basic idea of threat modeling is very simple you just model out your system reach a common understanding then go through it and say like okay where can we find threats the gold standard for it is the stride methodology that was developed at Microsoft which they put out about 15 years ago out into the world for people to use and that's what a lot of people base it on and this is the exact type of

threat model that you would see people doing their stuff that is you've got your external entities your processes your data stores and you just map out the flow of the data threat this is right really good and like factually the first big lesson I'll give you is like don't have your threat modeling session and have someone turn up with this diagram already drawn the real value in modeling the whole thing is getting people to gather to model it so they had a common understanding but it is it is a great way to sort of like get people thinking in the same space and to commute but it's not great for communicating things right because the

thing with this is like a diagram like this the people in the room talking through it may have an idea of what's going on inside this micro-services server inside the ethanol but if you're putting this to someone who has no idea then it's not great for communicating it and part of the thing with this is that this isn't really a classic data flow diagram so said this is the way everyone draws their threat model diagrams in the strike methodology or people often do but they're not really using processes because a micro-services server isn't a process it's a component so we would talk about this as a component based data flow diagram as opposed to a

process based data flow diagram we actually do out your processes and you explain so like okay this is how the data is actually being manipulated and you use boundaries to mark out your components now this was kind of a paradigm shift for us in threat modeling because it did help us to get a lot better understanding of what we were looking at and it also meant that your threat model suddenly becomes a great vehicle for explaining your system if you've got things mapped out like your threat malls a lot more accessible to people who aren't working on it so the second part of the stride methodology is applying your threats to it you can see in this case like this is

your smart home heating system you have your preferences that list when you're gonna be at home when you're not gonna be at home and that's obviously an information disclosure thing you've got your mobile app connecting to your micro-services server and they're spoofing their the thing to though is that you could just as easily have find those if you use the original diagram so that's my and if all you want to do is drive out the threats then the original type of diagram is a perfectly reasonable way of doing it so it's it's nothing like there isn't really a wrong way to do them the whole point is just to drive it together and get the common

understanding so let's say that you have like you've deployed your we've done your threat modeling we've created our borough smart home heating system I've told you about how great it is you've gone and bought one and installed it and straight away and it's going fantastic then one fine morning in June in the middle of the biggest heat wave that Belfast has ever seen you wake up with your heat on full blast you go downstairs and your cat is staring like this at your thermostat you go to see what he's looking at and this is what greets you what happened is that poison pill update has stuck ransomware on your thermostat it's playing a high pitch sounded on the air catkin here

which is why he's currently destroying your sofa and you you're as heating's burning up and you're roasting and it's not a good situation but the thing is like what happened here why didn't we catch that in our threat modeling well the answer here is so that we had our people in the room doing the threat modeling we had all these process design people and they were going like yeah here's what we're designing in there but we didn't have any of the people who are actually working on the device in there so we missed out on the fact that inside the control unit your code is being pulled from firmware and the firmware is another datastore that you need to

consider and the lesson here is really like make sure you have all the relevant expertise involved in your threat modeling session because it's very easy to have people who are focused on one area of your design and it gives them a tunnel blindness into it it's that's the Burroughs home heating system next up bit livelier is the greenhorn Iroquois smart car now you might ask like why would you threat model a smart car but I mean modern cars are really just mobile phones with two tons of metal and an engine attached to them when you get down to it there's this is and this is using the same so like standard DFT component based notation

but this is the standard architecture of a car where you have a controller area network in the middle all the things hook into it messages get passed around fun thing with this is like this is actually the architecture that cars have had since around the seventies which is one thing to bear in mind with all this Internet of Things stuff is people act like all these devices only came into existence when they started plugging the internet into them but your architectures have evolved from the original versions of those devices but this also points out the issue with because in this case like if we're looking at a car what we're really doing is we're threat modeling the

architecture of the car so if we started trying to use this data flow diagram notation we just be redrawing the architecture diagram so why don't we just use the architecture diagram and this is a perfectly valid this is actually a real smart car architecture system this is the automotive service bus which was developed by the University of Munich and open sourced it's kind of cool and we'll get into some of the features of it in a second but the thing here is that if what your threat modeling is your architecture if what your threat molding something you already have a diagram for then it makes perfect sense to just take your diagram and start adding your trust boundaries

or adding your boundaries - it's rather than redrawing the whole thing in with less information so I mentioned that so this was developed by the University of Munich as I said and they were thinking about security when they designed it which is something becomes clear when you start adding the trust boundaries to it you can see that what they've done is rather than one single controller area network they've set three separate ones and they've isolated them from each other so the idea being that if someone compromises the entertainment system they don't automatically have control of the cars transmission and be able to turn off the part your wheels when you're doing 7-liter in the motorway

because that wouldn't be good so that's what they've done there but there's also some interesting things that come out when you start drawing there so on like that iPad the sitting inside a machine boundary now that's actually the control console for the car in this design York you control the car through an iPad this mounted in the dashboard and it has a Wi-Fi connection to the architecture to talk to everything which is obviously a little bit of a security concern the pop site once you start adding these boundaries in and we can pretty easily add in our threats and say like okay yeah there's a spoofing and allegation of privilege on the API there there's a

denial of service threat I guess on the all the bits of the transmission you can see there's this so like side connection through the into the battery area that might lead to the denial of service on the battery stuff and you can get some value out of this but we are falling into a big trap here which is that we mentioned stride earlier we're using stride to look at the threats for this stride again it was developed by Microsoft it's a really great way of classifying the threats to an IT system the problem is that we're not threat modeling an IT system we're threat modeling a car and cars have very different attackers and very

different threats to worry about this is again from the city of Munich this is a from a white paper that two of their professors and a guy from the German University of Applied Science did but this is breaking down the potential threat actors on a car and you can see that there's some very different people involved here than you would think about in terms of an IT system like I like the tuner one which is like someone who owns the car and thinks well I own it I should be able to do whatever I like to it which includes opening big giving security holes in it but I'm gonna focus in on the thief because the thief in this case we

normally think of thieves in terms of IT systems in terms of want to steal information financial information credit cards personal and for that sort of thing but this is someone with a different goal and the best way to get from that goal to actual threats to us is attack trees in this case is more of an attack beanpole for simplicity SiC but this lets us start with our attacker work through what do they want to do or what are the way things they might want to do how could they do it and then how could they attack our system to do it and base off this we can add a new theft threat to our model and we can see that

oh yeah these two driver door and passenger door modules might also be something that someone might want to attack and so we have to protect those accordingly so again it's the whole thing that's like the you have to consider what your threat modeling as well as the actual threats and might be on it so next the mind Fox Bitcoin exchange this comes from an alternative universe where mine Fox was the name of a Fox themed MMO that went bust and then the website got repurposed by its owner as one of the first big Bitcoin exchanges and they did but because it's an alternate universe the people doing that really cared about security so they decided to start threat modeling and as

they were building it and if we start doing a component based data flow diagram in this you can see that you have the problem immediately which is that it's way too simple you're you don't have a lot of moving parts in terms of components here you just have your transaction engine that hooks into things and then your user client that goes into that so you can't really get the many good threats out of that on the other hand if you start doing a process based data flow diagram it balloons out of control very quickly because you've got loads of processes going on here because the trading exchanges are very complicated like just take for example

selling you might want to sell right now you might want to sell when a value reaches a certain threshold you might want to sell a specified time there's all different kinds of use cases for it and that points to a way that we could drive out threats on this and model it which is not using data flow diagrams at all but using misuse cases now that's not necessarily that readable because it's a little bit small but basically this is a fairly standard use case for someone wanting to sell their Bitcoin immediately so you have your different actors in there which is your person who wants to sell it there's the they ask can we sell it it

goes out to their wallet and we check do they have enough okay then we take it out transfer it to our wallet transfer payments over to their bank and simple where the misuse side of it comes in is when we start adding in new actors to the Ischia people who might want to do bad things such as a thief now in this case the thief might want to intercept the transfer of the Bitcoin and redirect it into their wallet rather than our wallet or they might want to steal the person's payment credentials as they're transmitted to the bank there's other actors we could add in then like we could add a fraudster in who wants to

sell a load of Bitcoin there and then immediately force the price to drop and then immediately buy back all the Bitcoin lower price which is a problem that did plague a lot of early transaction engines because they didn't think it would happen so we go through all these we built we and this is good because like we're actually thinking about security right when we're designing ITAR processes and we build in all this security and we put it out there and then something good and bad happens which is that unexpectedly we're hugely successful everyone's talking about mind Fox it's on the front page of the Financial Times so like though the ultimate Bitcoin trading thing and we're

like everyone's looking at us which unfortunately means we have to start acting like a real company now which so for example we did our threat modeling we listed out all our threats and we put in place solutions for them which is good like we've solved all our problems but we have to t have to convince these guys that we have done that this is the logo for the European Court of Auditors by the way and it's just such a great logo I thought I had to get it in somewhere but it's how do we prove that we've implemented our mitigations well same way we prove everything in engineering we use tests I'm a huge fan

of adding tests to threat models in general because it keeps people honest and it shows that they've actually put their mitigations in place but if you need to be able to prove out your threat model and prove that you've met the needs of it then having tests in place means that the auditors can go through they can check your test data they can rerun the test themselves if they want and it's a provable artefact now so last story is about synthetic cons General Hospital I think hospitals are the next big thing in InfoSec there's and it's a really broad subject I'm not going to get too into it Edwin mentioned I am the cavalry earlier

and they have a lot of really good stuff about this out there basically there's a lot of security vulnerabilities in hospitals and medical systems in general there's not a huge amount of impetus on people to secure them so far I think you get the first big GDP or adjacent medical information breach and all of a sudden there be a lot of money pouring into this and there's a lot of companies already starting to position themselves in it so there's a broad thing and I'm just gonna look a very simple system in there we're gonna look at the system for the nurses to manage patient records on the ward so this is like just simple system nurse on

the ward wants to check the status of a patient and then record new information okay blood pressure this temperature that very simple except that the information in question is medical information and medical information is privacy kryptonite it's like it's really active you have to be very careful with it you have to make sure it's managed properly and so we can't just have people being able to go in and access it we need to put in place an authentication mechanism we need to check that these nurses are allowed to access these particular patients records and this is an example of how you should really iterate over your threat models because you do your first threat model

it feeds back into your design hey you need these additional pieces then you enter it back to your threat model and say okay let's add in these extra pieces and see what new things pop ID so we do that a few times and eventually we come up with the system where we've got okay the administrator the matron on the ward assigns out which nurses can access which patient records and the nurses login and they can see the patients and on paper in all X grid and then two weeks down the line we look at the logs you may notice her after the deployment and we notice hey none of these nurses have ever logged in the only person

who's ever logged in is the admin and she's logged in all day what's going on the answer is that we've designed the system that's great on paper in practice nurses are right there saving people's lives running around they're heavily overworked they do not have time to be constantly logging into a system and logging out of it so what they've done is have just logged in with the admin role that can access all these records and just left it sitting there all day which is a sign that we've fallen into the trap of we've designed a system that we think people should be using as opposed to something that actually matches their needs so the solution is

obviously like replace the login step with something like tap your badge and an rfid reader and it unlocks the computer and then we're happy because we can read this is this specific nurse and they can access these records the nurses are happy because all they have to do is like tap and it unlocks in this grid so but again it's like it's just you need to build a system that people will actually use and not that they're driven to circumvent so the last lesson the last pitfall that we've fallen into is a mistake that we've made on every single diagram that I've drawn for you so far including this one which is that we haven't included our logs and this is

like you have to make sure to remember that as well as all the things you're designing and putting out there there's all these non-functional requirements sitting out there there's logs there's backup systems there's all these additional data stores you need to worry about especially with personal info Angwin and all of them and have tests for them so on so there's a lot there's a bunch of stuff they're summing up the general lessons learned but to me the main thing to bear in mind is that threat modeling shouldn't be something that you're doing in isolation threat modeling is something that you should be integrating into your processes integrating into your thinking thinking about okay what are we actually doing

and what are we actually trying to accomplish as opposed to just having it as an exercise that people go through and this rubber-stamped and it's done at the end so but that is me is my Twitter and liberty I tease Twitter and LinkedIn and Facebook and all that sort of stuff I do not tweet at InfoSec much at all but if you like ranting about historical things then that's we find that but that is me anyone any questions anybody have any questions no questions at all sure all right thank you very much awesome presentation