 Good morning everyone. Thanks for being here this early. I'm Arna. I'm a lecturer in security engineering at the Hanson University of Applied Sciences in the Netherlands. And what I'll be talking about is how we might be able to use threat modeling for improving or to help improve the security of software. Because currently if we compare the security of software with the security of or at least the safety of for example air travel or elevators then there's quite a difference to put it mildly. Now of course safety and the security are not exactly the same thing. With safety we're interested in protecting our infrastructure against the elements. Now with security we want to protect our infrastructure against Godzilla or attackers. Intelligence usually at least you can assume at least part of the time intelligence trying to get around our defenses. So of course as developers we can then ask are we doomed. Can we actually protect ourselves? And if we take the approach of penetrate and patch so after we've shipped a product looking for vulnerabilities and patching them I think we are doomed. Well another approach has been proposed. Scott goes under different names security by design building security in or shifting security left. The idea is to integrate security into the development's life cycle early on. And that can be in the form of now if you want to start applying this where do you start right which activity is then the most important. Now if you follow Howard and Lipner they say that if they had to choose they choose for threat modeling any day every day of the week. Now what is threat modeling? Threat modeling it's got well the term is used in for two different things. One thing more related to requirements engineering and the other thing more related to analyzing the architecture against security threats. So the one related to requirements engineering is the thing related to when people ask what's your threat model right what are your security assumptions and to give you one example this is a paper a classic paper by Doliv and Yao and the model that they they propose is the following. They assume about a saboter or an attacker that the attacker can obtain any message initiate any conversation and be a receiver to any user for any message. Now this is a threat model which assumes an omnipotent attacker right who can listen on listen on the ether to any message. Now this mess this image should be familiar to you right this is the model of the NSA intercepting any communication and also injecting any communication. The other approach of architectural analysis can take place later in the so so during design or actually once a design has been built analyzing whether there are any possible problems and the question that we then ask ourselves is what could possibly go wrong and this is by by asking ourselves this question we can before we write a single line of code we can really start thinking through possible security problems and we can also think of like how might it then go wrong. There's different types of threat models these different three different classes the ones that focus more on looking at the different types of attackers and their capabilities once looking more at which assets are important to protect and methods looking at what is the structure of our system and sketching that out. So for the attacker centric approach we want to look at who are our attackers when I look at their methodologies their motivations and one approach to map out like to take an attacker perspective with threat modeling is kill chains and this is an example of one like a general kill chain model right it it models how can an attacker get initial access how can they go through the network and what can they like what are their objectives. Another approach is looking at our assets specifically the key assets what do we really want to protect and one approach there is to for example sketch an access control matrix and looking at what are assets what are the different actors within our system and what are the possible missions now the approach that I'll look at in more detail are is the system centric approach yeah what we do what we do there is we sketch an approach to threat modeling sorry which like a so so we sketch a view of the system and this view it can take take different forms but so this is what we'll look at in more detail some approaches that some specific system centric threat modeling approaches are stride, trike and pasta now the one we'll look at in more detail is the stride approach and four questions can guide us when we're doing system centric threat modeling and these are the the phases that we can go through when we're carrying out a threat model or an architectural risk assessments firstly what's our system we want we want to get an idea of what we're actually analyzing then what can go wrong what are what are possible problems within that system that we've sketched then once we had a good view of that what are we what are possible security controls right what can what can we actually do about it and finally looking back have we done the right things so a lightweight methodology that you can apply going through these four steps I'll I'll walk you through the the one at the time firstly data flow diagrams I die so sketching data flows within a system there of course in many different ways to sketch a system but data flow diagrams tend to be the one used when threat modeling suppose this is our our system right a a general sketch of the headquarters of a an anonymous organization now there's many different types of threats here someone can can break in see the server but what we're interested in on a software perspective are is the the bottom part of so so all the things related to like web server firewall etc now what we can what we can do is we can abstract away from like this is already an abstraction but we can further abstract that to focus on so the data flow diagrams and these have a standard so these allow us to sketch data at rest data in motion or data being processed so besides so this is one one data flow diagram we can also diagram different levels of the system starting from our context diagram who are there are external entities going through and then going a more more detail and especially we can also look at for in this case this is a web application and we we have deconstructed that into the login process and authenticated operations and then we can if we want to analyze the login process in more detail then we can we can do so and draw more data flow diagrams of that now these data flow diagrams we can also label the data flows with how data gets transferred from point A to point B over what protocol and what type of data is being transferred now once we have this picture of our system it is this abstraction we can think through we can we can work on the next step which is to think through the possible problems that can happen and this is also called threat solicitation so to take one step back if we look at security then there there tends to be three goals that we want to achieve confidentiality confidentiality integrity and availability of information and we usually do that through applying authentication authorization and accountability controls so if we were if we then want to think of what can possibly go wrong we can invert these we can so to harm or to to affect the confidentiality of information within our system we can perform attacks related to information disclosure to harm integrity of data we can tamper information and so for each of these six classes of these six goals that we have we have a class of threats now if we take the first letter of each of these six then we get the acronym stride spoofing tampering repudiation information disclosure the Nile of serves and elevation of privilege threats so what we do is for each element of our diagram we can identify whether there is threats related to one of the stride classes so here's an example here we see that the browser client might be spoofed so someone can impersonate someone else and also the same goes for the web application now here we have a sketch of the architecture of the Swiss the Swiss payment network and we can already see what for example in the Bank of Bangladesh I think it was what went wrong there we can we see that the end user the end user computer is connected to the internet and also connected to internal Swift the internal Swift network so we can by brainstorm by eliciting threats we can already identify possible problems we can the end user computer might be exploited through an elevation of privilege attack here's another example this is a one-time token authentication solution and by going through so by sketching this representation of the system and by going through every so by going through the S for spoofing or is there a possible is there spoofing possible anywhere well we could we could think of can can someone is a spoofing we go we go through all the elements and think of all is is this threat possible for example information disclosure is information disclosure possible well we could we could think of the one-time token that's being transmitted or what are all the places where we can intercept that token now once we've done we've got a whole bunch of threats we can think of ranking them we can think of what are what are the relevant and the less relevant threats to address so how how do we actually rank these threats we've got a whole a whole bunch of of threats and which are which are the most important which are less important or what's our what's for example our top three now the answer to that is looking at risk not not this risk but the risk concept being the combination of likelihood and impact and one approach can be mapping risk from so having the possible to the likelihood or the estimated time until a threats actually impacts the system and then the amount of impact you can imagine that we want to focus our attention on the threats that are likely to happen to occur often so soon and also on those that have a big impact on our system another approach besides that that can help us with prioritizing threats is so decision trees this is an example for an elevation of privilege related threats we can identify does it impact the server or the client is it local or remote to what extent do users need to authenticate or not this can help us in in our prioritization lastly so once we've once we've sketched a system once we've elicited threats through applying stride they once we've ranked these threats identify the most important ones we need to know have we done the right thing of course as george box states all models are wrong and some models are useful so we could say like well at least if the model is useful to us then why why check whether it's correct and if they're all wrong then yeah why do this well some models are more useful than others so if we can improve that usefulness that's handy one way to check whether our model is correct is to check whether the higher level data flow diagrams whether they are matched to the lower level ones I do do data flows that occur in our context diagram do they also occur in the the level zero and the level one data flow diagrams another approach is to check have we do we have all have have we covered our complete attack surface I'd have we look at all the different ways of accessing our system because they those data flows should be present in our threat model of course we can also make use of cans lists of top 10 possible vulnerabilities to see if we have we have those included in our analysis and what can also help is threat trees or actually threat tree templates this is an example for the Nile of service attack against a data flow we can check if we thought about for example corrupting the message we can think about whether we thought about for example making the channel so in capacitating the channel right so we can we can check if we've we've covered all these threats and of course this checking whether we've done a good job that doesn't that doesn't end once you've done threat modeling once systems they change so we also need to keep thinking if we need to keep checking if our threat models are still up to date so that's a lightweight methodology for threat modeling a lightweight approach for looking at for going through the architecture of a system and thinking through possible problems one thing that's very important when when threat modeling is to do that with a team to involve not just developers but also also users or or proxies for for users and to to to take different perspectives and to to do that what what helps what really helps is to do this on paper do this collaboratively do it on a whiteboard for example this is the the the vulnerable application juice shop and this is the a quite high-level data flow diagram for juice shop so we can we can sketch this on a whiteboard relatively easily just with with markers and we can then with post-its identify where are our key assets right so personal identifiable information might be stored in the SQL database there's money involved with the whole payment service and then we can think through on different post-its what might be possible protections what might be possible controls so you could think of no sorry like what what what are possible threats and then we can think of possible controls against those threats and this is what it tends to look like and ideas that especially by by doing this early by doing this collaboratively you can address security early on in a development life cycle of course threat modeling is not everything there is there's many other aspects to address right there's many different activities within the security development life cycle and whatever you might think of Microsoft they do have a quite nice book that they've made freely available it's it is from 2006 but the sections on threat modeling are still relevant and an interesting exercise that I'd recommend those interested to do is to take any IOT application and to think through the possible threats to that IOT application one example being a smart washing machine connected to the cloud connected to a smartphone like ask yourself the question what could possibly go wrong right and and try to apply this also to your own development process thank you questions at the beginning can you please try to report the question was where do you start so that's a broad question but generally you start you start at the beginning and the idea is you start sketching sketching the the application from the perspective of who interfaces with the application right so you start sketching your context diagram and from there you think what are the possible yeah possible things that can go wrong sorry top down yeah generally so so yeah generally top down but you can also you can start from you can also start with with like subsystems and then you can combine the threat models of the different subsystems