Threat Modeling Handbook #2: Threat modeling is a process, not a document

Welcome back to the 2nd story in the “Threat Modeling Handbook” series. In the last story, we discussed what is a threat model and why it is useful, and I know by now you probably can’t wait to start the actual threat modeling, but before getting to that there is one more thing I wanted to clear out.

Threat modeling is a process, not a document

It is important to know that threat modeling is a process not a document, or to be more precise it works much better if you treat it as a process (or include it in your existing process).

The difference is that documents are usually created once and usually stored in a black hole somewhere, but threat modeling needs to be as agile as the SLDC (software development lifecycle) process, you should be able to adapt your threat modeling to new changes or features including, and you need to be continuously testing for the mitigations included in the threat model to get the most value out of threat modeling.

Hence, in this story, we will discuss some guidelines on how the threat modeling process could work.

When to threat model?

Based on the requirements mentioned in the last story (remember this diagram) we can break what is included in the threat modeling process into 3 main phases :

• Phase 1: Identifying High-level risks, threats, and their corresponding mitigations.
• Phase 2: Verifying the mitigations are working as expected.
• Phase 3: Creating continuous tests to alert if the mitigations break in the future (This is where threat modeling meets DevSecOps, but that is a story for another day).

A possible outcome out of phase 1 is design or scope changes (e.g. to mitigate a threat), and that can become costly if implementation has already started, hence the earlier this phase is started in the SDLC process the more efficient it is. While discussions around the high-level risks, threats, and mitigations can start as early as the “Plan” phase, the best time to actually be able to go through it thoroughly is within the “Design” phase, as having at least a draft design and scope is usually needed to identify the threats and their possible mitigations.

Once phase 1 is complete, We need to wait for implementation to complete (e.g. on a testing environment) to start phase 2 which is the verification of the mitigations.

If there are no critical findings from phase 2, the service/feature can then be deployed in production, but it is important to remember phase 3 which is creating continuous tests for the mitigations needs to be completed before or shortly after the deployment, and it should be monitored for alerts as part of the normal operations of the service.

When to threat model?

What to threat model?

If you are planning to introduce threat modeling to your organization it is usually better to start with a few high-value, high-complexity, and/or high-risk new services or features, this gives you the chance to understand the development process as you go and adapt the threat modeling process and tools to it. It also helps showcase the value of the threat modeling process and convince stakeholders to add it as part of the process.

Once you reach this point you can work with the stakeholders to agree on specific criteria to define which new services and features need to go through the threat modeling process. Ideally, you want the criteria to be more selective (higher-risk services and features only) and as the process is tuned and made more efficient (e.g. through using automation for threat and mitigation identification, verification, and testing) you can include more features of lower risk.

The criteria for what needs to go through threat modeling can include things like the following (not a complete list):

• Are we changing the design of the service? (e.g. introducing a new datasource, or a new downstream dependency, .. etc)
• Are we introducing a new kind of data we didn’t store/handle before? (e.g. new type of PII data)
• Are we using new credentials we weren’t using before? (e.g. new API key for a dependency)
• Are we changing how authentication/authorization works?
• Are we changing how any previously identified threat mitigation works?
• Are we introducing new attack surface? (e.g. new pages to a website, new routes to the API, or new input parameters to an existing route, .. etc.)

What do we need to start threat modeling a feature?

We need to have a good understanding of the service or feature being threat modeled and how it works to be able to effectively identify the high-level risks, threats, and their corresponding mitigations, and to be able to do that specific prerequisites are usually needed. Below are some examples I found to be useful, but you can adapt the list to what works for you:

• What is the problem we are trying to solve: Knowing the goal of the project is crucial to understanding the value being provided, which is in turn important to be able to reason about the risks, and whether they are proportional to the value or not, and take design decisions accordingly.
• Who are we building this service/feature for: Is it a tool meant to be used only by internal employees? Is it meant to be used by external customers? If so, is it targeted to all external customers or customers that have specific roles? .. etc. This helps identify the authorization model suitable for the service/feature being built.
• What kind of data is being handled/stored: Knowing the kinds of data the service/feature has access to helps identify the data-related high-level risks like data exposure and tampering and the related threats.
• Scope Items: This includes everything we are adding or modifying in the scope of the project, e.g. a new API service, new routes added to an existing API, new input parameters added to an existing route, a new website, new pages added to an existing website, a cli tool, .. etc.
• Design document: If it is a new service then we need the design (mostly provided in the form of an architectural diagram), and if it is a feature we need to know the design changes if any. This helps visualize the different components (e.g. frontend, backend, databases, platform, downstream dependencies, .. etc.), how they interact, and how data flows between them, which helps identify threats related to specific components or interactions.
• Credentials being handled: e.g. Are we introducing a new downstream dependency and using a new API key for it. Obviously, this usually ties to risks and threats related to the exposure of these credentials.
• Code changes: If the implementation has started having access to the code commits or PRs (pull requests) helps understand how the service/feature works and could also help verify the mitigations.

Conclusion

Threat modeling works much better if treated as a process that is embedded in the SDLC process itself, and in this story, we discussed some outlines of how this process can be defined and implemented. In the next story we will start with our first example, and go through phase 1 of threat modeling (risk, threat, and mitigation identification), but for now, let me know in the comments if you have any questions or feedback. Thank you for reading!