Robert Hurlbut -- Threat Modeling

0:05Chris RomeoThe Application Security Podcast. Here we go. Hey folks, Chris here. Robert and I are both at AppSec USA this week in Orlando, Florida. And so for this week's episode, we bring you a recorded conference talk that Robert did on the topic of threat modeling. In this talk, Robert goes into greater detail than we've really even gotten into here so far on the AppSec Podcast. So we hope you enjoy.

0:50Robert HurlbutToday we're going to talk about threat modeling for secure software design. And just a little bit about myself, my name is Robert Hurlbut and I'm actually coming in from Connecticut. That's where I live, that's where I work, but I also do a lot of work across the country as well as here in Ohio. I have some family in Cleveland, I'm in here all the time. And one of the things that I focus on is software security. And as you can see there, I've, you know, I have my own company, I'm independent, but I help a lot of companies, a lot of teams understand some of the issues with software security and how best to address those issues. That's my contact information there at the bottom. I have my website, roberthelmut.com. I'm also on Twitter if you're interested, take a look and see what's going on there. I do talk about threat modeling and other security issues out there today on Twitter. So you're welcome to follow. So to start off with today in talking about secure software design, just out of curiosity, I want to have an understanding of my audience. How many of you are software developers by chance? Okay, a few of you. How many of you perhaps manage a software development team? Okay, a few of you. How many of you are in some way impacted by software in your company or security with that software? Okay, a lot of people, a lot of people. And I think that's true of a lot of companies. We're really seeing it as an issue more and more. You know, before we would develop software and security was more of a byproduct. It wasn't something we thought about from the get-go. We added it on later because we said, oh, well, we probably do need a login form of some sort. We do need a way to check, you know, if people have access or not. And we did that after the fact. You know, we said that was the last thing we're going to do. We're going to run everything initially almost wide open. And so it became something we did later. Well, it turns out, you know, when you're thinking about secure software design, You find out very quickly building secure systems is difficult. It's not easy. You know, and we've been, you know, writing software, we've been building systems for a while, and if you've been doing that for a while, you've also noticed, you know, thinking of all the potential issues within a system from a security standpoint is not the easiest thing in the world. But one of the things that's key is design. Understanding your system and how it's put together and designing it appropriately, accordingly, the way it should be in terms of security and other features early on makes a difference. And in fact, one of the things we're trying to do here is building appropriate security. That means secure but not hindering people from doing their work. You know, allowing people to be able to use the system but not be so locked down that they can't do anything But at the same time, making sure that we're checking things and we're— we have the proper access control and so forth. And the best way to do that is, again, through secure design. But then the question becomes, well, how do you do that? And maybe even some reasons that you might wonder today, why even care? Why do we— why do we do that? Well, let's look at some examples of breakdowns. GitHub mass assignment. This is something that happened a few years ago. I don't know if you know about this, but GitHub, you know, you can have projects on there, repositories and so forth where you can store your code and check it out and so forth. Well, it turns out that there was a particular developer a few years ago who wanted to make some changes but he didn't have admin privileges. And he happened to notice— and GitHub is running on Ruby on Rails— he happened to notice that he can actually send code or a model, if you will, because they're using the MVC pattern, Model View Controller pattern, that he could send in a model where with a flag that's something along the lines of isAdmin, true or false, he can actually raise his— elevate his privileges. And so that's what he did. He simply set isAdmin to true, and lo and behold, he's able to get in and do what he needed to do. Now, he also did that with a few other accounts just out of curiosity. Hey, this is great. I can actually elevate my privilege. Hey, this is bad. I can elevate my privilege. Anybody can do this. And in fact, it was found— fortunately not a real attack that happened— But it was found that potentially lots and lots, thousands of projects could have been compromised the same way. Now, that was a vulnerability, but it was also a design flaw as well, that here's this thing in place, we have binding, and by simply compromising this through an attack, somebody could, you know, create all kinds of havoc. That vulnerability is still there whether, you know, you know it or not. For example, in ASP.NET MVC, that's still there. There's no way to protect against it other than know it's there and design for it and protect against it, okay? It's just there. So I can use that to change payments or, you know, prices on items. Just, it's there. You have to protect against it since it's input validation. It's a design issue. Another one, as we saw last summer, was the Jeep Cherokee hack. How many of you know about that?

