STRIDE Threat Modeling Example for Better Understanding and Learning

To learn about STRIDE threat modeling, it’s good to read up on what it is, the history of the methodology, where to use it, etc. But seeing a STRIDE threat modeling example goes a step further in improving your understanding.

In this post, I’ll provide you with a STRIDE example based on a real-world business case. Specifically, I’ll be using the component-based STRIDE threat modeling method.

In another post, I provided lots of example STRIDE threats, which may also be of interest to you.

If you’re new to threat modeling, read up on what is threat modeling.

Example Business Case

The example business case, for our STRIDE threat modeling example, consists of:

• Company and industry: Health care insurance provider, within the health care and insurance industry.
• Object in the scope of threat modeling: The company is in the process of developing a new web application called ‘MyHealth’. It will allow customers to view their medical data, billing, appointments with healthcare providers, and potential deals that customers can purchase.
• Scoping limitations: Currently, the business processes related to the MyHealth application are not in scope.
• Tech stack of the application: The MyHealth web application will be cloud-based, hosted in Azure, and will have a Javascript framework front-end.
• Team: Various DevOps teams are involved in the project, as well as business driving the transformation to provide as many health insurance services through the newly developed MyHealth application.

Note that this development will connect to various parts of the IT landscape which is considered legacy, and thus not in scope of the current threat modeling case.

The above is meant to provide you with a general idea of the business case, development environment, and tech stack used in this STRIDE threat modeling example.

First Step: Gather Background Information

The first step in the STRIDE threat modeling example is to gather as much background information as possible (which sounds obvious but is still worth mentioning).

Potential information that may help in later STRIDE threat modeling steps:

• Architectural diagrams and overviews of the proposed application design: Such architectural diagrams can provide threat modelers and team members with an understanding of key components within the design, technology used, communication flows, etc.
• Requirements of the solution: Requirements often contain the business and IT requirements that explain what the application must be capable of doing. The amount and quality of requirements may vary in quality from project to project. There may even be some security requirements that can help with the later STRIDE threat modeling steps.
• Project documentation: Project documentation will explain how the application will be built, who is involved, how long the project will take, etc. Pay attention to the inclusion of security as part of the project. This will indicate whether security is an integral part of the project (and thus resulting application), or whether it is a ‘forgotten’ quality.
• Team overview and governance: Understanding the key players in a project is very important. Pay attention to the security team members involved (i.e., security champions, security department representatives, etc.).

Read all the gathered background information. It will show the project members that the threat modeling team is up to speed.

Second Step: Create a Data Flow Diagram (DFD)

Because we’re applying the component-based STRIDE threat modeling method, we need a good understanding of the key components involved in the project, and how they interact with each other.

To achieve this, I’ll create a Data Flow Diagram (DFD), which is the second step in the STRIDE threat modeling example. It will include only the key components, the key interactors (e.g., users), data stores, and the communication flows between them.

Architectural diagrams and overviews of the proposed application design help in creating a DFD.

The reason why I’m only including key components (versus including all components) is that including too much information can make the overall threat model too complicated and too difficult to understand. Participants in the threat modeling sessions will not be invested or engaged if they do not understand what they are threat modeling.

The Data Flow Diagram (DFD) should be made based on input from team members in an interactive threat modeling session. It is important to get input and cooperation from a wide range of team members, including technical/non-technical, developers/non-developers, testers, Product Owners, and any other people and roles with knowledge of the application.

The diagram below is an example of a Data Flow Diagram (DFD) based on the MyHealth example.

Highlights of the diagram (and its main components):

• Customer: The end customer using the application. The customer is a health insurance recipient (paying a monthly health insurance fee, and receiving health insurance coverage).
• Employees: Employees access the application as well as customers. Employees provide support to customers via a helpdesk and other channels. Employees can see more data than customers, including access to many different customers.
• MyHealth Application: This is the main application in the scope of the threat modeling exercise. It is shown here as one icon. However, the application has many sub-components, backend, frontend, etc.
• Customer Data: The new application will have a new database environment to store some of the relevant customer data.
• Medical Procedures (and activities): Data provided to the customer includes medical procedures, activities, etc. This data is stored in a legacy database and system. This data will not be sent to the Customer Data database.
• Billing Data: Billing data is managed in a separate system, but is shown via the MyHealth application (to the customer).

Note that the above Data Flow Diagram is not perfect, but for the purposes of keeping the STRIDE threat modeling example simple, it will do for now. Future posts will focus on how to tweak and improve on details included in a Data Flow Diagram.

Third Step: Perform Component Based STRIDE Threat Modeling

Now, as a result of creating a Data Flow Diagram, we have an understanding of the main components in the STRIDE threat modeling example.

As a next step, I will perform STRIDE threat modeling against each component (known as component-based STRIDE threat modeling).

Two approaches for this step:

1. Think of potential threats per component, and assign a STRIDE threat type (i.e., assign Spoofing, or Tampering, etc.).
2. Per component, think of Spoofing threats specifically, then Tampering threats, then Repudiation threats, etc. So in order of STRIDE, go through the list and think of potential threats limited to the STRIDE threat type.

I usually use both methods, or a combination of both.

For this example I’ll use method 2 – the method of strictly thinking per component, and walking through all STRIDE threat types, to determine which threats may apply.

I’ll do this for two components: MyHealth Application and Customer Data components.

Note that the STRIDE threats that I’m about to describe are ones found within the desing phase of this application. Therefore, the types of threats are still quite high level, and do not account for potential known countermeasures.

STRIDE on the MyHealth Application Component

The following STRIDE threats apply to the MyHealth application, as part of the STRIDE threat modeling example.

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.

STRIDE on the Customer Data Component

The following STRIDE threats apply to the Customer Data component, as part of the STRIDE threat modeling example.

STRIDE	Identified Threats
Spoofing	No Spoofing threats identified.
Tampering	Tampering Threat 1: A database administrator may tamper with customer data for fraud purposes. Tampering Threat 2: Someone who gains unauthorized access to the database may tamper wtih customer data.
Repudiation	No Repudiation threats identified.
Information Disclosure	Information Disclosure Threat 1: An attacker may infiltrate the company network, and gain access to the database, and then have access to all database data.
Denial of Service	No Denial of Service threats identified.
Elevation of Privilege	Elevation of Privilege Threat 1: A database configuration page may be exposed on the internal network, which could be used to gain unauthorized access to the database. Elevation of Privilege Threat 2: A default database user may be used to gain access to the database, if the login method is exposed to the internal company network (and not only accessible on a separate management network).

Countermeasures, Controls and Mitigations

In this example, I have not included steps that define countermeasures to the identified threats. This is a design choice to not complicate this example too much. In subsequent posts, I will provide STRIDE countermeasures examples.

Further, you have to decide how you approach the countermeasure process. If you spend too much time on countermeasures too early in the threat modeling process, you may take away precious time used to think about potential threats.

Don’t get me wrong, defining (and architecting) countermeasures is important. But some (or most) of the countermeasure work can be performed as part of other security engineering activities.

STRIDE Threat Modeling Example Conclusion

In this STRIDE threat modeling example, we looked at a business case whereby a health insurance company is developing a new application for its customers called MyHealth.

I described three steps in this threat modeling example:

1. Gather background information
2. Create a Data Flow Diagram
3. Perform component-based STRIDE threat modeling

Each of these steps is needed in order to perform STRIDE threat modeling.

The important result as a part of this threat modeling example is the two tables with STRIDE threats. These are the threats that you should be aware of and should build countermeasures for.