How rapid threat models inject more reality into tabletops

Keeping up with security demands and modeling evolving threats can feel like an endless race that requires an ever-changing strategy. However, new ways to rapidly iterate threat models can make them more accessible to security teams — and more useful, too.

For many organizations, a typical threat model is an exhaustive, multi-week review that consumes significant time and resources. Making threat modeling routine can run up against institutional inertia, limited resources, scheduling conflicts, and a perception that threat models are not essential.

"Threat modeling is the proactive security blueprint that helps you find the weak spots before the hackers do,” said Muhammad Muneer, principal consultant, Mandiant.

While comprehensive models are essential for high-risk systems and for major architectural changes, this limited perception of what a threat model can be prevents teams from applying the principles of threat modeling more broadly. The rapid threat model approach can help organizations better understand how their defensive measures should adapt to the dynamic threat environment.

In addition to maximizing the benefits of threat modeling, the rapid approach can help inform tabletop scenario development — saving time, increasing value, and improving exercise realism. These are two critical practices that should be conducted on a more frequent basis in order to ultimately help improve an organization’s security.

Meet your new design partner: The rapid threat model

The rapid threat model is a trade-off: You exchange an exhaustive, all-encompassing review for rapid iteration and broader coverage. This lighter-weight approach is ideal when time is short and key personnel are scarce or unavailable.

It also serves as a powerful tool to democratize security, bringing non-security-focused teams including application developers and infrastructure owners to the table, and getting them to think like an attacker while also helping to embed security culture in the organization.

So, how do we conduct threat models rapidly? We can think about this in three aspects:

• Time: A rapid threat model scales down the time and participant requirements. Instead of a two- to three-week engagement, plan on the activity lasting for a two- to four-hour focused workshop, or at most, a single day.
• Participants: The participants should include a small, core group of stakeholders: the lead application developer or architect, an infrastructure representative (or cloud representative, where applicable), and a security partner. Input from a business representative who can walk through the use of the in-scope component and key business concerns and dependencies can also be valuable.
• Structure: Provide a structured agenda for the session to enable the actual delivery of a rapid threat model. For example:
  • Scope (15 to 30 minutes): Tightly define the scope of the threat model. Focus on a new feature, a key data flow or process, or a specific application.
  • Brainstorm (60 to 90 minutes): Identify the system’s “crown jewels” in the context of the previously defined scope (such as key data points, data flows, and primary functions). Map out the high-level architecture and trust boundaries. If existing architecture diagrams are non-existent or overly complex, a whiteboard might come in handy. Finally, spend some time brainstorming credible threats, focusing on the in-scope “crown jewels” and common threat actor motivators.
  • Prioritize, consider countermeasures, and document (30 to 60 minutes): Quickly rank the threats by likelihood and potential impact. Avoid analysis paralysis and identify the top three to five scenarios that are both plausible and concerning. Consider some potential countermeasures to mitigate the risks identified by each scenario. Write down the scenarios and countermeasure considerations in bullet point form.

The benefit should be immediate: You walk out of a single session with actionable, prioritized security scenarios and ideas on how to mitigate the risk presented by each.

Rapid threat models can often be very valuable to provide security input into application design at the outset. For example, a team may choose to conduct a rapid threat model on a new, public-facing "Customer Loyalty Portal" in the cloud.

• In order to collect information on how the application may be used by customers and key architecture components, the participants for the rapid threat model may involve the tech lead, a cloud engineer, and the security architect.
• The threat model is likely to focus on the portal itself, not the broader application, but the group would need to understand how the portal is integrated with the rest of the application, how authentication occurs to the portal, and what access can be provided from the portal.
• The security architect is then responsible to apply threat intelligence and other collected research to overlay potential attack paths based on the provided information and prioritize identified threats.
• Following this, the group needs to collectively agree on the top risk scenarios and consider some possible countermeasures that can be applied to mitigate risk.

Doing this exercise during the design phase makes it much more likely and plausible that these countermeasures can actually be applied in a more reasonable timeframe, helping to reduce the application’s attack surface.

Bringing threat modeling and tabletop exercises together

The scenarios and attack paths identified during a threat model can be quite useful beyond the bounds of the exercise. They can inform the scoping of penetration tests and red team exercises, identify missing incident response playbooks, and be used as inputs when developing threat hunting hypotheses. The scenarios can also be used as a direct input for tabletop exercise planning and storyboard design.

Outputs from a threat model provide the foundations for a compelling TTX storyboard. You've already established the key architectural components, integrations, and likely attack paths. You have a scenario that is relevant, plausible, and understood by the key stakeholders, because they helped build it.

It can also provide an opportunity to engage those stakeholders in exercising the response activities (and developing an application-specific plan, if necessary) that they may inadvertently be responsible for in case that an incident occurs. This is particularly important in the case that the threat model scope involves operational technology, IoT, and third-parties, because Incident response roles and responsibilities for these components are often far less defined and integrated with an organization’s central incident response process.

Here’s the simple shift in perspective: A threat model charts an incident from the threat actor’s viewpoint. A tabletop exercise reverses this timeline perspective from the threat actor’s viewpoint to the defender's viewpoint. You start the exercise at the moment of detection or impact and test the response from there.

The attack path from the threat model becomes the storyboard for the exercise, guiding the inject development. Continuing from our above example, the team may have identified a dozen or so potential threats, but end up prioritizing two as the most critical: an authentication bypass on the customer-facing API, and a potentially-compromised service account that could lead to database exfiltration. These prioritized scenarios are the key output to document and feed into the other activities outlined above, including the tabletop exercise storyboard.

Closing the loop

The best time to do these activities is exactly when most teams don't: during the development cycle. By running a tabletop exercise for a product that is still in development, you move beyond theoretical design flaws and begin to test the human and process elements of your response.

The threat model helps you ask, "Could this break?" and the TTX helps you ask, "What happens when it does?" This is where you find the deep, systemic gaps, such as non-existent interaction models between teams, outstanding response questions, or critical stakeholder concerns that were never voiced during design.

Threat modeling and tabletop exercises are two of the most effective ways to build organizational resilience. By viewing them as isolated, time-consuming events, we miss their true power. A rapid threat model provides a fast, iterative way to identify plausible threats, and its outputs are not just a report; in addition to providing actionable remediation actions (hopefully at the outset of development, prior to go-live!), they are direct fuel for high-fidelity tabletop scenarios.

By conducting this sequence before go-live, you test not only your design but your response to its failure, uncovering critical governance and technical gaps when they are still easy to fix.

We encourage you to move beyond the annual, organization-wide tabletop exercise. Start embedding rapid threat models and their linked tabletop exercises at the design phase. By leveraging the synergies between these two crucial initiatives, you can save time, improve your designs, and build a more resilient organization.

To get more information about threat modeling or tabletop exercises, check out The Defender’s Advantage or reach out to a Mandiant cybersecurity expert for specialized assistance.