6:50Chris RomeoOkay.

6:51Robert HurlbutThere was something that recently came out I saw on Twitter where 1 in 4 Americans have forgotten about this, or only remember it rather. 3 out of those 4 forgot it. But believe me, 4 out of 4 carmakers still remember it very well. If you remember, 2 guys found out that through the entertainment system, they are able to get out into the internet or vice versa, the internet through having an endpoint and being able to control through the entertainment center system the car itself, which included, you know, turning off the car, speeding up the car, and other things like that, which of course again is really bad. But that's a design flaw. Somebody, for whatever reason, hadn't thought through that, oh, if we allow that opening in, it might potentially turn into an attack. Fortunately, no one was harmed, and certainly a fix came out very shortly after. In fact, I remember I was at Black Hat and DEF CON this past year, and I saw the presentations, and shortly after or a little before, Chrysler came out with a fix. But again, design issues. The last one I want to mention is Target. Now, it's not software-specific, but it was a design issue. You know, why do you give a company full access to your network? And that's what happened through HVAC system or through an HVAC company. They had full access to the network and then the attackers then could come through that way and to the rest of the system would look like their HVAC employees. Now, again, not software-specific, but it is a design problem where we didn't localize the particular access, okay? So, lots of design issues, but as I think about it and as I like to talk about, you know, what we're missing here is when we're thinking about secure design is also thinking about the threat model that's attached to those things. So, let's talk about threat modeling. Well, threat modeling is something we already do in our lives. Anytime we lock the doors to our house or lock the windows or lock the doors to our car, we're already thinking about these things because why? We're already thinking about, well, potentially if I leave my door open, somebody might come in and get my things. If I don't lock my car door, somebody might come and take my car Or if I leave things sitting in the car seat, somebody might see it and take it if it looks valuable, right? So we already think about these things in terms of what could happen, right? What could go wrong? Weigh the risks and act accordingly. And actually, believe it or not, when we're doing that, we're already doing a kind of threat modeling. We're going to talk more about that today.

9:46Chris RomeoOkay.

