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.
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?"
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:
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:
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:
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.
I find this technique very useful, and I can recommend it to you:
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:
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:
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.
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.