― 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 extra 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
It is important to know the boundaries of you system, because you cannot control everything. E.g. while the cookie store in the user’s browser contains sensitive data which is part of your system, you cannot control which browser the user has or how they use it. You can however control whether you use cookies at all, or which cookie flags you use
to secure them. So, the choice where the boundaries lie is not always trivial.
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.
Add actors
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