9:47Robert HurlbutSo some things that I think threat modeling will help you do, and this is in particular especially with application security, is it helps the builders, the breakers, and the defenders. Do any of you maybe put yourself in any of those categories? Breakers, builders, and defenders? The builders basically understand the security features and be able to put those in place. The breakers know what the critical attack surfaces are. And the defenders to understand the critical attack patterns. That includes intrusion detection. You know, what is it that, you know, is most critical in our system? It also, I believe, helps with all kinds of other areas in security and business. You know, this is really trying to solve many, many problems and ways to do it. So where does it fit in? Well, it's one of the security tools, in particular application security tools, but it's also in many other applications as well. We already know about these tools that are automated, pen testing, fuzzing, analysis, detection, and so on. But threat modeling really is a tool that's a thinking tool, if you will. It's a process. It's a tool, as I mentioned earlier, that I believe can help with secure system and software design. And it's not automated though. There are some tools out there and we'll talk about those. But it really is a thinking tool, a way of thinking about your system. So, as I mentioned, it's a process of understanding your system and the potential threats against your system. A typical threat model will include the understanding of your system, the threats that have been identified, the probability of those threats. In other words, you know, how likely are they to happen? the potential harm or impact. And then along with that, you should have a priority and plan for mitigating those threats based on the risk that you've identified. OK? I have a couple quotes here. I like talking about these because I find this true many times in my own experience in working with software development teams. A dev team with an awesome and complete and accurate threat model gets my admiration and not much of my time. Really because they don't need it. And that's from Michael Howard who wrote Secure Code 2 a few years ago, works at Microsoft. Another one from Brooke Schoenfield who wrote a great book on threat modeling last year, came out last summer. As I practice it, threat modeling cannot be the province of a tech elite. It really is best owned by all of the development team. And that's how I practice threat modeling as well. I don't think of it as just something, you know, the consultant only knows. But when I come into a team and help a team, I'm trying to help everybody understand about threat modeling because I believe it's something that we all need to think about. And as I mentioned to you earlier, it's something we actually already do in our everyday life. But how do you apply that then to developing systems and securing systems? We'll talk some more about that. Some quick definitions. Threat agent is just someone or a process that can do harm to your system. A threat is essentially the goal. You know, what is it that that adversary wants? What is it that they want to do? Now, that's different than a vulnerability. A vulnerability is the flaw in the system that allows the threat to be realized, okay? Does that make sense? So, I may have multiple vulnerabilities. I may have a SQL injection vulnerability. But perhaps it's buried somewhere deep into my system that nobody actually has access to. But if that vulnerability is actually available and accessible on my website, then what an attacker can do is use that vulnerability to access my database, go all the way from the front end to the database, and perhaps collect credit card information or other kinds of database information. That's a threat. So that's the difference. The vulnerability is what allows the attacker to enact the threat. So very different. And we do focus a lot on vulnerabilities. There are analysis and scans and so forth. But the threat is what actually makes use of those vulnerabilities to then plan the attack and actually carry out the attack. And of course, the attack, motivated and skilled. sufficiently skilled threat agent takes advantage of the vulnerability. And that's kind of important because you have to think about the motivations and also have to think about the skills. And that kind of comes into the attacker profile. Years ago, we talked about script kiddies and how they would take things off the internet and run them. And they have no idea what it does, but it sounds fun. Let's try it. And all the way up to state-sponsored criminals who are using very sophisticated attacks against our systems, various ways of compromising our systems and taking sensitive data. So all of those things are still attacks, but it's interesting to see based on the motivation and how much skill they have, how those attacks change, and that can also impact how we build our threat model as well. Asset, anything of value. And maybe even further, anything that you're worried about losing. That's a big thing there. So when do you do this? Well, threat modeling really should be your first priority. I believe in SDLC, if you're following any kind of software development lifecycle, it should be one of the first things that you do. And that's where it really fits. in the requirements and design phase. You know, when you're starting to build your application and, you know, believe me, I understand. I've been doing this for 30 years. I know what it is like to be sitting down and looking at a screen and saying, you know, let's just build this and it's a prototype and nobody will ever use it. And guess what? That thing becomes what? It becomes the main application for the company. And you go, well, you know, we never really thought through it. We never really, Well, this is where you need to take a step back and start looking at, well, how is this going to be designed and what are the security implications of this? The other thing is that threat modeling will also help uncover requirements, and that's actually what threat modeling is also about, is helping you understand security requirements that you have within your system. You know, some people say, well, threat model is just the architecture part. That's only one part of it. But it's not your architecture. Threat modeling determines what your requirements are security-wise. You can also make threat modeling a part of your agile sprint planning. How many of you are familiar with agile methodology and following it currently? Okay, excellent. You can also do this in a sprint planning session where at the very beginning you're building out your features and you're understanding, you know, what are the various pieces of this. You can also apply the question, what's our threat model? What are the security implications of this feature if we put it in place? So, a great place to do that as well. Now, what if we didn't? And unfortunately, I get more calls about help for threat modeling not on the other slide, but on this slide. What if we didn't? We built it, we put it together, it's running, it's been out there, And now we're all of a sudden we're getting some problems, you know, some security issues. You know, authentication is not as good as we thought, or authorization is not as good as we thought. What do we do? And I always say, you know, it's not too late to start, but realize, you know, it has, you know, some consequences with it. For example, it will be pretty difficult to change major design decisions. You may have made a decision way early on that was just completely wrong, but at the time it made sense. And then you get all the way down and say, okay, now we got to think about security. Uh-oh, well, now I got to redo a few things, and that's expensive. So ideally, you want to do that at the beginning. But even if you didn't, I always say do it anyway. Always make it a part, even if you're starting from scratch and you've not done this before, I say still do it. think about it, applying threat modeling to your own system. So a typical session that I'm involved in and like to help companies when they start thinking about threat modeling is, first of all, in a typical session, you would gather some documentation. You would gather the people that have knowledge about your system. This is your developers, your QA, your architects, your stakeholders, your managers, other people that have some investment in the system, have some knowledge in the system, and just start asking questions and understanding, you know, what are we doing? What have we built? How does this work? I find this is great because not every— or not just one person knows everything. And certainly as a security person within your own organization, perhaps, you may not know all the ins and outs of how that system was built. So don't make it one person's job. Don't be the threat modeler person that goes off and tries to figure this all out. As much as you can, try to gather a team. Understand the business goals and technical goals, which may, may, may not be the security goals. I remember being in a situation where I was helping a financial company, And they had 2 sets of users. There were regular users and there were managers. And we were talking about putting 2FA, 2-factor authentication, in place. And what they said to me was that, well, you know, that's a great idea, but our users, you know, we don't want them to be bothered with that. But the managers, because they manage multiple accounts, that makes more sense. Now, my security goal was you probably ought to have it for everybody, but for them, At that time, they said, well, that's not our goal. Our goal is the managers are the ones we feel are the most significant and critical. Let's get it in place for them and then we'll look at putting that in place for the users. So, a little bit of different goal, but that's the key. Understand your business. What is it your business does? What do they want to do? Understand those goals and how that works and supporting that. Threat modeling must support those goals as opposed to the other way around. Technical goals, understand your environment. You know, a Java system has its own set of security issues and security environments, a .NET same way, other systems as well. All have certain environment— environmental things that are in place for security or not in place for security. So understand those and why do we choose to run it on this system versus another system.

