Threat modeling the TRAIL of Bits way

Our threat modeling process is a little bit different. Over time, multiple application security experts have refined this process to provide maximal value for our clients and to minimize the effort required to update the threat model as the system changes.

We call our process TRAIL, which stands for Threat and Risk Analysis Informed Lifecycle. TRAIL enables us to trace and document the impact of flawed trust assumptions and insecure design decisions through our clients’ architectures and the systems and processes that support them. Mitigating system-level findings like these squashes whole classes of vulnerabilities, which means fewer one-off bug reports and fixes to worry about.

What TRAIL is

We’ve all used a variety of threat modeling methodologies over the years; each has its strong suit, but none perfectly fit our clients’ needs, so we combined the best parts of what we knew and iterated to build our own process. TRAIL initially extended Mozilla’s single-component Rapid Risk Assessment (RRA) process to whole systems (large and small), incorporating parts of the NIST SP 800-154 Guide to Data-Centric Threat Modeling and the NIST SP 800-53 security and privacy controls dictionary.

While RRA’s data dictionary inspired our approach, TRAIL enables us to model all in-scope parts of the system and their relationships with more rigor. When following TRAIL, we systematically cover each connection between components. We don’t just uncover direct threats to the data that each component handles, but also emergent weaknesses that arise from improper interaction between components, and other architectural and design-level risks.

Security patching can easily become a cycle of receiving a security report, making a one-off fix, and then getting yet another ticket that documents yet another instance of exactly the same problem. Structured threat modeling breaks this cycle of treating the symptoms over and over. A proper threat model exposes design-level weaknesses (of which individual vulnerabilities are symptoms) so they can be remediated.

Why a TRAIL threat model provides value

TRAIL has three goals:

1. Document the current system’s architecture-level and operational risks;
2. For each risk, provide our client with both practical, short-term mitigation options and long-term strategic recommendations;
3. Enable our client to update the threat model themselves¹ as they mitigate risks, and the system otherwise changes over time.

Throughout the software/systems development life cycle (SDLC)², application security review results in a better product. The design phase of the SDLC is an ideal time for collaborative³ threat modeling exercises involving both security engineers and the people building the system: there aren’t yet users relying on particular system features, but requirements are mostly set in stone, so it’s easier to make design improvements. But the second-best time to plant a tree is, naturally, now. Threat modeling work provides value in every SDLC phase since it improves developers’ understanding of the consequences of design choices.

How TRAIL works

Model building

TRAIL’s foundation is in first building as accurate a model as possible. We work with our client to identify all in-scope system components. Then, we’ll place a trust boundary anywhere that security controls⁴ gate connections between components (or should, as per security requirements and design). We’ll group components that share trust boundaries into trust zones.

We’ll talk extensively with our client and read their system documentation to build knowledge of the system and its SDLC, uncovering and documenting previously unwritten assumptions. Then, we establish relevant combinations of connections and threat actors⁵, especially for those connections that cross trust boundaries. We call these connection-actor combinations threat actor paths⁶.

While our discussion of potential threats with the client throughout this process is relatively free-form, building threat actor paths ensures we stay rigorous and don’t miss a way that an attacker could maliciously escalate their privilege or cause data to move between components or out of the system.

Threat scenarios

Our core model-building work allows us to identify design-level and operational risks that our client could have otherwise missed. We’ll document these risks in the form of threat scenarios. Each threat scenario describes a potential way that an adversary could exploit a single connection crossing a trust boundary between two components in the system. Putting threat scenarios together and doing further confirmation research enables us to write findings, but we’ll discuss findings later. For some threat modeling exercises, we will stop refining our system context at this point and will wrap up our work with summary-level remediation recommendations—we call this type of review a lightweight threat model.

What you get from a lightweight threat model

A lightweight threat modeling engagement results in an end-to-end, high-level overview of the risks inherent to a system’s design, illustrated with a handful of threat scenarios plus recommendations. Our clients typically use the results of lightweight threat models to guide further security review and remediation. Here are a few threat scenarios from the 2023 Trail of Bits assessment of the Arch Linux package manager, Pacman:

