If there are only three things you take away from this blog post, they should be:
One of the most common questions I’ve gotten throughout my time as a threat modeling facilitator is, “I completed my system threat model, now what?” It can oftentimes be confusing turning ambiguous threats, mitigations, and questions into actionable work. As part of this process, there’s several different ways to make your threat modeling sessions more useful, and use the outputs of that session to drive value outside of your team.
I had the chance to speak recently at Threat Modeling Connect’s ThreatModCon about this topic and received such positive feedback that I wanted to share my presentation more broadly. While giving the workshop, I was grateful to participate with the audience, albeit in a more distributed way. I collected responses to my questions through Poll Everywhere. See my slides for more in-depth responses to my questions, provided by the audience themselves!
As part of a threat model, you’ve likely generated one, a dozen, or potentially hundreds of threat artifacts. A threat artifact is made up of a threat description, a potential mitigation, questions about that threat relevant to your organization, and action items around implementing, documenting, or verifying a mitigation. Once you’ve generated several of these, it’s important to return to each component to improve the value of the threat artifact. As stated in the overview, what matters is what you do with these artifacts. Throughout this blog, we’ll be using the four question framework, to analyze what we could do to improve our threat modeling process as a whole. To review, the four question framework asks:
We’ll be using this process to lay the foundation for driving more actionable work for everyone!
To improve our threat description, we’ll start with the first of the four-question framework: “What are we working on?” Let’s start with the importance of the audience. When looking at a threat description, one of the first questions we should ask is, “Do we understand the threat being described here, or ‘what is being worked on’, based on our role?”
This returns to the idea that “threat modeling is for everyone.” I highly encourage individuals to think about who is in the room during a threat model, and more importantly, who is missing. Whether it’s a group of your organization that is focused on testing, legal and compliance, risk, sales, or downstream engineering teams, it’s important to ask if the threat being discussed and described is relevant or a priority to the application, business, or organization.
As part of this process, individuals from other roles can offer a two-fold benefit to threat modeling. First, if a threat is unclear to a participant in the room, they should be encouraged to ask why that threat is relevant to them or the team. By asking these questions, it can help understand the scope of work for a threat, and contribute to conversations about relative priority, dependencies, and potential impacts. Second, for those more well-versed in the threat, explaining and teaching about that threat to others helps cement the concept mentally for those participating in the discussion, and can educate others on potential tribal knowledge or unknown responsibilities.
Once we’ve worked to describe the threat accurately for the parties involved, it’s time to move to question two: “Do we understand ‘what could go wrong …?’ based on the description as is?” Usually, we won’t, and more work needs to be done.
We move to question three: “What are we going to do … to improve the description?” The answer here frequently varies, but a few suggestions are:
As part of the review of this section, I’d like to call attention to two key pieces of advice:
As part of generating a threat artifact, it is also important to document the mitigation. A key point to consider is, “What if I don’t have a mitigation for this threat?” If you, and the team, can’t identify one existing mitigation for the threat described, you’ve found something that can instantly drive actionable work (if it applies to your specific environment).
This is not an instant red flag, but it’ll be important to identify if this is relevant, and then communicate out, preemptively, that things like this aren’t happening to your environment. That can be a selling point of a feature, or clarify legacy tech debt that can be offloaded by changing a core technology.
The last two components of a threat artifact are the questions and resulting action items. As part of your process, I highly encourage everyone to include a method to record questions and document them as a way to drive conversation. If there’s one “role” anyone can take in a threat model, it’s recording outstanding questions and confirming the question content with the attendees. Make sure the questions are stored with the threat model.
Going back to “threat modeling is for everyone,” questions show you a lot about who you’re working with, and what you’re up against. It’s oft-quoted that there are no such things as bad questions, and this applies to threat modeling. A caveat here is that questions may derail a threat modeling session, so using a tool to stack rank priority on questions, like a slid.io, virtual whiteboard, or other collaboration tools, can help keep the questions focused.
As part of giving this workshop, I presented a general threat description, provided by the Elevation of Privilege Card Game. We used the general description of a threat to build components of a threat artifact. I recommend checking out slides 13 through 23 to see some of the results of the activity!
After the activity, and a much-needed break, we dove into the next steps.
It can be difficult for those starting in Threat Modeling to translate a generic threat into something more actionable for the team. As part of this, I included two examples that project managers, engineers, and others can use to frame the work generated by a threat model.
As an audience,
I would like a mitigation description,
so that I may avoid threat description.
To do this, I need to action item #1, action item #2, and spike on question #1.
Feature: Mitigation Description
Scenario: threat actor performs threat description
When: audience performs threat description
Then: mitigation effect
And: additional validation of mitigation effect
A three-part user story is a common framework within Agile environments to help “mad-lib” a description of work together. By using this format, you can roughly attach the needed parts in order, and then refine the description of the work based on team feedback.
Gherkin has seen its own rise in popularity and use. For those who find themselves leveraging this syntax natively in your testing structures, it can be easy to write the features and business cases in parallel with the threat model session as outputs or activities to involve the whole team.
Your threat model benefits from returning to it often, and with different audiences. Consider this: who is missing from your threat modeling sessions? Here’s some audiences we collectively identified as being invited to your next threat model:
Remember earlier, when I mentioned that your threats need to be specific to your audience and that a diverse group of participants is important? That’s because this group of people should be able to confirm or deny assumptions, inform processes or action items, and be informed about changes around supporting their primary value stream. No one group owns this end-to-end.
At this time, I’d love to pass along some sage advice from Rafiki.
In the clip, Rafiki’s staff is the threat. He illustrates that we all learn from theory, as well as past experiences that threaten us. After we’ve described a threat once, we can think of a mitigation (Simba: First, I’m going to take your stick), and then figure out our course of action for future risks. In a similar way to Simba, we too need to return to our threat descriptions and overall threat model often. But why? Consider the following benefits for the audiences in the previous sections.
Return to threat models for your team to:
Return to threat models for stakeholders and dependencies:
There’s a lot of different activities that can be derived from the investment of time that threat modeling asks for. In a similar way, threat models can be used to drive education and security efforts across an organization.
In summary, the inaugural Threat Modeling Conference was a wealth of information beyond this singular workshop. It was difficult to choose just where to be, as each talk and workshop drove such a varied and wild crowd with a wealth of experience. For my part, in my workshop and through this blog post, these are the things I hope everyone manages to take away:
As part of my workshop, I also set the intention to include a reflection. With 90 minutes of conversation, presentation, and activities, I wanted participants to pause and give themselves action items to take back to their organizations. I’ve included the questions below:
Overall, ThreatModCon was exactly the type of event I have missed having in-person over four years! To be surrounded by passionate, driven, communicative practitioners from multiple disciplines, backgrounds, and fields all working together created a natural buzz and synergy between all the content that was presented. I feel honored to have had the opportunity to speak while also learning from every single interaction I had.
Thank you to the organizers who created the event, and provided the opportunity to connect and grow. I encourage anyone with an interest in threat modeling to join Threat Modeling Connect to connect, socialize, and participate in discussions that have stemmed from this wonderful event.
I can’t wait to see you next year!
P.S. If you or someone you know may be interested in additional information about threat modeling, specifically, for workloads in Amazon Web Services (AWS), I co-authored a whitepaper on the topic. Download it here.