Continuous TRAIL

You’ve just completed a threat modeling exercise with us. You have our final report in hand. You’ve maybe even started remediating our findings! But threat modeling can only document the risks that were present in your system at the time of assessment. As you continue adding new components, security controls, and features, does our threat model still accurately describe your system? What new risks has your work introduced?

You and your team should incrementally update your threat model as your system changes, integrating threat modeling into each phase of your SDLC¹ to create a Threat and Risk Analysis Informed Lifecycle (TRAIL). Here, we cover how to do that: how to further tailor the threat model we built, how to maintain it, when to update it as development continues, and how to make use of it.

Adapt the threat model

While we intend TRAIL threat models to be approachable and useful for security engineers as well as for developers who work on your system day to day, we do not expect you to maintain all the tables, diagrams, and lists from our report. We’ve intentionally used your organization’s naming and terminology to identify your system’s components, connections, and trust zones, but our reports show our work in detail so it is clear how we arrived at our findings during the engagement. Your team now needs to decide what items from our report to maintain going forward.

What to update

For most systems, we recommend keeping at least the following things up to date, as system design² and implementation continue:

• Trust zones

• Threat actors

• Trust zone connections (not connections between individual components)

• Security-relevant assumptions

Once your system is stable (in SDLC terms, it enters the maintenance phase), revisit and update the following threat model parts:

• Components

• Trust zone connections

• Threat actor paths

• Sensitive data (keys, passwords, tokens, PII, logs, accounts, etc.)

• Relevant security controls categories

What to add

Your adapted threat model is a great place to track remediated and accepted risks. As you address each finding or threat scenario that we disclosed, document how you remediated it and why you chose that remediation option over others—or why you chose to accept the risk as-is.

Updating your threat model with newly discovered risks can also be helpful. For example, if you recently found out that your hardware supply chain is vulnerable to compromise, you could create a new section discussing that risk and documenting potential mitigations.

Where to put it

Choose where the threat model will be stored, how it will be structured, and what tools you will use to update it. Do this however works best for your needs³—just make sure your team is actually comfortable updating the threat model over time. For example, you may decide to:

• Turn the threat model into Markdown documents in the same repository as your code

• Host an editable version of the threat model as a Google Doc or a HedgeDoc

• Add a new category or page to your internal developer wiki

• Add threat modeling sections to your team runbooks

• Translate the report contents into input for threat modeling tools like Threat Dragon, Threagile, or STIX

• Use a tool like draw.io, Lucidchart, or Mermaid to create new diagrams

For the first version of your updated threat model, you can simply copy-paste relevant data from our report. Then, over time you can tailor the structure to your team’s style. We’re also open to changing our reporting format to better suit your needs!

Revise your SDLC

The next step is to refine your team processes to ensure that the threat model stays up to date (therefore, remains useful). Each phase of your SDLC should include updating the threat model.

Each time developers propose a significant design or implementation change that affects how the system should work, a responsible party needs to investigate and document the architecture-level security implications of that change before it can be merged. Specifics of your threat modeling lifecycle will depend on your existing processes.

Examples

If design and implementation happen at once in major pull requests, then every pull request should include an “update the threat model” step before the pull request can be merged.

On the other hand, if big changes undergo design review before any implementation happens, threat modeling should at least happen as part of the design review discussion (consider including an unbiased third party with security knowledge and fresh eyes, like us!) and again before the change is considered fully implemented.

Suppose your team tracks their work in a ticketing system. Then, when the project lead creates tickets for adding a new feature to the system, they should include tickets that any engineer on the team can complete to ensure updating the threat model happens once design concludes, once implementation concludes, and so on.

Alternatively, a directly responsible individual (like a security engineer with team and system context) should be designated in charge of keeping the threat model updated as new features are designed and implemented.

Update your threat model

Consider these questions to decide when to update:

Does this change add a new system component (e.g., microservice, module, major feature, or third-party integration)? If so:

• Add it to your list of components under the relevant trust zone, or create a new trust zone if none apply. The new component should be added to an existing trust zone if an actor gaining access to another component in that trust zone would also implicitly gain access to the new component.

