Several things can go wrong with baking: meringue flattens when you take it out of the oven, cookies are burnt, the cake is raw on the inside, kitchen catches fire. These threats are something you can prepare for so you can reduce the likelihood or limit the damage. Similarly, in cybersecurity, you can identify problems early and plan mitigations. This is called threat modeling or threat analysis. I’ll introduce the idea and concepts of threat modeling through baking analogies.
Threat modeling identifies potential problems early
The purpose of threat modeling is to think, what can go wrong and what we can do about it. Usually, when people talk about threat modeling, the threats are related to harming security and privacy in an IT system or an application. System unavailability, information leakage to unauthorized people, lack of logs, or getting root access are examples of threats.
In general, a threat can be any scenario with negative consequences in the context of the system that you are threat modeling. Let’s think about the threats in baking. Examples of things that can go wrong are:
- The cake is sticking to the pan and does not come out.
- The pastry is raw from the inside.
- The pastry is burnt.
- Cookies grow into one giant cookie.
- Meringue flattens when taken out of the oven.
- Yeast does not activate.
- You forgot to add an important ingredient to the dough.
- You measure an incorrect amount of some important ingredient.
- You don’t have all the needed ingredients in your cupboard and you have started already.
- Dough or cake accidentally ends up on the floor.
- The bottom of a springform pan falls off and all the dough flows over.
- Your kitchen catches fire.
I think pretty much all of these have happened to me, except luckily my kitchen catching fire. Some of these shortcomings apply to only certain types of pastries or baking. That’s the way the cookie crumbles! Similarly, there are several threat modeling techniques and they fit different purposes. I’m going to explain these next.
Plenty of threat modeling methods
There are plenty of threat modeling methods. It’s often a good idea to use a few methods to get more viewpoints on the different threats the system might face.
STRIDE identifies threats from the architecture
STRIDE is a method oriented to data flows and works well on understanding threats related to architecture. Each letter in STRIDE comes from a specific type of threat:
- S – Spoofing:
- T – Tampering:
- R – Repudiation:
- I – Information disclosure:
- D – Denial of service:
- E – Elevation of privilege:
If iterating threat types with a data flow diagram sounds dull, you can play a card game called Elevation of Privilege, by Microsoft. The threat examples in the cards help you identify security problems (and beat your colleagues).
LINDDUN identifies privacy threats
The privacy threat modeling method LINDDUN is also meant to be used with data flow diagrams but I think it also serves well as a thinking aid. Similar to STRIDE, LINDDUN is a mnemonic:
- L – Linkability:
- I – Identifiability:
- N – Non-repudiation:
- D – Discoverability:
- D – Disclosure of information.
- U – Unawareness:
- N – Non-compliance:
There’s also a card game, called LINDDUN GO, so again you can play while searching for privacy threats.
Evil user stories: what bad should not happen?
Evil user stories, also referred to as misuse stories or abuse cases, are a way of discovering threats from a more functional point of view. There are few ways to creating evil user stories. The first one is using the following format:
- “As a hacker, I want to steal credit card numbers and sell them in darkness” or
- “As a bored teenager, I want to launch a denial of service attack on a popular website so I can brag to my friends”.
The challenge with this approach is that you might run out of ideas of what a hacker or disgruntled user might want to do. Another way is to first list, what important assets you have (your source code, personal data of customers, credentials, etc.) and then think, what bad should not happen to these important data or resources. You can do this by completing the sentence, “An attacker should not be able to do…”. For example:
- “An attacker should not be able to steal credit card numbers” or
- “A user should not be able to see someone else’s private profile information”.
So many ways to think about problems
Then there is the PASTA model (which comes from Process for Attack Simulation and Threat Analysis) and OCTAVE methodology (Operationally Critical Threat, Asset, and Vulnerability Evaluation), or you can use threat personas. Drawing attack trees, that visualize how threats happen and what are the consequences, is a method in its own, too. There are also threat modeling tools, where you draw the system architecture complete with data stores, servers, and connections. The tool provides you a list of all kinds of weaknesses related to these components.
Whichever threat modeling techniques you use, it’s important to be systematic, take multiple viewpoints, document your results, and use findings to improve the security and privacy of the system you are threat modeling. Also remember, that threat modeling is not a one-time thing: it’s something you should repeat continuously, for example, with each new change you are introducing or in every sprint. You can read more about good threat modeling principles from the Threat Modeling Manifesto.
What can we do about the threats?
An essential thing in threat modeling is thinking that what can we do about the threats. Can we avoid the threat scenario? Can we make it less likely? Can we reduce the impact?
Similarly to avoiding a total baking failure by using clean utensils and exact measurements, you can redesign your application in a slightly different way or add some more security features to protect you from the threat scenarios you have identified. Sometimes you cannot avoid the threat fully (internal threats, typically) but you can build for example logging and monitoring to be able to identify an incident as early as possible.
Impact in baking is maybe not so bad
In many cases, the consequences of baking threat scenarios are maybe not too bad, after all, especially if you’re only baking for your family and friends. The cookies might be slightly irregular, the buns are a bit uneven or the cake is lopsided. So what? Unless you burn the pastries into coal, your homemade delicacies are probably going to taste good even if they look funny. It’s another matter of course if you’re supposed to be a professional baker or you’re baking for an important event on the next day.
Understanding the impact and likelihood of a threat scenario is important for being able to prioritize the mitigation options. Your kitchen catching fire is maybe a very unlikely event if you’re careful enough, but the consequences are critical, so it’s wise to have a fire blanket nearby.
On the other hand, cake sticking to the pan or overgrown cookies are more probably scenarios but that’s usually quite harmless. With security and privacy threats, you’ll want to weigh out the risk more seriously.
Baking and threat modeling well together for another reason, too: everybody wants to join your next threat modeling session if you promise to bring homemade cookies!
Bake Security In 