A convenient guide to starting you on Threat Modeling – part two
In part one of this article, I started to look at the challenge of making threat modeling better as a development team. I recommend reading it first before continuing with this one.
Continue(Threat Modeling);
At this point, you should know your attackers and assets and build a register of threats. This information should give you enough data to answer the second question of threat modeling, “What could go wrong?”.
Now it’s time to start digging into the third question – “What are we doing to do about it?”
Step 6.5: Merge
Before moving to the next step, look at your threats and see if you can group some of them or remove the duplicates. Then attach to each threat an attacker and an asset.
You would need to do that for a couple of reasons:
- For the same threat, you might have different mitigation scenarios depending on who your attacker is.
- You might find out that one threat might apply to many assets, and with one preventive measure, you could mitigate them all.
Step 7: Prioritize
You probably ended up in the previous step with tens of threats. If you don’t, I suggest you go and spend some more time brainstorming or using the STRIDE model to inspect your infrastructure.
Now you might panic for a bit and start thinking about how you could fix everything. Let’s start prioritizing the threats.
There are a few good techniques for that, and I will introduce one of them called – Probability/Impact Matrix.
For every threat combination (threat, attacker, asset), ask your team the following questions:
- How likely is this attack to happen?
- If it happens, what will be the impact?
For each question, rate all the threats on the Low, Medium, and High scales and put them on the board.
Hint: You can try here the following strategy:
- One person only adds those combinations on the board and places them where she thinks they belong.
- Then the team could share their opinion and challenge this assessment by giving their reasons. Something like Agile poker, if you are familiar with that term.
Alternatively, you can read a more advanced tutorial on risk assessment here.
At the end of this step, you should have a prioritized list of threats, and logically you can start with those placed in the top right (High/High) segment. It’s your team’s decision on how you would like to manage that.
Step 8: Mitigate
I find this technique very useful, and I can recommend it to you:
- Pick one of the threats you identified in the previous step and read it aloud to your team.
- Give some time to every member to work individually on a solution and place the proposals on the board. It could be a one-step approach for fixing the problem or something that includes a “dirty fix” to lower the risk and a proper solution later.
- Then ask everyone to look at all mitigations proposed and vote for the best (according to your team’s knowledge) way to proceed.
- Then together, look at the most voted items and prepare your plan.
When you know how to prevent this attack, do something fundamental – add it to your team’s task management software.
Most teams don’t do that. They identify the threats and stop the process here.
That doesn’t seem right – to have a valuable and successful strategy to prevent attacks, take action:
- Add the threat user story (the combination between the threat, the attacker, and the asset) to your backlog.
- Add the mitigation plan.
- Add the acceptance criteria (How would we know that we did a good job?)
- Add a sprint name or another time-bound to make yourself accountable and build your plan.
Step 9: Triggers
You are now at the end of the threat modeling session. You did a great job, identified many threats, and prepared a mitigation plan. You need to do just one last thing before you leave the room and do something completely different and probably more fun.
The threat landscape is changing as you read this article. Many new attacks are happening every second, and new threat agents appear every month.
To mitigate the risk of your threat model becoming irrelevant, you need to define the triggers that bring your team back together to review and update the model.
Some of them could be:
- You will add a new data flow to the microservice.
- A component you use becomes vulnerable. (Check CVE database).
- You will sell your product to a government agency, and the risk of the attacks will change.
- An internal component you use just got hacked or altered.
Of course, you can build a habit of reviewing your model regularly without defining any unique triggers, but again you need to ass this action to your backlog and see to it.
Use the Force, Luke
Now you have defined your threat model, plan, and triggers. You did a great job.
🎆 Congratulations! You deserve a gift.
I will give you this PDF template of all tools and ideas described here, which you can use for your session. I also have this as a collaborative Miro template for your team. I can share it if you send me an e-mail to bogomil -at- talkweb dot eu.
Don’t leave your code unattended. Apply threat modeling early and with care to build more secure products and services we all enjoy!
Credits: the picture is from Alina Grubnyak.
This Threat Modeling article is also published here.
Per Wikipedia, the core definition of threat modeling is “A process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigations can be prioritized.”
Suppose we want to get practical and decode this into something everyone can understand. In that case, it’s answering four simple questions which you could discover in the Threat Modeling Manifesto as well:
What are we planning to do?
Do we have a new Auth mechanism we want to implement in the next sprint?
Do we have a new feature that we will release to the customer soon?
Do we plan a new microservice?
Do we discover that some of the components we use are compromised?
Do we plan to buy a new car?
What could go wrong?
The attacker can exploit our new Auth mechanism because we didn’t protect all the ports.
A botnet can bring our new service down by executing a DDoS attack
We ship our new component with a default admin password.
The car comes with a remote control that anyone can easily hijack.
What are we doing to do about it?
Protect our apps by reducing the attack surface and removing the ports or endpoints we don’t use.
Leverage a CDN to limit the impact of a DDoS attack.
Disable default accounts and do not send passwords via e-mail.
Buy a protective case for your new car keys.
Did we do a good job?
Measure the success of the mitigation.
Has this attack happened and what was the outcome?
How many DDoS attacks were we able to mitigate?
How many complaints about customer data leaks have we had?
Is your car still in your garage?
Threat Modeling: A Cognitive Model
If you look out of the window and stop reading this text to analyze what you just learned, you will realize that all of these sound logical. This is how we humans are wired to self-defend, and we have the habit of following this model in almost every situation.
Do you need an example? All right, here I go:
What are we planning to do?
You decided to go on a vacation and realized that you need someone to take care of your plants while away because you love those little green souls so much. ( And you should, but that’s another topic).
What could go wrong?
You might want to give your keys to your neighbor and task her with the mission, but she just rented the place next to you, and you don’t know if you can trust her. Maybe she can rob your apartment or throw a party. The probability is low, you think, but it still is there.
What are we doing to do about it?
Maybe move your plant to the garage and give her the keys to the garage. Limit the access and still achieve your goal.
Did we do a good job?
After your vacation, you see your plants alive, your home in order, and your neighbor happy to help you. I call this success.
Of course, she copied the key so that she could enter the garage at any time, but you still don’t know about it :)
It’s a process
Now let’s go and look step by step at how you can build a very efficient thread model.
As a beginning, I will start with the steps to help you answer the first question – What are we planning to do?
Step 1: Gather your team together
To have a helpful session, you need your whole team. Most of the time, the modeling is done by one or two persons because they know most of the system or the company believes that this exercise is not valuable. By inviting your whole (agile) team, you include many experiences, different points of view, and diverse opinions.
Step 2: Identify objects (components) in the system under assessment by writing a low fidelity diagram at first
The most knowledgeable person in the room (onsite or virtual) draws a low-fidelity diagram of all the components you need to model against and explains what they represent. Here is the time to talk about different trust boundaries you might have.
Practical Tip: K.I.S.S.: Keep it simple, stupid. Do not draw a highly complex system with tens of components and boundaries. Start with the part of your system if needed or a simplified view. Then repeat later if you want to go deeper.
If you go with the whole complexity of your solution, you might lose some of the attendees or, the following steps will produce hundreds of threats that will not flow well through the system, and your session will become less efficient.
Step 3: Recognize the flows between those objects
After you have the components draw lines between them to show how the data flows to help your team realize what they need to do later to protect the data in motion.
Practical tip: While drawing that, please explain the process and why this is happening while drawing. For example: When the user visits the application website, they can see the login page served by the Apache server. Then the credentials are sent to the application server via an HTTPS connection and checked for validity against the customer DB.
You need to explain the system well, so the team would understand it before moving to the next part.
Now let’s move to the most exciting part.
Now we answered the first of the four questions, “What are we planning to do?” and now it’s time to brainstorm on What could go wrong?
Step 4: Identify the attacker personas
Given your product value and architecture, who is your attacker? The usual suspects are:
A competitor – maybe a company that runs in the same market segment would like to bring our services down or steal our customer data.
A Bot – automated attack service without human interaction. Your internal employee – willingly (bad morale) or unwillingly (social engineering or phishing) could harm your product.
A random internet user – an unknown source with no apparent motivation.
Another exploited service – a service/module you use with a new vulnerability. You know your system, be creative here, and identify the attack actors. Look at similar Threat Models and see what attackers exist there that you could reuse. The more time you spend here, the more impact you will have later. Remember, this is a model. There are no wrong ideas here. Your cat can be an attacker if you leave your computer unlocked. (read an article entitled How to Fix Common Tech / Computer Issues Caused By Cats)
If you want to extend the knowledge, you can build the personas, adding their motivation and likely attacking you to have the complete profile.
As this is optional, please remember the more time you spend modeling, the less time you will have to remediate security issues later. This rule applies to every step in this section.
Step 5: Create an Inventory of Assets in Interest.
Look at the diagram you created in the previous step and the attacker personas to analyze the assets you need to protect.
Again let’s start with the usual suspects:
Your DB – The data you store is the primary interest of almost any attack.
Keys – the keys to encrypt your information or to authenticate users.
API Ports/resources – an available port is always a good entry point of an attack.
You could apply to same rule here – look at the low-fi diagram you created as part of the threat modeling session and ask yourself – If I am an attacker, what would I want to steal/do?
Step 6 – Create a register of threats.
Use one of those methods or a combination of a few to build a register of threats for your product.
Method one: Brainstorm
Spend 15 min individually to look at the low-fi diagram, the assets you identified, and the possible attackers and write down all the things you believe could go wrong: How any of the attackers can harm any of the assets.
Then, each one of the team would place a sticky note next to the Asset or the Component where this attack is most likely to happen.
Please make sure:
Each member of your team has the right to talk and add their attacks on the board.
Anything is possible; there is no lousy attack scenario at this moment.
If there are similar attacks – combine them in affinity groups to look at them in detail later.
Method two: Use similar Threat Models.
If your product is built on K8s or uses a known scenario as Oauth 2.0, there is probably a publicly available thread model for it.
Download and verify the source of it
Use it to see what threats are applicable to your infrastructure.
Identify gaps and add them to your register of threats.
You could also look at your company register of threats (if any) and/or similar services like yours already with a threat model for inspiration and ready-to-use work.
Please remember these models are outdated, and you need to use them as a start and not rely on them entirely.
Method three: Use STRIDE
STRIDE is a good framework for doing Threat modeling for web applications. It was created by Microsoft and contained a register of threats divided into six categories.
Spoofed Identity – How hard is it for an attacker to pretend to be someone with authority to use the system? An example of identity spoofing is an attacker breaking a poor user password and gaining access to the system. Spoofed identity in the offline world could happen if you have a note with your pin stuck on the back of your Credit card.
Tampering with input – How hard is it for an attacker to modify the data they submit to your system? An example is when an attacker submits a SQL injection attack via a web application and uses that action to view everything in the database. Or, in the offline world, imagine someone saying your name in the post office, and they give them all of your precious packages without checking for proof.
Repudiation Attack – How hard can users deny acting? An example is when a user has deleted some sensitive information, and the system cannot trace the malicious operations.
Information Disclosure – Can someone view the information they are not supposed to have access to? An example is when a user can read a file they were not granted access to or the ability of an intruder to read data in transit between two computers.
Denial of Service – Can someone break a system so valid users cannot use it? An example is when a Web server has been made temporarily unavailable or unusable with a flood of traffic generated by a botnet. A DDoS attack is like an unexpected traffic jam clogging up the highway, preventing regular traffic from arriving at its destination in the offline world.
Elevation of Privilege – Can unprivileged users gain more access to the system than they should have? For example, the attacker could use an unprotected service using a service account to access the protected data. In the offline world, this could be a thief breaking through the window to enter your house, otherwise protected with a secure door.
Each category contains applicable attacks against your system, which you could use to get started.
The way it works is you start from the top category and read the first threat, and then if you see that it can be executed against one of your components, you add it on the board and then move to the next one.
At the end of this exercise, you have a good register of threats.
Use the force, Luke
Remember that you still need to put your brain to work and think about other threats not included in the framework, and the more time you spend modeling, the less time you will have to remediate security issues later.
Since we already know What we are going to work on and What could go wrong, In the next part of this article, I will focus on the following two questions and give you some good practical advice on doing a great and valuable Threat Model.
Smile more and think about security all the time!
You can find this threat modeling article here as well.