Welcome to the first, brand-new edition of the newsletter in 2023!

In this edition, we share some content that can shed light on a better understanding and avoidance of pitfalls in threat modeling. And finally, we could not help ourselves but have another go at ChatGPT to treat you to a nice poem on threat modeling.

The TMI line-up for this month:

• The hitchhiker’s guide for failing threat modeling, a guest article by Michael Bernhardt
• Curated content: Creating Security Decision Trees with Graphviz
• Curated content: Threat Modeling Lingo
• Toreon blog post: Unlocking the power of Threat Modeling by Steven Wierckx.
• A Toreon Poem in honor of Poetry Week

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 out a pen and write 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 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. It is not a good idea 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. It is better to have a clear plan in place to ensure that security is considered throughout the development process, rather than waiting until the last minute to address it. This will help motivate the team to improve their work and will make clear to everyone what they have missed out on in the last weeks and where they can best focus their efforts to improve security.

Step 2: Invite everyone and their dog to the workshop
Threat Modeling is an activity that depends on collaboration with the entire team working on the applications, regardless of their level of expertise in security matters. However, identifying the right participants who can provide input for the assessment can be challenging. To ensure that everyone has a chance to contribute, invite everyone to participate, even if they are not currently involved in the activities. If this approach doesn’t make sense to you, then invite only those who share your perspective and understand the system in the same way. Avoid adding unnecessary complexity to a well-defined and understood system. Remember, nobody likes surprises! As a Threat Modeling expert, make sure to avoid formal communication protocols. It’s when people speak candidly that the best opportunities arise for identifying potential security issues.

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. To really drive home the importance of the task at hand, make sure to use a tool that’s as cumbersome and convoluted as possible (Excel, anyone?). And for an added touch of fun, make sure to keep the team guessing by refusing to let them work in an agile manner. After all, there’s nothing quite like the feeling of being completely at the mercy of a rigid structure.

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 straightaway 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 clear concept. STRIDE, PASTA, misuse-cases, and attack trees are all concepts that people used in the early days. It is important to approach threat modeling with a clear understanding and not rely on the assumption that everyone can identify security threats without proper guidance or tools. Rather than comparing threat modeling to a game, it should be acknowledged as a serious task that requires a structured approach and dedicated effort.

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!

Reprint from the Threat Modeling Connect community (highly recommended).

Original article

Creating Security Decision Trees with Graphviz

Threat Modeling Lingo

As we celebrate Poetry Week here in Belgium, let us take inspiration from the beauty and power of words in not just literature but also in the field of threat modeling. To honor this occasion, here is a poem crafted by ChatGPT: