In this article, I describe how to STRIDE threat model. STRIDE is a threat modeling method that can help you to identify potential security threats and weaknesses in your application or IT system.
Simply put: It is a method you can practice, to think about the bad things that could happen to your application. It allows you to about threats that are classified according to a threat type: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, or Elevation of Privilege (STRIDE). Because you’re thinking of threats within a type, it’s easier to think about potential threats, rather than being completely open and just brainstorming.
Learn more about STRIDE threats, and read up on a real-world STRIDE example.
STRIDE was first developed by Microsoft.
Quick Explanation of STRIDE
Before I start to explain how to STRIDE threat model. Let me start by quickly explaining what STRIDE is, by explaining what each letter means in the mnemonic.
Spoofing: Spoofing is a type of threat whereby an attacker maliciously impersonates (or pretends to be) a different user (or system). You can also use Spoofing more loosely during STRIDE threat modeling to classify threats related to users and access rights.
Tampering: Tampering is a type of threat whereby an attacker maliciously modifies data. You can also use Tampering more loosely during STRIDE threat modeling to classify threats related to the security of data.
Repudiation: Repudiation relates to the ability to prove or disprove that an action or activity was performed by a specific user (or not). Repudiation is thus a type of threat whereby an attacker denies having performed a malicious action.
Information Disclosure: Information Disclosure is a type of threat whereby the attacker gains access to information that should be confidential or secret (and not available to an attacker).
Denial of Service: Denial of Service is a type of threat whereby an attacker will prevent a system (or application) from working for valid users. This is often achieved by overloading a system with fake requests so that no time or resources remain for legitimate users.
Elevation of Privilege: Elevation of Privilege is a type of threat whereby an attacker will elevate their current level of access privilege. This can include elevating access privileges where an attacker has no privileges at all (i.e., not a user) or elevating access privileges where an attacker already has ‘some’ privileges (i.e., a basic user).
Step 1: Understand Background of the Application
While this isn’t strictly speaking part of STRIDE, it is helpful to begin by having a basic understanding of what the application does (its reason to exist), how it does this – what technology is involved, and generally, just understand how to use the application and have a ‘feel’ for it.
This can be achieved by a formal research step, or it can be achieved more informally.
This may or may not require effort on your side, depending on how well versed you are on the application in scope.
Step 2: Create a Data Flow Diagram of the Application
The second step consists of creating a Data Flow Diagram, with the main components of the application, the main actors, and the main interaction points (i.e., other applications, other data sources, and other APIs to which your application connects).
What are the main types of icons and figures you can use in a Data Flow Diagram: See the image below for an explanation.
Note that you should only use the symbols below, and you shouldn’t make your diagram too complicated. The goal is to have a high-level overview of the main components, not to make a super detailed technical diagram.
How to create a Data Flow Diagram (and this step can be performed by yourself, or as a team):
- Understand the main components involved in the application (think: the web services involved, the database(s), and the APIs.
- Understand the main actors involved in using the application (think: the end users of the application, the developers, the administrators, third parties that may also use the application in a different way to end users, etc.).
- Understand the main third-party connections, other applications, other databases, etc. (that are not in the scope of your application as such).
- Understand the different trust areas in play, and where the main components and actors reside within the trust areas.
- Start to draw the Data Flow Diagram, by drawing the most important components first, and then the most important actors.
- Iterate the drawing process until you are happy with the result.
- Only include the most important components, actors, and third-party connections.
The image below shows you a basic example of what you’re aiming to draw.
Step 3: Component-Based STRIDE Threat Modeling
Now you know the main components in the application (and those that it interacts with), you can think about potential threats that may impact your application. You can do this by looking at each main component in your Data Flow Diagram, and iterating through the STRIDE threat types.
The following STRIDE table applies to the MyHealth application depicted in the Data Flow Diagram above.
| STRIDE | Identified Threats |
|---|---|
| Spoofing | Spoofing Theat 1: A user could possibly access data from other users. There are lots of sources of data that are shared within the MyHealth application. There are also lots of features within the application that access different parts of the data. Spoofing Threat 2: The application needs to be accessible to customers. Therefore, the login feature, and its related features (i.e., password reset, etc.), need to be easy to use. However, the ease of use must not introduce a threat which allows an attacker to circumvent or misuse login features (and thus gain access to user credentials). |
| Tampering | Tampering Threat 1: The application has limited data entry features, because most of the features are read-only. For example, users cannot edit billing data, or edit registered medical procedures. But some core informaton about the user can be edited, such as current address, which bank account or credit card must be used, etc. There is a potential threat of other people, except for the current user, tampering with user data. |
| Repudiation | No Repudiation threats identified. |
| Information Disclosure | Information Disclosure Threat 1: Medical data is extremely confidential, and subject to various regulations (i.e., HIPAA). There is a threat that users may access medical data of other users, through lack of access controls. Information Disclosure Threat 2: There is a potential threat of employees accessing health data inappropriately via the MyHealth application (other applications already have strict controls). Information Disclosure Threat 3: There is a threat that attackers, may target customers to try and gain access to their data. Think phishing attacks against our customers, social engineering, etc.. |
| Denial of Service | Denial of Service Threat 1: The application has very high Availability requirements. There is a threat that criminal gangs will target the company with Distributed Denial of Service (DDoS) attacks. The company has been a target of such attacks in the past. |
| Elevation of Privilege | No Elevation of Privilege threats identified. |
There you have it, you now have threats for one of the components in the diagram. You now need to move on to all the other main components. You’ll notice that each component has its own set of unique threats.
The sum of all the component threats makes up your application threats.
The next steps include thinking about countermeasures that you can use to counter the identified threats.
How to STRIDE Threat Model Conclusion
This how-to STRIDE threat model article, explains the three main steps involved in STRIDE threat modeling.
You can continue to build on this threat model, by looking at more Data Flow Diagrams, that depict other parts or other views of your application, or you can focus on more and better countermeasures.
But for now, you have the basics on how to STRIDE threat model.
And in case you don’t know: there are other threat modeling methods, such as:
