In , 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. part one of this article 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 scale and put them on the board. Low, Medium, High 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 , if you are familiar with that term. Agile poker Alternatively, you can read a more advanced tutorial on the risk assessment . here At the end of this step, you should have a , 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. prioritized list of threats 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 " " to lower the risk and a proper solution later. dirty fix 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 - add it to the software you use for your team's task management. fundamental 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 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- dot eu. this PDF template talkweb Don't leave your code . Apply threat modeling early and with care to build a bit more secure products and services we all enjoy! unattended : the picture is from . Credits Alina Grubnyak

Flow

2022 - HackerNoon Contributor of the Year - Cyber Threats

2022 - HackerNoon Contributor of the Year - Privacy

2022 - HackerNoon Contributor of the Year - Psychology

2022 - Internet Heroes

Visit my blog!

Book a 15-min free coffee talk

Buy My Book

 Software Delivery Professional

Too Long; Didn't Read

Publish Your First Brand Story for FREE. Click Here.

K.I.S.S. on a Threat Model, Like it is Hot P.2

K.I.S.S. on a Threat Model, Like it is Hot P.2

Too Long; Didn't Read

Coin Mentioned

@bogomil

RELATED STORIES