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.
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.