21:00Chris RomeoOkay.

21:00Robert Hurlbutsystem, in the cloud now versus not, and so on and so on. They all impact how we build our threat model. And also, as we talk about a little bit later, about the risks that might be involved with those decisions. Agree on meeting dates and times. And I usually say about 1 to 2 hours at a time, because if you try to do this for an entire day, one, your team is going to get just overwhelmed. I'd say have a focused time, 1 to 2 hours. And then most important, be honest, leave ego at the door, and no blaming. You know, when you're looking at these things, especially if it's after the fact, it's so easy to say, oh, you know, why didn't we do that? Why did we miss that? Don't do that because the point is of all this is we're all on the same team, we're all trying to accomplish the same thing, is to secure our system. So please leave those things at the door. Okay. To the side and get focused on, you know, where are we today, let's figure it out, and how can we then go forward and make this secure, okay? So, simple tools, I like a whiteboard just to document it. You can use Visio or Word, Excel, and so on. Great, great tools. There are also a few other tools out there you can use as well. There's one from Microsoft which I have a reference much later. In the deck, but I like this one. Dennis Cruz just came out with a simple threat model one-page just to get you started, and unfortunately you can't see that well, but it just mentions, you know, what's my diagram and threats and so on and so on. I also like this one that I've used with a few customers, is just have an Excel spreadsheet and just start documenting my risk level, which we'll talk about later, threat description, countermeasures, and then the follow-up. Very, very simple. You know, getting together, drawing on a whiteboard, what's our system look like, where are the issues, and then documenting it, okay. So to start off with, with your team, one of the first things you want to do, I think, is to review your security principles. And this is important to make sure everybody's on the same page and understands, you know, we're talking about a secure system here. Well, how are you going to be secure unless you know what it means to be secure. What are the baselines? What are the actual things that need to be in place? Secure weakest link, defend in depth, a few there, a few more, do not share mechanisms, assume secret's not safe, promote privacy, use resources, okay. And these slides are available if you want to look at those and I have a reference there. Another great resource I've seen over the last couple of years is this one that came out from the IEEE Center for Secure Design, Avoiding the Top 10 Software Security Design Flaws. And their approach there, a bunch of companies got together and put this together, and their approach was not just focusing on the vulnerabilities, but focus on the flaw that causes the vulnerabilities. So this is another great short, small book that you can hand out to your team to, again, understand some of the basic security principles before you get started. Okay, so here's the process that I follow, and more or less others follow the same. It breaks down, you know, like I said, very similar to what others are doing as well. But essentially drawing your picture, drawing an understanding of what you have in your system, identifying those threats, determine the mitigations and the risks, and then follow through. And follow through is an interesting point because I don't see everyone always doing that. And so I like including that as well if you can follow through after you've done the work. So draw your picture. Now, this one is just a typical web application, a browser, a web server. It doesn't tell you a lot, but it gets you started. It helps you start understanding, well, what's in our system? And obviously this is a pretty simple one and you may have many, many more things going on. But the first key thing is start drawing on a whiteboard. What is it our system is doing? Now, another thing that you can use are data flow diagrams, and these are some nomenclature for it and some ways to draw these things, the entities, the processes, stores, and trust boundary. But whatever you choose, come up with a way, in a simple way, that you can communicate with others. Here's what's going on, here's how things communicate with each other. And the reason you focus on— and typically we focus on data flows— is it turns out that when data flows from one entity to another or one process to another, that actually turns out to be one of our most vulnerable places. Think about it. When we are on a browser connecting to a web server, what are we sending? We're sending credit card information. We're retrieving account information, we're making changes. The browser by itself does nothing. The web server does nothing. But it's that communication between the two, the data that's going back and forth, that's pretty sensitive. And also where that data gets stored, pretty sensitive. So, those are some key areas and that's— those are the things that we need to be aware of and be sure to secure. So that's what we call data flow diagrams, is to try to understand the data flows between those systems. So in understanding the system, we want to understand the logical and component architectural— architecture of the system. And again, as I mentioned, the communication flow between those systems. So here's an example of users. I have admin and server. Now this is a very high level. But, you know, request-response settings and logging data and then a trust boundary, very simple. And again, this is just a high-level view, but what you'll probably do is go a little further into the system and start breaking it out. And notice now we've got some user admin, of course, the web app, audit service, other services that are there, data files, credentials, and so on. And then you start labeling them. Well, what's going in between these 2? How are they communicating? And then also you define some trust boundaries. And of course, trust boundaries just simply mean that I'm going from one state to another of trust, so a user may be unauthenticated and now they're authenticated, and once that has happened, you know, what happens with inside that perimeter? Along with that, you would identify You know, what are my entities? You know, what are my services that are running? What happens with the data as I store it? You know, what are the flows? So these are just some things that you want to think of as you're looking at your system and understanding it. And believe me, you're not going to catch everything, you know, maybe the first pass. And one thing I like to say to, you know, teams that are trying to figure this out for a big, big system is, Don't try to take it all in one shot. In fact, I would say typically take 1 or 2 services and figure out the threat model for that 1 service or 2 services. And then take the next one and see how that's connected. And what you do is you're building on and kind of like an onion unfolding it and seeing how the whole system works rather than try to take it all at one shot. And you'll see, for example, the authentication service works with something else and then it works with something else, works with something else. And eventually you will get most of the system. And that's a great way to digest it. So now your threat model consists of a diagram understanding of your system and the data flows. Next is the threats. Now, it is the most important part of this. It is called threat modeling after all. But it is also the most difficult because how do you identify the threats? our system? Well, there are some tools and I'll talk about those. Attack trees, Bruce Schneier has a pretty nice slide deck he wrote many years ago. Attack trees essentially are just a way of, you know, kind of a flow. Here's my goal, how do I get there, the various paths to get there. And there are all kinds of attack trees that have been created for websites and other kinds of attacks that an attacker might use. to traverse to get to their goal. Hard to write, which is why a lot of them have already been premade, but that's one way to think about these things and understand some of the potential threats. There's some threat libraries like, for example, CAPEC and OWASP Top 10 and so on. You can take a look at those. There are ways to kind of help you think about these things. Checklists, checklists are not so bad, at least to get started. How many of you are glad that the pilot has a checklist before you take off on the plane? plane. Yeah, right? They're not bad. They really help you start thinking about things you may not have thought about regularly, right? So don't throw out checklists. And there's a few there. I really like the ASVS from OWASP, a great tool of lists of questions about what is it in our system that we need to think about from a security standpoint do we have in place. And then recently they just updated the proactive controls. 10 things that answer the OWASP Top 10. Here are the things that developers need to think about when you're building systems. So again, some checklists. Use cases, misuse cases. If you've been in software or done any software development, a lot of times people will focus on use cases, you know, how do people use our system? We don't always think about misuse cases because we think, you know, I've talked to teams and they say, well, you know, what happens if this, you know, somebody does this? Well, nobody would ever do that. You ever heard that before? Why would anybody ever click on that button? Why would anybody ever do that? Well, that's a misuse case and it's important to look at those as well. There's a couple of games out there, Elevation of Privilege, OWASP Cornucopia, I'll talk about that in a moment. Stride is another fantastic way and I'll look at that in a moment. PASTA actually came out in the last few years. It's an actual 7-step process that includes not just STRIDE and risk analysis, but also attacks. They include within their threat model simulated attacks. So it's not just a theoretical thing about what might happen. They also include an actual attack that they've demonstrated that it could happen. If you're interested, take a look at it. POSTA, Process for Attack Simulation and Threat Analysis. There's a nice book also that came out last year on this as well. Okay. So STRIDE originally came from some guys at Microsoft back in, I believe I've seen the original paper around 1999, but it really came into more, I guess, in the public, if you will, around 2003, 2004 when there was a book that came out on threat modeling where they talked about STRIDE. Now STRIDE is is really a mnemonic. It's not necessarily categories. It's a mnemonic, a way of thinking about these things. There's spoofing, there's tampering, repudiation— basically, did I do what you said I did?— information disclosure, denial of service, elevation of privilege. The way to counter that is, of course, authentication, integrity, non-repudiation, which is usually done by logging, confidentiality, availability, and authorization. Now, if you notice, the confidentiality, integrity, and availability, that's the CIA of security, right? Have you heard that before? And then, of course, the 2 A's, authentication and authorization. So, that's really all what STRIDE is doing, is just trying to help people who are new to security or not that familiar with security try to understand some security concepts here.