• Add any data flows between the new component and existing components to your list of trust zone connections. Also note how components will send data to, or retrieve data from, the new component. Add one entry to your list of trust zone connections per new data flow.

• Document in your list of threat actor paths any way an actor could gain access to the new component. Keep in mind that any given actor may have multiple ways to access a single component or trust zone.

Does this change add a new trust zone (e.g., by adding a new network segment)? If so:

• Reclassify any system components accessed in different ways into the new trust zone as appropriate. If a new authentication check or privilege level was added, it’s likely that a new trust zone has been added. If services were moved between existing network segments or existing access roles were reassigned, it may be enough to simply move the components in question to different, existing trust zones.

• For any such reclassifications, update your list of trust zone connections and threat actor paths.

Does this change introduce a new threat actor (e.g., a new user role)? If so:

• Add the new actor to your list of threat actors.

• Identify the trust zones and components the new threat actor should have privileges to access or interact with, and update your list of threat actor paths.

Does this change add a new connection between system components that crosses a boundary between trust zones (e.g., a new application service on an existing server instance that can be called by a service in a different zone)? If so:

• Add the new connection to your list of trust zone connections. Be sure to note when a connection is encrypted, the type of encryption in use, and any authentication or authorization data needed for the connection to successfully occur.

• Identify which threat actors have direct access to the trust zones from which this new connection originates, and add them to your list of threat actor paths.

When making any of the threat model changes described above, remember to also update the system diagram accordingly.

Use your threat model

Identify missing or weak security controls

Use your updated threat model like a system map to identify insufficient security controls, which should guide the addition of further controls or the correction of any existing control’s implementation.

Consider each new connection between components:

• Does it violate any previously held security assumptions?

• Does the new connection cross any trust boundaries?

• If the new path crosses a trust boundary, what security controls are in place for it?

• Can any threat actors that were not previously considered traverse the path?

• Does traversing the new path allow any existing actors to gain new privileges, access new components or data, or make external connections that they could not previously?

Your team should iterate over the new paths and consider them in light of the assumptions and controls defined in your threat model. If you discover any actual risks—that is, unmitigated threats—you should revise your system design to ensure that it respects your intended security properties to mitigate those risks. If a risk cannot be mitigated, document why and create a procedure for responding to it if it occurs.

Finally, the actual implementation—code and configuration changes—must correctly enforce the designed security controls. For instance, if a trust zone is delineated by network access controls, make certain that the network segment in question does in fact have the expected ingress/egress rules applied. Consider further engaging Trail of Bits to write custom static and dynamic analysis rules to check if these controls are correctly implemented.

Additional threat model uses

An up-to-date threat model can:

• Inform new design changes. Your team can avoid risks early on in the SDLC.

• Guide and enhance secure software development. Engineers have a resource to reason about the system’s security.

• Help the team plan for incidents. Tabletop exercises and incident response planning can be based on the threat model.

• Prioritize upcoming security audits. Threat models are great at determining where further security investigation should be directed.

• Boost security audits. External and internal auditors have good documentation to start with.

• Provide truthful documentation for end users. Users are informed about what security guarantees they can and cannot expect from the system.

Next steps

There is no one-size-fits-all solution: starting with your TRAIL threat model, build your own approach. In the event of a major architectural overhaul—or anytime you would like to have a second pair of eyes—feel free to book office hours with us to review your threat model updates, or engage us to review larger changes to your system design.

As you and your team continue to grow and improve your application security practice, here are some additional resources for learning about threat modeling:

• Threat modeling the TRAIL of Bits way

• NIST SP 800-154: Guide to Data-Centric System Threat Modeling

• NIST SP 800-53: Security and Privacy Controls for Information Systems and Organizations

• Mozilla’s Rapid Risk Assessment

Then, you may want to move on to these resources:

• Trail of Bits’ threat model reports

• Mark Dowd, John McDonald, and Justin Schuh’s The Art of Software Security Assessment

• Adam Shostack’s Threat Modeling: Designing For Security

• Martin Fowler’s A Guide to Threat Modelling for Developers

• Threat Modeling Manifesto

• Microsoft’s STRIDE

• CMS’s Threat Modeling Handbook

• Bruce Schneier’s Attack Trees