— This post is part of a series of blog posts about all kinds of Security topics for Developers —
Threat modeling is a process which far too few developers know about. It is a process that does what the name suggests: It helps you to model all threats to your application. Basically you make a list of threats, but in a structured way, such that you can assess the risks, and decide what to do about them.
Why do I need to do this?
I guess you can imagine the ‘why’, but since not many developers use threat modeling, I’ll try to explain it nonetheless. First of all, if you don’t know which threats there are for your application, you cannot do anything about them. It’s always better to know in advance and decide you accept the risk, then it is to regret after you lost half of your customers because of a security breach.
Although this is a security blog, and security is perhaps the most important reason for threats, issues can also occur because of more natural causes, like power outages, a flooded server room, or a disadvantageous bus factor. Those can be serious threats to your project too, and therefore to your company.
The last reason to do this, is simply because it’s fun to do. It fits the type of developer humor to poke holes in their own creations through all kinds of unrealistic scenarios. But while doing some of the brainstormy steps, you’ll also come across more realistic threats. We noticed that when someone came up with a totally outrageous and silly idea to extract data from our system, other people noted that it wasn’t so farfetched after all, and sketched out a quite reasonable approach to attack us.
When to do the modeling?
Typically, the best moment to do threat modeling is at the beginning of a project, but in practice you can choose any moment. Better to do threat modeling halfway or at the end, than never at all. An advantage of doing so near the end of the project is that you know the architecture and all the data flows much better, so it will be easier. A disadvantage of course is that it may be more work to fix bad design decisions.
If you’re new to threat modeling, I would still recommend to do your first session on an existing project. That makes it a lot easier to ‘try’ a threat modeling session and familiarize yourself with all the steps. You have a much clearer picture of all the assets and flow of data and probably that makes it a bit easier to think about the risks. Once you know the process, you can try this out in a new project to address the threats already in the design phase.
Over time you will notice you already take into account many threats while thinking about the initial design of a new feature.
Let’s get started
There’s different ways to approach the threat modeling session, and it totally depends on your company. If you’re in a big company, probably there’s already a strict formal process for doing threat modeling. Therefore, I’ll assume smaller companies or individuals who are new to threat modeling. OWASP has a nice cheat sheet for this, although it seems a bit long and abstract at first. I find the steps in decomposing and modeling the system the most useful.
I’ll discuss the relevant steps in more detail, because I guess that’s the most practical guideline for others to get started.
Identify the trusted boundaries of your system
This step will likely already cause some discussion, which is good. Here’s some of the things we consider:
- Do we only look at software, or do wo also include the infrastructure?
- Should we include the reverse proxies or the firewall?
- What about our orchestration software? It’s managed by another team, so it’s mostly out of reach for us.
Often it doesn’t really matter what you include, as long as there’s consensus in the team, to avoid unnecessary discussion later. In later steps you may find that you still want to reconsider the boundaries. That’s fine, but if you do, don’t forget to look at the steps in between to see if the changed scope influences them.
Perhaps a bit boring, but it’s important to know who are the users or actors in your system. These can be the regular end-users or administrators with browsers, but also hackers with apps or other tools. And what about those disgruntled colleagues? Missing a group of actors means you will probably miss a whole category of threats too, so make sure you don’t miss anyone. You may even want to split the group of hackers into script kiddies, professional hackers and governments.
Add information flows
Here we’re going to make a list of all the different types of data that flow through the system. E.g. you can make a list of all types of authentication tokens and cookies. For each piece of data, you’ll want to know where it goes. What components does it touch? This is important to later find out where the data can leak. The more components use the data, the more opportunities for a hacker to get access. E.g. session cookies are usually not needed behind your authentication gates, but often they are still available.
For each type of data, there may be different flows, depending on the situation. E.g. our Authentication service creates the Sessionids, but after creation they flow both to our Session store and to the cookie store in the user’s browser. Also, for each request from the user’s browser, the cookie is sent along and goes through several components again.
It may happen that already during this step you see a flow that makes you frown. Although we’re going to look at threat assessment in a later step, you might want to take notes here already. We find that while creating the information flows, we came up with half the threats that were on the final list. So, this is where the creativity starts.
Perform threat assessment
If you didn’t do so yet in the previous step, now is the ‘official’ moment to look at the information flows. For each type of data, for each flow, see if there are opportunities for any of the actors to get hold of some valuable information.
You may also include ‘threats’ like losing data after a disk crash, because of a lack of redundancy or backups.
Add a probability value to each threat
Now that the list of threats is complete, we can have a look at their likelihood. Maybe you included some of those very unlilely, improbable or exceptional situations that will only occur when Jupiter, Pluto and Proxima Centauri b are in 1 line, on Christmas eve. You can mark those as ‘low’ probability.
Others may be more likely, like developer colleagues that stick some new and shine library into your code, including backdoors.
Add a value for the impact of each threat
Whatever the value of the probability, suppose this threat really becomes reality. What would be the impact? Would the company loose a 100 dollars? Or would the company go bankrupt? It helps if you can really put a number to the impact, but again ‘low’, ‘medium’, ‘high’ suffices.
Manage the risks
Risk management is a broad topic, and there are all kinds of models that help you calculate risk, given some probability and impact. In general you would use this formula:
Risk = Likelihood x Impact
However, the result and usefulness completely depend on the units you used for the parameters. We just go for a simple ‘low’, ‘medium’, ‘high’ scales for each of the likelihood, impact and risk. This works fine most of the time. In the end, deciding the values for probability and impact will mostly be gut-feeling decisions anyway.
When you have your list of risks, you can manage them by doing one or more of the following:
- Accept: Often you’ll find the risk is so low, that you’ll just take the risk for granted, and accept the potential impact. It’s also possible that you find that the potential negative user impact is more important. You can also reassess later, and make this an ‘Accept for now‘.
- Transfer: Outsource or insure. Perhaps another colleague or team is responsible for this, and can pick it up more easily?
- Avoid: You should to do structural changes to completely avoid this type of situation. Those can be architectural changes, or deciding not to deliver a certain feature at all.
- Reduce: Take actions to lower the risk by reducing likelihood and/or impact. Multiple steps may need to be taken to achieve this. Register actions to get this started!
After the whole threat modeling is done, it is important to not stop here. Unless you decide to consciously accept all risks, work needs to be done, either by your team, or by someone else. Register actions for all risks that need to be taken care of. Oh, and probably it’s wise to think carefully with whom you want to share your results. You don’t want to help the bad guys.
Have fun with your first Threat Modeling session!