In part one of this article, I started to look at the challenge of how to do threat modeling better as a development team. I recommend reading it first before continuing with this one.
Continue();
At this point, you should know your attackers, your assets and build a register of threats. This information should give you enough data to answer the second question of the 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, spend some time looking at your threats and seeing 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 be applicable towards many assets, and with one preventive measure in place, you could mitigate them all.
Step 7: Prioritize
You probably ended up 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 of those questions, rate all the threats on the Low, Medium, High scale 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 for that. Something like the Agile poker, if you are familiar with that term.
Alternatively, you can read a more advanced tutorial on the 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 knowledge) way to proceed.
- Then together, look at the most voted items and prepare your plan.
When you know how to prevent this attack, then do something fundamental - add it to the software you use for your team's task management.
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 actions:
- 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 to build your plan.
Step 9: Triggers
You are now at the end of the threat modeling session. You did a great job, identified lots of threats, and prepared a plan to mitigate them. You need to do just one last thing before you go out of 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 became 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 to review 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 your model, your plan, and your triggers defined. 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 to use with your team. I can share it with you 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 a bit more secure products and services we all enjoy!
Credits: the picture is from Alina Grubnyak.