Table 1: Example threat scenarios from our 2023 assessment of Arch Linux Pacman

More lightweight threat models can be found in audit reports in our Publications repo, including in the reports from our assessments of CoreDNS, Eclipse Jetty, Kubernetes Event-Driven Autoscaling (KEDA), and others.

Findings and follow-on work

When a client wants a more granular security review but isn’t sure how best to target it, we can do a lightweight threat model and use its results to scope a follow-on secure code review, infrastructure review, or fuzzing work to just a few threat scenarios or system components.

Or, instead of stopping with the high-level overview provided by a lightweight threat model, we can alternatively do a comprehensive threat model to produce system-level findings. A threat model finding concretizes threat scenarios with deeper, targeted investigation, evaluates the severity and difficulty of exploitation by different possible threat actors, and concludes with tailored recommendations on how to remediate those threats.

What you get from a comprehensive threat model

In a comprehensive TRAIL threat model, we’ll continue past the endpoint of a lightweight threat model, putting our identified threat scenarios together and doing more research to ultimately present findings and finding-specific recommendations. Here are summaries of a few findings from our Linkerd engagement:

• At the time of the Linkerd engagement (in 2022), the destination service, which served routing information to sidecar proxies within a Linkerd-integrated Kubernetes cluster, lacked built-in rate limiting. This could have allowed an attacker with sidecar proxy access within one of the cluster user application namespaces to easily cause a denial of service by repeatedly requesting routing information, or to change the destination service’s availability status to force updates in the Linkerd controller component.
• We also discovered that nothing prevented infrastructure operators from using the Linkerd CLI tool to fetch YAML definitions, including sensitive information, over unencrypted HTTP. This cleartext data flow would weaken the overall security posture of an infrastructure operator’s system.
• Also at that time, the linkerd-viz web dashboard lacked access controls. This meant that any attacker who learned the Linkerd dashboard’s network address by simply running a scanning tool on a Linkerd-configured Kubernetes cluster could then gain detailed knowledge about the namespaces, services, pods, containers, and other resources in the cluster by accessing this dashboard, and could use this information as a basis for targeting the software running on top of the cluster.

The table below includes some of the threat scenarios that we used to build the findings summarized above:

Table 2: Example threat scenarios from our 2022 Linkerd comprehensive threat model

Other comprehensive threat model reports in our Publications repo include even more threat actor paths and the findings we built with them; our reports for Curl and Kubernetes are great examples.

Applying the results

Once we’ve mapped your whole system, identified security control gaps in its design, explored potential threat scenarios together, and provided our findings and recommendations, what’s next?

Informing further security reviews

We internally use our threat models’ outcomes to provide context and direction for further Trail of Bits reviews of the same system, improving efficiency and outcomes on subsequent audits. If you are interested in both the results of a threat model and another type of security engagement we offer, why not book both engagements back-to-back with the threat model first? This retrospective blog post from 2024 on our work with OSTIF gives several excellent examples of this pairing!

Remediation

Our practice is to include short-term (immediate stopgap) and longer-term (to achieve the ideal state) mitigation suggestions for each finding in a comprehensive threat model. Where possible, we recommend several overlapping mitigations per finding, since a single mitigation could fail or be subverted by a resourceful attacker. We also include a high-level summary of our recommendations in both comprehensive and lightweight threat models.

Updating your threat model

A threat model must change as the system evolves. We provide an appendix with every report that includes directions to help you periodically modify your threat model so it remains relevant as your system’s design and requirements change over time. We’ll also discuss how and when to update your threat model in our next post!

I like how a TRAIL threat model sounds. How do I get one?

Please use our contact form to get in touch. We’d be delighted to learn about your system and your needs!

Special thanks to Stefan Edwards, Brian Glas, Alex Useche, David Pokora, Spencer Michaels, Paweł Płatek, Artem Dinaburg, Ben Samuels, and everyone else who has worked on threat modeling engagements at Trail of Bits for your awesomeness and contributions to the evolution of TRAIL.