33:21Chris RomeoOkay.

33:22Robert HurlbutAnd ideally these apply to your data flow. And it's again a great tool to start thinking about what are the potential kinds of threats that might be in our system. There's also this OWASP Cornucopia, which is a game that focuses on a few areas here. And simply it's a game that you can play with a round and everybody gets about, I think, 5 or 6 cards and you have your diagram out there. And someone picks a card and say, you know, this is a, you know, 2 of authorization. And they read it and say, does that apply to this situation? Yes. Put it down. Somebody says, hey, I'll meet your 2 of authorization with a 5 of authorization. Oh, you know, put it down. And whoever puts down the highest hand or highest value wins. Now you can cheat. Don't worry. It's just a game. It's a fun game. But it's a way of learning about this as well. Because at the bottom of each card it will tell you the— perhaps that particular threat or that particular issue, where would you find it in OWASP Top 10, where would you find it in CAPEC, where would you find it in ASVS. So it's a great way again of getting familiar with security topics, especially for those who are not familiar with security. So it's a cool game. Other ways that you can think about threats in a functional way, you know, my input and data validation. We already talked about the 2 A's, configuration management, and I have an example here in a moment of that. That's a pretty hot topic and doesn't get enough attention, I think. Some other things, session management, cryptography, exception management, auditing, and logging. What I like to do is ask questions. When I'm with a team, I'm just asking questions. They've got their diagram up there and we've already talked about the security principles. And I encourage people to ask questions. Who would be interested in this? What kind of attacker, what kind of user would be interested in looking at what we have here? And what are the goals, the assets? What are we trying to protect? What are the methods that they might use? And are there any attack surfaces that we may have missed? Some other questions, authentication, authorization. And so on and so on. One of the best questions, is there anything that's keeping you up at night? You'll be surprised the answers you get on this one. Oh yeah, there was a button that we put out there, it's hidden, we used it for development, we forgot to remove it, it's still there. Or, yep, there's that ID 53. Don't ever, ever, ever put 53 as an ID because you'll have Keys to the kingdom. We forgot about that one. We kept that out there. All kinds of answers, but it's an interesting telling question and answer with it about, well, what is going on in our system or what did we forget? So let's talk about configuration management, a particular scenario. This is my diagram I had earlier. If we look at, you know, example configuration management, let's say here data files for the web app, configuration files. So our system is— that we've diagrammed is a web application that uses configuration files. Some basic security principles that we already should know about and be thinking about is be reluctant to trust and assume the secrets are not safe, all right?

