Threat Modeling How-To Guide

How do we model threats?

Threat modeling, at its heart, is really about asking four simple questions:

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 job?

How to answer: “What are we working on?”

The crux of this question is documentation. More specifically, this question is guiding the development team to start thinking about (and documenting) the core processes being developed in terms of processes, data flows, data storage, areas of control, and identifying places where trust assumptions are being made between and among systems and processes. The answer to “What are we working on?” should include a verbal description of the use case for the application and a data-flow diagram showing:

• External entities
  • Entities outside the control of the application or company.
• Processes
  • Code and systems under the control of the application or company.
• Data flows
  • Representation of data moving from one system to another.
• Data storage
  • Representation of data being stored somewhere (this can include Stellar smart contract (Soroban) storage, online databases, fileservers, etc).
• Trust boundaries
  • Outline and group together areas where interactions between systems make or include trust assumptions. For example, in a dataflow where a user submits data on a webpage and it gets processed on the backend, a trust boundary should enclose the backend process, since data can be submitted to the backend outside any filtering controls on the front-end.

How to answer: “What can go wrong?”

Understanding the use case and the data flow from “What are we working on?” can greatly inform thinking around what can go wrong. However, to ensure consistency and thoroughness for the review, it is useful to follow a framework that helps guide the thinking around threats and what can go wrong. Stellar Development Foundation (SDF) follows the STRIDE model. Described below, the STRIDE model helps to provide the consistent framework to ensure high-quality threat models.

For each of the S, T, R, I, D, and E acronyms in the table below, ensure, at a minimum, at least one issue is identified. Oftentimes, there will be multiple issues for each threat. It is useful to identify each issue with an identifier indicating both the threat it is connected with as well as its number. Since there can be multiple spoofing issues, for example, it can be helpful to identify the issues as Spoof.1, Spoof.2, and so on. For especially complex data flows, it can even be beneficial to apply a full stride model on a subprocess in the flow. Ensure that your identification can differentiate between these as well.

	Definition	Question to Ask	Example
Spoofing	Spoofing is the ability for an attacker to pretend to be someone they are not, often taking advantage of gaps in end-user verification in downstream systems.	Could the action being taken be induced by someone other than the person believed to have taken the action?	Calling and ordering pizza pretending to be someone else.
Tampering	Tampering is the ability for an attacker to modify data being submitted or sent to have a different effect than that anticipated.	Could the request have been modified in some way to take an action other than originally intended?	A software bug changes all selected pizza toppings to “cheese.”
Repudiation	Repudiation is the ability for a user to claim they did not take the action that was taken.	Can the user “refute” the action, claiming they did not take it?	The user claims they never ordered the pizza they ordered.
Information Disclosure	Information Disclosure is the over-sharing of data that is expected to be kept private.	Are there areas where more information is being shared or limited information is being shared with more people than is strictly necessary?	Pizza company displays the most recent pizza order, name, and telephone number on their webpage.
Denial of Service	Denial of Service is the ability for an attacker to negatively affect the availability of a system.	Is there a part of the application that is susceptible to being overwhelmed or made entirely unavailable due to overwhelming demand?	Pizza company has a single phone line that only returns busy when called while in use.
Elevation of Privilege	Elevation of Privilege refers to the ability for an attacker to gain additional privileges and roles beyond what they initially were granted, either through legitimate or illegitimate means.	Can someone gain additional privileges without proper authentication and authorization?	Pizza maker signs into the computer with his manager’s keycard and deletes the order so he doesn’t have to make the pizza.

How to answer: “What are we going to do about it?”

For each issue identified in the STRIDE model, think through the ways that issue can happen and identify a “treatment” or way of addressing the issue. Answers here should be detailed in how the issue will address the threat identified. This could include code blocks detailing changes or verbal descriptions of how the issue will be addressed.

How to answer: “Did we do a good job?”

The point of this section is to understand if the analysis done during the other sections was sufficiently deep and broad as to provide value. Some questions to ask and answer here might include:

• Has the data flow diagram been referenced since it was created?

  • If so, congratulations, you have created a reusable tool that can continue adding value.
  • If not, there may need to be more detail or better organization. The data flow diagram should be a useful tool that is regularly referenced.

• Did the STRIDE model uncover any new design issues or concerns that had not been previously addressed or thought of?

  • If so, excellent! The STRIDE model should help to guide thinking towards security issues that may not have been thought of during the initial design phase.
  • If not, ensure you have at least one issue for each threat. Pay special attention to trust boundaries and processes handling sensitive data or taking particularly powerful actions.

• Did the treatments identified in the “What are we going to do about it” section adequately address the issues identified?

  • If so, excellent! The threat modeling exercise has helped to build a more secure application.
  • If not, you may want to provide greater detail and thought around how to respond to identified issues.

• Have additional issues been found after the threat model?

  • If so, excellent! The threat model is a living tool that should be redone any time significant changes have taken place to the architecture. During the design phase for these changes or additions, make sure to analyze the system with the newly designed changes to identify new potential issues in the new changes and in the interface to the old system.
  • If not, continue to refine your threat model and design as new information is learned about the system. The threat model is a living tool that can continue providing benefits as new information is learned about the system.