 And I guess without further ado, let's welcome Justin here to talk about threat modeling My name is Justin Goodheart. I'm from Olympia Washington part of the only mega group here hanging out helping out and I'm here to talk about threat modeling And try not to do feedback So if I lean forward I started out with doing development work for about 13 years and then at one point they shifted and pulled me over into the security team And so I got a chance to start trying to help developers write more secure code Better quality code and over the years. I've been able to help out with threat modeling and help out with secure code static code analysis different talks and pretty much just trying to be A good member of the community How many folks have done threat modeling before show of hands? Nice Those who didn't raise their hand. I could probably guarantee that you have done some form of threat modeling Good example is with traffic driving around obeying the speed limit signs doing maintenance on your car Being able to keep an eye out for the drivers around you Especially those who are driving erratically or who are on their phone while shaving and putting on makeup So what you're doing is you're putting in different controls to try to reduce the threats that could go against you So obeying the speed limit signs keeping your distance from the car in front of you making sure your Vehicle has been properly maintained so it doesn't break down on the side of the road those kind of things is what we are trying to encourage the developers in doing when they're building applications and When they're taking a look at implementing new systems. We want them to See what kind of threats are there see what kind of things to avoid see what they could put in place in order to try to reduce the Risk to the application. I missed a slide There it is So starting out I was going to talk about application threat modeling and then I have a couple of slides on network threat modeling as well Kind of a new area. I'm diving into Threat modeling is what I have most of my experience though So application threat modeling is approach for analyzing the security of application or system so good opportunity in order to be able to take a look at how it's documented how how it's built how you have put in the different mitigations in place and It also helps with the developers to get a chance to work with the security team In order to learn more and do cross collaboration because there's things developers have figured out to make things better They could help security and then there's areas where security gets a chance to collaborate with the developers to help their code That their systems be more secure So the process threat modeling process is pretty much breaking down the system Then what you do is you determine what threats are and then you go through and you identify the counter measures So mitigations or controls you can put in place to reduce the risk Potentially also eliminating risk Usually that means getting rid of the feature but Most time what we do with app case threat modeling is we start with the data flow diagram a good conceptual diagram of the system using some simple shapes the different shapes are external entity so a different system or Potentially like someone another company systems or another internal system that you're using or interfacing with Maybe even a third-party service You have a process. This is Where the work is actually done in the system So a function could be a web service. You can look at like the application itself as its own process The data flow so where the data is going back and forth and that's what you're trying to focus on And then the data store where the data lands where the file shares are or your data store like your database Maybe a flat file that you're storing somewhere with some data and then trust boundaries is something a little bit different from the Traditional data flow diagrams that threat models use and that shows going from one security context to another So like a good example on a web server You have different rights that you're running as then you would if you're connecting from a browser Or the settings that you have on a database is going to be different than your web server So you have different contexts that you're transferring from and so we want to show those lines In order to show when you're going from one context to another Good example of a data one of the diagrams for a threat model is just one of the canned ones I found online from Microsoft and This one shows a user browser the users coming in through a user interface service Goes over to user profile service that has its own data store And it also incorporates in a news feed service that it also has its own back-end data store But also can push out RSS feeds to the internet What we do is we start out with the diagram here And we sit down and we label each and every interaction going from one Process to the data flow or from the data flow across the trust boundary or going into another data store and We want to make sure and stuff that we could actually reference that one pinpoint and this was kind of a sloppy Normally the numbers are much better and you break it down More detail, but this was kind of overlaying Then once you have your interactions on the diagram you go ahead and you sit down and you show it each one of those steps where it crosses over from Across trust boundaries cross processes and you identify the stride stride is a different threat categories But each one has each of the different processes external interactors data stores, etc. Have a different potential threat area Let me go into that a little bit So stride is spoofing tampering repudiation information disclosure denial service and elevation of privilege and We'll see if I go back one Probably should shift these slides around so that I go through stride before talking about the matrix so Old school what we do is we sit down with this matrix and we break down After we've identified all the different elements on the diagram and we'd figure out what threats were there And so we sit down and we go okay We're going from this point to that point and we sit down and go okay They're spoofing and there is Repudiation and then we move on to the next one and so it's kind of a manual process using this matrix Later on I'll show you a tool that Microsoft provides for free that helps determine the threats automatically make it a little bit easier So spoofing is trying to pretend that you're someone or that you're something that you're not So a good example is if I was to go up and say that I'm Bill Gates I'd have to prove it and usually we do that through some sort of factor authentication Sometimes multi-factor sometimes single factor and you're trying to prove that entity Well, sometimes you're interfacing with another service some third party That third party you want to be able to prove that that really is who you're talking to and so you're trying to reduce the potential of An attacker or someone or maybe in a mistake of mis-configuration and talking to someone that you're not supposed to be talking to or Be someone that they're not Tampering this is where you're changing the data either across the wire or at rest or you're editing it when you're not authorized to do so so being able to Capture it across the wire injects something Also potentially compromising the files on the network share something like that Repudiation is basically a legal term for being able to prove that something happened Usually we do this for law mitigate it through logs in order to prove Usually also the third party a good example When you're buying stock and you go in there and you say okay the stock is coming down It's about $15 a share and you go ahead and you buy a hundred shares, but then you see it drop another $5 So you call up the company you say hey, I didn't buy it at $15. I really bought it at 10 Well in order to be able to reduce the someone trying to pull a scam or something over They have a trust of third party that time stamps the interaction How much it cost the time and you could prove that when you bought it you really bought it at $15 a share That's a good example to also the checks in the mail So you call up to or the Collectors call you and you're talking them on the phone. You say well the checks in the mail We'll wait for them to prove that the check was in the mail on that particular day the post office will stamp The envelopes that are going through the post office with their own time stamp And they are a third party that doesn't care if you pay your bill on time or not And so that works for non-repudiation another good kind of fun example Information disclosure is very similar to tampering except this time is unauthorized viewing of the data So you've been able to gain access to a file. You've been able to see what's going across the wire that when you're not supposed to Now this has also a lot when you're getting into confidential data that a lot of folks are not authorized to see Denial service is always fun. This is where Being able to prevent something from running be able to prevent someone from getting to your service being able to prevent it from someone Get into your website Denial service also has fun stuff with the distributed DDoS attacks or What happened last night? I guess with the wireless where? conveniently went down for a little while Elevation and privilege and this is where you can inject something in in order to be able to get more rights than you were authorized to have so some folks do this through Probably sequel injection cross-site scripting be able to gain access to different areas or be able to change something They're not supposed to be able to change or to try to change the context that they're running as in order to be able to have more rights admin rights other rights back about 2003 I think it was a trustworthy computing initiative that Bill Gates put out with a simple memo They started working on being able to show different ways of Identifying a scale for the risk of the system and they use an acronym called dread and it stands for damage repeating Reproduce ability I could say it exploit ability Affected users and discoverability and the whole goal was as you sit there with the big room of folks And you go down each one of these given it a scale of one to five And so you could sit there and you could debate over is it really a three? Is it a four? who wins and What ends up happening is is you end up going through and identifying what the risk score is for that particular threat and Lessons learned they ended up shifting it because there was too many folks fighting over the different scales To be able to go for a high medium low So if you sit down in the group and someone goes well I think this is going to be really bad because it will impact us it will affect 10,000 users We're going to set it as high and it's a lot easier to sell a high medium low than it is to go through each of these and have D of Five and a r of one and a e of three and what does that mean kind of thing? So high medium low works much better when you're going through threat models Then you go in and you start addressing each of the well Kind of bring it back Make sure that what's going on in my head you guys are actually understanding too so You've gone through you've documented the system you created a conceptual diagram You've now marked each of the interactions you've gone through and you determine what kind of my threats are Happening to each of those interactions and you've gone through and you've identified the risk of that particular threat Now it's time to mitigate it So there's four main ways of mitigating threats and it's kind of it's very similar to dealing with risk And you can mitigate the threat by adding in a control some way of you know to reduce the potential of that threat being exploited You can eliminate the threat, which usually means you're getting rid of that feature. You're getting rid of that system Sometimes program folks would come up to you and say we really need to have this system in order to track this data and Then they just want to be able to put it into a Microsoft access file Put it on the network share and think that it's going to be safe or even better Someone in the office admin assistant knows how to build access forms and they lock it down with a password But they keep forgetting that you just hold on the shift key Open up the access file and bypass everything so a little the risk is there so Sometimes the better bet is to either get rid of that particular data store and say maybe there's a better way or Be able to transfer it over like the next one where you shift it over to another system Or you add an extra insurance in order to be able to deal with the risk or you deal with a third-party tool Trying to transfer that particular threat over somewhere else and then there's always accepting the risk and accepting the risk could be very dangerous Folks are usually Quicker to accept the risk of a system a threat or of a bad system Then they are to actually address it because I think it's going to take more time more energy a lot more fighting just to do it right and so managers usually will Just unblindly accept the trick there is to make sure you document it Make sure they understand what the risk is and make sure that they understand what could happen if it goes wrong And even better is when you could get the development team to come back later And no doubt how they would fix it if they were told to go fix it in an event of a breach or some sort of incident But another kind of thing I picked up in one of my studies Sometimes worry is a sign that the risk hasn't been fully accepted or that risk acceptance was inappropriate So you start going down the path. They've already said we're going to accept the risk and Then now the manager is a little worried about it or the dev team manager or someone else release manager And they start to question whether or not That risk is worth it You should probably try to circle back around and reevaluate to see if there should be some other control in place Or what you could do in order to be able to reduce that risk So if you decide to go ahead and mitigate There's two main ways and stuff that you can mitigate a threat Design the security control that will protect it and that's where you go through the different common mitigations like sequel injection threats sequel injection threat use parameterized queries Your threats gone you make sure you could use Third-party tools like Andy the NAD framework, which does parameterized queries behind the scenes You can in some cases when you're doing more to the dynamic script incorporate something like sanitization and also input validation But the best bet is to use like parameterized queries and you put in that control of using parameterized queries that threat goes away Identify that we are accepting the risk And this is the second option and this one I also kind of note it's really good to document it and also what you would do if it was exploited because that Having that list there it helps you reduce the time after you've identified that there's been an incident Before you could have a fix in place or a hot fix in place another good thing when you're going through threat modeling with a team is to Sit down with them and say what are some of the common ones that we have and as you start going through the threat models Start making a list of the different threats and how you would How you mitigated it in that particular project This list eventually builds up into a nice library a reference library you could refer back to How do we fix it in the other project? What did we do last project or last year and you can start seeing okay? We saw this again. How do we fix it before this is a real quick easy way? Or how can we make it better and circle back and fix the application from last year? And so you get a chance in order to use this as a reference library But it also builds up the team because as you go through it more often they have a point of reference They can study up on it. We had lessons learned and then another good thing to do is to look out at the different articles and blogs and different feeds that come in talk about security related issues Because that Brent builds an awareness with your dev team Security team as well being able to know what's out there. What kind of events are happening What kind of threats are on the horizon? What are folks finding with the new technology that's coming out and What it does is it helps build that team up with their understanding and the better the understanding The more they could collaborate when they come across a particular threat in the system that they haven't dealt with before So an iterative approach. So just when you think it's over you get to go through it again in my organization a Lot of the developers They'll build the threat model and then they walk away from it and then they go build something else That doesn't exactly follow the threat model. That's a very bad approach So I'm constantly trying to get them back in the room when things are changing to Re-evaluate how they've addressed that threat what the system looks like Maybe you even recreate the threat model after the fact in order to make sure it's more accurate And then help identify if there any other any threats that we did not mitigate or we didn't know we're there and so Practice makes perfect and it really pays off And so as you get a chance to go through a few it also builds up more confidence with your dev team Because they've gone through it a few times. They're more familiar with it. They get faster at going through the threats and This is a diagram I pulled for more of an agile process But the idea is that you have that requirement that vision that you want to build Comes in you model it create the conceptual diagram You go ahead and you think I didn't identify the threats you figure out the controls You're going to put in and that's where you enumerate through the threats and Then you go ahead and you build out your mitigations And then you do a validation step and you could use different tools for the validation step like static code analysis Peer reviews are really good You also have the Chancellor and Poland security team if you have one in order to take a look at the code at the system helping them with the validation Quality assurance testers are really good allies to have when you're dealing with the validation step too Because they could find functional bugs that would also resolve in a security bug because if it's not working right maybe it could be exploited and So some essential questions that we want to ask while we're going through the threat modeling process What are you building? What does it look like? What is it using? What kind of platforms? What could go wrong with it once it's built are we going to deploy it out to the wild and just let it go or do We have a plan to maintain it What should you do about those things that can go wrong? So If you know that there's going to be the potential that Your internal server that's underneath someone's desk could go down Maybe you should move it to one of the servers in the data center or go to the cloud Which is a fun buzzword and then you go ahead and ask the question of did we do a decent job of the analysis? When we're going through this threat modeling process have that retrospect Retrospection of how it went How did we? Communicate as a team. How did we address the issues where the one areas that we need to improve in? Do we need better models? Do we need to do a better job of working together across the different teams? And get a chance in order to figure out how to make it smoother quicker and easier When we're going through that I kind of explained the more of a manual process of doing the diagramming Microsoft I mentioned earlier and a few other companies have some tools that make it a lot easier So that you could just do the diagramming and then it helps you with identifying the threats and then also documenting how you're mitigating the Microsoft threat modeling tool 2016 which they also now have a Prototype a preview for their azure version of a threat modeling tool to help out when you're doing azure type systems This one is free and it it works a lot like a visiostensils You just do the drawing of your system and then it determines the threats for you And you just go down and you show how you're going to address those There's another one called threat modeler threat modeler has a cost to it But they have three different edition Editions to use you have standard edition where you get a chance to draw everything out more of a single use on a single machine license You have a dev ops edition, which is supposed to help with The devs get a chance to connect they do their role security folks connect and do their role And you get a chance to kind of track it through your life cycle and then the enterprise edition is for more of the distributed keeping track of multiple systems multiple different projects and Then some other possible threat modeling tools that you can look up the secure CAD Iris risk, which some folks say is really I haven't got a chance to dive into it, but I've heard good things about SD elements by a security compass, so that was the application side I also want to note on the website for tour camp. I also have two other resources a Guide that talks about the different types of threats for the stride threats And then a list of their mitigations the common ones to use is a guide in order to help with the conversation And then also I have a networking resource guide in order to help with some of the questions that you want to ask to that So kind of shift gears a little bit from the application side And you're going to see my novice work on the network threat modeling side, so a Lot of research and to trying to find Someone else's work because plagiarism is cool And so I found really good presentation that talked about Documenting segmenting and then restricting is the kind of the roadmap for how do you address network threat modeling? the concept is Keeping your documentation up to date on your network map how the systems are configured so that you could use it as a Reference guide in order to make sure that things are right because that helps with the validation step When you can circle back later The segmentation in order to be able to make it so that it's not one big flat network that Everyone can't talk to everyone unless you have other controls in place like the certificates and There's some new stuff that's going on now where you don't even have to worry about firewalls and I don't know I saw some stuff at the RSA conference that was pretty out there But with the segmentation you don't want to be able to have something that has like confidential systems Or if you have secret or top-secret type stuff being able to be on the same network with all the Public information you want to be able to separate those out so that someone who gains access to the public systems Can't necessarily gain access to your more sensitive networks and then restrict and Instead of going with the defaults for your rotters and switches instead of going with the defaults for your servers Be able to configure and lock them down so that folks only have access to what they need to to get the job done And only to the areas and stuff that they're supposed to be able to get access to Some additional considerations So how many different devices are you talking about a home network where you're talking about an enterprise with? 19,000 plus employees with different servers and devices across the whole How many different versions of firmware you have to deal with if you have five different router types But they're all dispersed across and they all have different firmwares Is there maybe a chance there in order to get them all in the same firmware? Are you using the recommended versions in some cases? folks in different organizations personal experience Forgot to kept the routers up to date on the latest firmware And so a couple years goes by and you find this and it's a firestorm in order to go through and try to get everyone up To speed get it all the firmware to the right level and then do you have a good change management process in place? You know to keep track of the different versions the changes Where they're at and then also you don't want any hidden surprises So one day all of a sudden everything's available through shodan and you're scrambling to figure out why and there's been no changes At least nothing in your logs and then all of a sudden you call upon the group that works on it And we're actually they're now off the internet again So it's kind of weird when that happens magically Without any logs or any change or any record that they made any changes on the network or firewalls And so it's kind of scary because you never know when something might just pop up Another option I've seen some examples where folks have taken a network diagram for their network Threat modeling and they just converted it over to a data flow diagram and then use the existing tools that they had in place but they used it more with the strides and the dread and Some folks say that that is challenging because Application processes aren't exactly the same as the network So so questions Good please Very good question. The question was is how long how much time do a developer spend when they're on threat modeling when they're building a new feature and Depends on how hostile they are Some groups Haven't done or haven't been forced to do a lot of threat modeling before and so they'll drag their feet and they'll make Seem like it's the worst idea in the world just to convince management that they shouldn't do threat modeling in the first place It does happen but I've have Worked with multiple teams now stuff where we could get a new threat model knocked out in about an hour and Sitting down and just get a room together make it a team sport Pull in the folks that are working like the BA so they can answer some questions Pull in if you're dealing with like databases operations of the server's configurations Pull the operations folks into the room sit down and you just spend that hour going through and knock out the threats Make sure it's diagrammed accurately and then run with it There are the question was Between application diagrams and network diagrams the differences is that right? Yeah So with the application diagram you permanently are focusing on the data Where is it going in the system with the network? You're looking at The different IP ranges your different firewall rules Where things get diverse back and forth what kind of traffic you're looking at? Do you have a quality of service? configured so maybe streaming a video goes different than Someone trying to send an email but usually what you end up with is There's the logical network diagrams where you could show The IP address is going from one router to a switch or Traversion to whole network and then you also have some folks that will do their whiteboard network diagrams Which look like clouds with lines and some little brick walls and so it kind of varies there On the network side, but usually what you want to do is you want to have something that's accurate So make sure that they validate the diagram and then you just sit down and say okay Do we have the right versions of the firmware? Do we have it locked down properly? Do we have the right firewall rules in place? Have we worked with the firewall team and are to make sure that the configurations are there or is it set to any any? Which some folks still do but Yeah You remember The question was about how we see the threat modeling impacting the cyber insurance world and The cyber insurance world is dealing more with the risk management than the threat management of the applications But it still comes into play because some folks will say That they'll just go ahead and pay a little bit more for the insurance or a third party through an SLA will insist that they have their insurance a High enough in order to cover the expenses of the system or potential damages or how it would take in order to get it up in them a natural natural emergency or Some sort of attack The first part again real quick Audit compliance So kind of breaking that so the difference I think the question was So kind of the different what I understand and correct me if I'm wrong So when you're dealing with How much time do you put towards auditing and compliance? How much time do you put towards training and best practices? How much time do you put towards doing a threat modeling? Is that kind of a summary? Good So when you're dealing having those learning opportunities where you're saying that we're just not making you do this because we hate you We're doing this because we love you and we want you to grow Which threat modeling sometimes gets that way so Most of the time making sure to reiterate making sure to be open when they are hostile So you go into a dev team and they're First thing you want to let them know when you're the first time they have to go through a threat model They say that you're here to help you hear it in order to make it easier This is going to be a team sport, but then you want to make sure and stuff that Kind of try to carry them at the beginning go to the extra mile be there for questions be there for Walking them through it, but then also be able to point them to some good resources They can find on their own so the best practices and training side And then at the same time Being able to just actually tell them You're going to be audited later at some point You're going to be audited and this will help make it so that those are easier so you don't have to worry about that as much That helps with the app dev managers too because app dev managers don't like dealing with audits The downside though when you're talking about threat modeling sometimes they don't see the importance of it Sometimes they're hostile towards it or at the resistant And so get a chance in order to try to make sure that their managers are involved and that they understand that there's a Value added to the team and that's where it also helps with documenting the systems Because if they create a threat model and the data flow diagram and you say that that's good enough for their application diagram It helps them go wait. I don't have to create more documents I could just create that and then check it in with the code and I'm done please That's a very good point so sooner the development lifecycle the better Good example, we had a privacy office come down with their own system and so the developers were screwing in order to look good to the privacy officer and They sat down and they finally listened to me I'm like do it at the very beginning before you write up the system because that far too often they start coding They would have something in QA. They'd possibly have something in production and then they go wait a minute We're supposed to do a threat model on this, weren't we? that happens and so As soon as they know what they're kind of a concept of what they want to build Do the threat model right there at the very beginning and it's going to be much easier on them It's going to be much easier on everyone because it's no longer now a stop cap It's no longer a hurdle that they have to jump through. It's now just part of It's like a guide It helps them get a better picture of what they're going to be building how they're going to be coding it And so usually they actually like the threat model at that stage opposed to being resistant to it So, yeah, please The way I explain it to work You have your conceptual diagram of your system and then different features could be added on without actually changing the conceptual diagram But if there is a feature change that does change, that's when you want to circle back and revisit the threat model During the threat model conversation, we don't usually go all the way down to the weeds Usually we're talking more conceptual high-level, but by having the data flow diagram They actually know a little bit better what their process is going to be like and so we could talk about them when we're addressing the high-level stuff So it's a chance to be more familiar with like how is that function going to happen? How are we going to authenticate? How are we going to log? What events are we going to log? So those things are already been talked about in the meeting And alongside in there The developers always have my phone number, so they usually reach out, but that's a good point Yeah, if you're dealing with an external, sorry, the question was this for every process Do you have to necessarily have it in the threat model or you could go higher lab? If there's an external interactor, so you're dealing with it someone else's API You want to make sure that's captured because every time your system talks to someone else's that you want to make sure it's on the Diagram is a external entity But when you're dealing with the system itself usually what I tell folks is to aim the data flow diagram world Somewhere between a level zero and a level one to keep a high enough level to where it's not 5,000 threats. It's usually more like a hundred threats that you have to go through What is it happening is you could go all the way down into the weeds and talk about each and every function And you could diagram it and you could put it into like third modeling tools Or you could sit down with the matrix and identify all of them And it becomes bigger than the project itself. And so you end up having to go through a lot more paperwork a lot more Mitigations and you have to document so much that the whole team kind of gets bogged down But by bringing it back up to like a level zero level one right in there and enough in order to know kind of the main functional areas Like this is our web front end our web server area We're going to have our web services here and then we're going to have our data store in the back And so you have understand how the system flows and then you can talk about how you're going to deal with authentication with your authorization with Something like your logging with See what else also redundancy Resilient systems like load balancing different ways of handling the potential denial service attacks how those configurations are going to be When you're doing your whiteboarding What did that then need to software that could you know, you currently get higher and higher jail? Yes, it's very good point So I'm not as familiar with the the ratings as much but by having it done You could actually check that off. You could document it You could show it in an audit or review and so that helps when you're dealing with Trying to show it like auditors or trying to get ratings on how secure the systems are Yeah, because going through the steps being able to show that you've gone through the steps And especially when it comes to an audit But most importantly being able to talk through the with the development team be able to work with them And on how they need to improve their controls to make the systems more secure Yeah, it's a team sport you learn from the developers just as much as they learn from you And you get a chance to figure out how they approach the different issues any more questions So I have some additional resources again the slide deck is already posted on the tour site I have some threat modeling tool download Microsoft's secure development lifecycle resources and then also a book reference This is a pretty good book on threat modeling that I found before so Thank you very much for your time and have a good tour camp