36:57Chris RomeoNow, questions?

37:00Robert HurlbutHow does the app use those configuration files? And out of curiosity— and actually, maybe don't hold up your hands. But one of the things I found is in a lot of systems, everybody trusts the configuration file, right? We do a really good job, or at least try to, of validating all the input that comes in through the site, but we don't always check the configuration file. Guess what? It's still input. It's still input to our system. What would happen if somebody changed a website to point somewhere else? What would happen if they changed a password? What would happen if they changed all kinds of other settings within your configuration management? What would your system do? How would it react? How is it checking those things? How is it testing those things? You know, not everybody thinks about those things.

37:51Chris RomeoYeah.

37:53Robert HurlbutWhat validation is applied? Is it implied trust? So possible controls and mitigation that you may come out of this, that come out of this, set permissions on the configuration files. Again, it matters. Now, invalidate all data input from the files, use fuzz testing to ensure input validation, okay? The other thing about this is we'll talk about in a moment, is this also applies to where does it sit, you know, where does our web server sit? Do we own the box or does somebody else own the box?

38:27Chris RomeoOkay.

38:28Robert HurlbutSo, you've identified threats through the answers to questions. Let's talk about mitigation options. And let me look at our time. Oh, we've got a couple of minutes here. Leave as is, just leave it. We know it's a problem, leave it. Remove it from the product. You know, there's— We know there's a problem there, we're gonna remove it and just not make it available, this feature. We remedy it with a technology countermeasure, which is, you know, the ideal thing. If we found a problem, we found a threat, we need to put in place the countermeasures. The other one is just warn the user, which is what I call, or better known as, pass the buck. You know, just let somebody else deal with it. You know, we'll give a notice, hey, by the way, if you use our system, Your information may be compromised in certain situations because we're not protecting whatever. That's letting you know, and that might be buried deep, deep, deep into that, you know, the agreement that you clicked on. Remember when you installed the software that everybody reads, right? One of the biggest lies in security, everybody reads those agreements. Just warn the user. So, those are a few ways we can decide how to mitigate. But we need to understand the risk. So talking about risk management, there's a bug bar, there's the FAIR approach by Jack Jones and Jack Freund. He— both these guys, Factor Analysis of Information Risk, actually a great book on that. It's a more comprehensive risk analysis and risk management and even some threat modeling. And I know some companies that will use this alone where A threat is only identified by the thing that you lose. If you don't lose it, it's not a threat. So it's an interesting way of also managing this as well. One of the ways I like is just, you know, use the simple risk rating of high, medium, or low, which is based on— oops— the ease of exploitation and the business impact. The ease of exploitation is if anonymous users can exploit the issue, it's high. If you need to know things about the system working tools and so on, then it's probably low. If it's hard to do, it's low. Business impact, if all users are impacted, that's pretty high. If a significantly low number of users are impacted or the possibility of harm here is very low, then it's a low. You put those together and you determine what is our risk factor here, a risk level. This is an example medium threat risk, risk threat rather. It's CSRF. Here's a description of it. We need transaction codes, thresholds, event visibility, and so on, and identifying the components that are affected. So that's our threat model. Following up on our scenario with configuration management, the data files, What's our risk rating? Well, again, it depends on where we are, and that actually affects our threat model. So if we own the box, it might be we identify medium-low. We own it, we're monitoring it, we're not worried as much. If it's hosted on the cloud or somewhere else, it may be a higher issue. It may be an issue that we need to think more seriously about because we don't own it, we don't know who's changing these things, we don't know who's looking at these configurations, and if they do change it, and change the look out, you know, the look and feel of our site, how would we know? So that may be higher in the risk. So then this becomes our threat model. Does that make sense? That's what we're looking at as far as the principles, the questions, the mitigation, and the risk, and that can then determine our priority. What do we do with this next?

