Driving Actionable Work From a Threat Model

If there are only three things you take away from this blog post, they should be:

1. Threat modeling is for everyone.
2. As long as you have a threat description, a potential mitigation, some action items, and questions, it doesn’t matter how you got here. What matters is what you do with that information.
3. Engage, and re-engage, with your threat models to improve value beyond your team.

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!

Improving Your Threat Artifact

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:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

We’ll be using this process to lay the foundation for driving more actionable work for everyone!

Improving Your Description

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:

• Include descriptors that make the threat specific to your platform by considering your audience.
• Shorten your description if it is too vague or exceedingly complex.
• Break up your threat into component threat descriptions. Which threats rely on other indicators of compromise, and which threats are standalone issues?

As part of the review of this section, I’d like to call attention to two key pieces of advice:

• Consider your audience!
  • Are you including your tech writers in your threat modeling session? What about your sales engineers? Or teams that are downstream dependencies of your application?
    If only two people understand the work described, only two people can do the work described.
• Support asking and recording questions!
  • How do you expect to collect questions during your sessions? Where possible, leverage technology to record and capture questions, and their answers.

Threat Mitigation

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.

Action Items And Questions

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.

Activity Time

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!

I’ve got a Threat Artifact - Now What?

After the activity, and a much-needed break, we dove into the next steps.

• Create tickets for the dev team
  • Spikes
  • Documentation and runbook creation/updates
  • Contextualized mitigations and features
• Socialize your threat model results
  • Consider your audience
• Return to your threat model process often
  • The time spent on your threat model is invested — what matters is what you do with the information created

How-To: Turn Your Artifact Into Work!

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.

Three-Part User Story:

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.

Gherkin:

Feature: Mitigation Description

Scenario: threat actor performs threat description

When: audience performs threat description

And: …

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.

Socialize Your Results

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:

• Management stakeholders
• Downstream and upstream applications
• QA team (if separate)
• Operations team (if separate)
• Customer success, marketing, and retention groups
• Compliance and regulations/legal

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.

Return to Your Experiences

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:

• Drive onboarding new employees
• Drive and prioritize operational and security tabletop scenarios
• Inform your demos
• Create blog posts to retain or socialize a solution to your problem space
• Improve on the threat modeling system, documentation, and process for team velocity and flexibility.

Return to threat models for stakeholders and dependencies:

• Drive new user documentation and training on your product
• Educate non-technical staff supporting your product
• Incentivize product acquisitions, contracts, and workflows
• Inform pen testing engagements
• Create blog posts to retain or socialize a solution to your problem space
• Improve on the threat model system, documentation, and process based on what audiences need

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.

Review!

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:

1. Threat modeling is for everyone. No matter your role, you can contribute to a threat model, as well as consume the output of the threat model. It’s a feedback loop that drives benefits.
2. So long as you have a threat description, a potential mitigation, some action items, and questions, it doesn’t matter how you got here. What matters is what you do with that information. We talked about the four parts of a threat artifact. Regardless of how you got here, STRIDE, PASTA, some other alphabet soup, it’s what you do with this information that matters.
3. Engage, and re-engage, with your threat models to improve value beyond your team Re-engage and drive work from your threat model activities. Use collaboration time to convert threats to actionable features or documentation, drive content for blogs, better define QA stories, and drive priority.

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:

1. Who can I partner with, outside of my application development team, to share and socialize my application threat model?
2. What’s stopping you from socializing your application in your organization?
3. How can I close the loop between work identified by the threat model and work completed in a reasonable time?
4. What are some things you can do to improve the fidelity of your threat description, action items, and/or mitigations?

Will I See You Next Year?

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!

Best,

Jono

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.

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.