The Hitchhiker’s Guide for Failing Threat Modeling

Precaution: This guide contains very explicit irony. It intentionally avoids using self-reflection and empathy. It shall only be applied in small doses and under strong security safeguards for the security expert.

As passionate experts in the field of security, we all strive towards applying the model of zero trust in collaboration with our fellow development colleagues. This guide is supposed to take an ironic look at how to best fail a Threat Modeling workshop – not by having an underline for learning how to do it better if you are planning to run it successfully the next time.

Have you ever gotten out of a Threat Modeling workshop with the impression “that hasn’t gone right”? Did you ever face a situation where you have dozens of findings from the workshop, but no one wants to listen or discuss the next steps? Then it’s time to pull a pen and note down the Top-7 list of things you should do to fail your Threat Modeling perfectly! Let’s note it down in chronological order from planning to getting into it with the application team to consolidating the results of the Threat Modeling workshop:

• Step 1: Always place your Threat Modeling request at the very last minute
• Step 2: Invite everyone and their dog to the workshop
• Step 3: Create a culture of fear that suits the topic of security
• Step 4: Start right into the analysis of threats
• Step 5: Threat Modeling concepts were just for slow starters, skip it
• Step 6: The biggest risk of security is having a risky discussion
• Step 7: Time to move on and conquer the next security-barbarian island
• Conclusion

Step 1: Always place your Threat Modeling request at the very last minute

We all know the situation when after a long journey, there are only a couple of days left to heroically launch the product, and it’s not only the architecture and the coding fragments that look as if you had just started the Hello World programming course. Time to spoil all plans of the team for doing necessary cleanups and quality improvements by placing a last-minute request to re-assess whether security was in the people's mind while planning! Not only will it help the motivation within the workshop but it will also make clear to everyone what they have missed out on in the last weeks and where now they can spend the best nightshifts to finally make it better. That’s a good start to position security in the best light!

Step 2: Invite everyone and their dog to the workshop

Threat Modeling is definitely an activity that lives from the exchange with the whole team around the applications, independent of whether they are directly into security matters or not. Though, identifying the right participants who can give input for the assessment is a tedious task. Therefore let's invite just everyone to the table independent of whether they may actually already be involved in the  activities or not. If that doesn’t sound reasonable to you, just invite only people that think the same way and see the system in the same light - you don’t want to add noise to a perfectly well-defined and understood system. Nobody likes surprises!

As an addition for you as Threat Modeling Pro, assure that right from the start there are no communication rules. Only if people speak right as their mouth has grown is it the perfect setup where someone might say something wrong.

Step 3: Create a culture of fear that suits the topic of security

Speaking of starting the session, it’s the first time to make a stand. And whoever thinks that security is fun??! Time to clearly articulate the seriousness of it. You should represent a genetic match of Inspector Barnaby and Indiana Jones – expressing that you will find any murder of good-code-quality and feel like being surrounded by a dangerous jungle. Only if people understand that you chase them for every mistake will they openly tell you about any potential security flaw. In addition, to underline the seriousness of the activity, directly confront the team with your tool, best a lengthy and complicated-looking Excel. Also here agility is key, the participants find themselves in the structure and intention along the way.

Step 4: Start right into the analysis of threats

So much time is often wasted to first understand the context, terminology, and desires of the application team. By skipping it, you can straightly show your efficiency in finding the mistakes of the team. Software is all the same – you have seen it all. Therefore, if anything from the architectural model is unclear to you, it will somehow sometimes somewhere be clarified or most likely indicate already the first mistake by the application team. So, get your board ready and paint your threats!

Step 5: Threat Modeling concepts were just for slow starters, skip it

Developers are used to Agile, and agile just means that you don’t have a concept. STRIDE, PASTA, misuse- cases, and attack trees are all concepts that people used in the early days. So go with the perception that everyone can put the security glasses on and the security threats that you are articulating are clear, aren’t they? Threat modeling is, in the end, nothing else than the famous hide-and-seek game!

Step 6: The biggest risk of security is having a risky discussion

Now that you have collected your list of threats, it is time to close the book. The development team should have had its learning from the session, and the security expert is not supposed to show them how it can be mitigated. Someone from the team may even have the idea to start a likelihood-impact discussion – a risk is a risk, and now that they are on the table, it is time for the team to roll up their sleeves and value the indication of it while thinking about how to resolve it.

Step 7: Time to move on and conquer the next security-barbarian island

Your job is done! You have not only left the team alone with the findings of the Threat Modeling, but you also right after the meeting shouted out loud on all channels what epic failures the development team has done – this is how effective security and security culture is done! Doing so also ensures that now everybody’s attention is on it, so there is no need to review the resolution. Your time has come to move on. Well done!

Conclusion

We’ve all learned and grown from our mistakes, or if possible, from others’ mistakes. The intent of this post is to share and debunk the common misconceptions about how to run a threat modeling program so we can all avoid making the same mistakes. What’s the issue outlined above that resonates with you the most? What are other common pitfalls you’ve seen? Share in the comment section below and let me know!

✍️ About the author: Michael Bernhardt

Michael is a passionate security expert with 15 years of experience in the field of AppSec, CISSP certified, and a former EuroUSEC program committee member. He is currently heading the Product Security team of Telefónica Germany, supporting Telefónica in its secure cloud transformation. As part of his former professional security career, he has advised numerous Top50 customers in the secure adaption of SAP’s ERP system, led SAP’s global DevSecOps program, and was a founding member of SAP’s Open Source Program Office acting as Security Officer. He considers AppSec an art of bringing together people and technology under the principles of security best done by security story-telling. Michael is also a founding member of Threat Modeling Connect.