42:14Chris RomeoOkay.

42:15Robert HurlbutSo now we've identified the mitigations and the risks involved. Finally, we do follow-through. We document what you found. You file the bugs or new requirements. If you find a problem, if you find a threat, that's a bug in an existing system. If you've never implemented that feature, that's a requirement. That's what threat modeling helps you do. And then ultimately verify those are fixed or verify that requirement— or that feature rather is now in place. And the mitigation is in place. Now, you've gone through this whole exercise. When are you done? That's always the question. Wow, this is a lot. When are you done? What's the answer? You're not. You're not. But at some point, you do have to say, we've got as much as we know now. And then make it something that you continue to revisit time and time again. For example, in the sprint planning and so forth. So if we miss anything, review again and you update. If there's anything new, you review again and update. So yes, we may never be done because there are always new features, there are always new things out there, there are always new vulnerabilities that people are finding. But the key is when you start this process, you'll find out as you go along it becomes easier and easier and easier. Threat modeling becomes not just a thing that we talk about, but a thing that we do. It's a thing that we think about all the time. We're not just looking at the system as, well, that's, you know, a big blob of something, I don't know what it does, but instead looking at it as, hey, there's a threat model issue there, there's something there. And when you have a team that you're working with and all of a sudden when they're looking at something and not you as a security person say to them, Or they say to you rather, what's our threat model here? And you know you've done a fantastic job and they're getting it and that's a great feeling. And that's something I hope for everybody. So here's our 4 things. Ultimately we have a living threat model. This is not something you just do and throw away and go do something else. But it's something that I hope that you make it a part of what you're doing in your own work. And make this a tool that, something that you use regularly. Then ultimately, again, following through and turning into something that's alive, it's living, it's continuing to evolve. Because as others have said that I've talked to, threat modelers, threat models essentially are fractal. We may not know everything at first, but as we delve into this thing, we'll know more and more. And ultimately, it just helps us to be better at security and understanding our system better. So your challenge, use threat modeling for secure design before new features. Also, let it drive your testing, you know, help— it can help you to know where you need to focus that test, those tests. And then it helps you really understand the bigger picture. Because as you look at everything and you unfold the onion, you then have a much, much better understanding of your system and what you're building. So some books, you're more than welcome to take a look at those. I recommend all of these for threat modeling, they're just fantastic. They've come out in the last couple years. A couple tools, there's the one from Microsoft, there's another one, Threat Modeler. They're not automated tools. Now, Threat Modeler will— you can point it at a system and it will get you started, but ultimately, what did I say at the beginning? This is a thinking tool. These things won't just magically produce something for you. That's not what this is about. Every company is different, every scenario is different, every application is different, so you really have to spend the time It is what it is. You have to spend the time and think about your system, but believe me, by the end of it, using whatever tool you're using, you'll definitely know it better and you'll have a little bit more confidence about the security posture of your system. So, some more resources, some links, and so on. Thanks for listening to the Application Security Podcast.

46:44Chris RomeoThe intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Kartenberg.

46:50Robert HurlbutYou can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.