supernav-iconJoin Us at AWS re:Invent 2024

Contact Sales

  • Sign In
  • Get Started
HomeGRC CentralRiskSTRIDE Threat Model

Using the STRIDE Threat Model: Tutorial & Best Practices

Using the STRIDE Threat Model: Tutorial & Best Practices

What's Inside

Learn about the STRIDE framework, a practical and effective approach to threat modeling that helps identify potential threats and vulnerabilities in system designs for effective risk management and mitigation.

Contents
Summary of STRIDE Model ThreatsGeneral MethodologyDecomposing Your Systems into ElementsTrust BoundariesElement AnalysisCataloging ThreatsIntegrating STRIDE into your SDLCZero Trust with STRIDE

Threat modeling is a structured approach to identifying threats in the context of your business and product. The purpose of threat modeling is to understand your attack surface exposure and potential threats, manage their risk, and apply mitigation controls. This modeling contributes to an overarching risk management program and should be revisited and updated often.

STRIDE—which stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege—is a practical approach to threat modeling that aids organizations in identifying strengths and weaknesses in system designs. It helps you think through the decomposition of a system’s parts and how a threat might become realized in a product’s development and operationalization. 

In this article, we review STRIDE and discuss its various elements and best practices for using it. In a few steps, we lay out the groundwork for the basics needed to start threat modeling with the STRIDE framework. This will serve as a useful quick start guide for engineers, architects, CISOs, and relevant stakeholders to get started implementing their own threat modeling processes.

Unlock End-to-End Risk Management

Proactively identify and address your organization's vulnerabilities to reduce and minimize the impact of unexpected events.

Learn More

STRIDE is a classification of threat tactics that offers security-minded professionals a general approach to identifying threats in product development and implementation. The beauty of STRIDE lies in its simplicity and practicality when compared with other threat models. It does not require you to consider your business context—you can start applying STRIDE once you meet its prerequisites.

Consistency and structure are key to the application of a threat modeling program—it takes a little more effort in the beginning to become a natural component of your security strategy.

Summary of STRIDE Model Threats

This table summarizes the threats described by STRIDE and their associated security properties.

Threat

Applicable Security Property

Definition

Spoofing

Authentication

Claiming an identity that is not true

Tampering

Integrity

Changing the state of something from its original or intended form

Repudiation

Accountability

Denying having taken an action or having received a message

Information disclosure

Confidentiality

Unauthorized exposure of information

Denial of service

Availability

Unavailability of a service by any means

Elevation of privilege

Authorization

Claiming a higher entitlement than authorized

General Methodology

When you’re starting your threat modeling, the first step is to focus on what you are trying to protect-essentially scoping out your systems from a high level. Once that’s clear, the next step is to identify who your likely attackers are and why they’d target you. Understanding who gives you insight into their capabilities and attack methods, while the why helps you pinpoint the assets they’d be most interested in. Finally, think about how and where potential attacks could happen by breaking down your systems and identifying vulnerable areas that could be exploited. This approach gives you a solid foundation for anticipating what could go wrong.

As you approach threat modeling with STRIDE by following the concepts below, it is important to remember that threats tend to follow the data flow, and the key is balance:

  • Define and decompose your assets: Defining your assets is a good starting point. Identifying critical assets allows you to know which ones pose the greatest risk if compromised. 

  • Know your attackers, tactics and techniques: This approach focuses on trending and conventional threat actors’ techniques, however these have a propensity for change—along with the threat actors’ motivations—therefore, it is best not to make it the center of your threat modeling. 

  • Gain introspection into your systems to find vulnerabilities: This approach focuses on your product’s architecture, system elements, and data, specifically how your data is stored, transmitted, and processed. It allows you to focus on what you already know, informed by your asset inventory and threat intelligence.

64% of companies report integrated risk management and complete visibility into third-party risk as top-ranked priorities.

Download the report and gain critical insights into risk management strategies of today's enterprises.

Get the Report

Decomposing Your Systems into Elements

Before we dive in, let’s explore the distinction between elements and assets. Your systems are made out of elements—hardware and software—including all interactions of a system toward an end purpose. Assets, on the other hand, hold value to an organization, whether tangible or intangible, like intellectual property, financial data, or personally identifiable information. Assets are what you are trying to defend, while elements enable the interaction of a system. 

Decomposing the system is commonly done using diagrams, which help visualize how a system works, communicates, and runs different processes. A commonly used diagram for this purpose is a data flow diagram (DFD). The goal of a DFD is to disassemble your system into parts and highlight the data flow between them. If you are just starting off, there’s no need for your diagram to be too elaborate, but keep in mind that other types of diagrams could be more suitable for the type of systems you are trying to threat-model against.

In the context of threat modeling with STRIDE, elements are processes, data stores, data flows, and the external entity who is the user, administrator, or persona interacting with the rest of the elements. Any resource interacting in and around a system can be an element.

It is helpful to label elements by trust boundary (described below), with each boundary separated from another by its level of privilege. Each element in the diagram should be drawn using a specific shape to convey its role, as in the diagram key below: A process is expressed as a rounded rectangle or a circle. Keep in mind that shapes can vary slightly when the element’s role expresses more explicit definitions; for example, a double circle expresses a logical representation of a complex process or multi-process such as a service or daemon.

stride threat model asset 1

Trust Boundaries

Trust boundaries are demarcation points between elements with different levels of privilege. Everything on one side of a trust boundary is commonly assumed to have the same level of trust. There may be times when a trust boundary is required even within the same context, such as a database, to demonstrate that some database tables require differentiated levels of trust. 

A process that requires communication between different system components or resources, such as when exchanging parameters or keys, may require you to draw a boundary between them. This can be done from a high-level point of view to a more detailed decomposed state of one asset into multiple instances. 

Consider an asset with two potential failure modes: fail-open and fail-close. In this case, it's important to represent both failure states in your threat model to ensure that the threats associated with each scenario are thoroughly evaluated and accounted for. Similarly, consider a data sink that aggregates data from multiple sources—it's important to define boundaries around each source, as they may introduce distinct threats that should be addressed individually in your threat model.

The important thing to remember is that a change in your environment, such as the level of privilege, trust, context, or state, can have security implications with unique threats that need to be demonstrated in your threat modeling. You’ll also want to ensure that your diagram representation includes data sources and destinations.

stride threat model asset 2

Here are some relevant best practices:

  • Start high and then go low: Create a diagram that provides context, then break it down into smaller parts, for example, by trust boundary.

  • Remember that representation matters: Often forgotten, be sure to draw the external entity or the process that is reading or writing from or to a data store.

  • Reduce where appropriate: You can group similar elements within the same trust boundary together as long as they are the same type or are using the same technology.

Element Analysis

Once you have broken down your system into smaller pieces, it is easier to conduct analysis. In STRIDE threat modeling, there are two common approaches: STRIDE-per-element and STRIDE-per-interaction. STRIDE-per-element focuses on identifying threats to individual elements of systems, whereas STRIDE-per-interaction focuses on the threats that may arise from the interactions between components. For example, if we were to look at a Transmission Control Protocol (TCP) handshake, STRIDE-per-element would look at the client, server, and negotiation in one image separated by their respective trust boundaries. In contrast, STRIDE-per-interaction would further elaborate on each prompt and response of the handshake for analysis.

Now that you have framed your diagram and approach, it’s time to go through the STRIDE threat taxonomy to brainstorm threats. Don’t spend too much time on whether a threat fits into one category over another. Depending on what your role is within the organization, you may see different threats; therefore, be sure to include technical subject matter experts as well business units that understand your product’s business logic.

A good way to start is to look at what is occurring when data is crossing a trust boundary and ask what is likely to go wrong. Another method is to look at each element and iterate through the STRIDE mnemonic to figure out if the element is prone to each threat. You can label each element with the types of STRIDE threats they are susceptible to, and further analyze those threats by decomposing complex components into smaller parts. 

Lastly, we often make assumptions based on perceived notions. The same is true about security. Take a moment to analyze your system in a decomposed state to validate your assumptions about some of the protections you take for granted, especially within all of your dependencies.

Gain Confidence in Vendor Security

Streamline the risk management process with all your vendor information in one place.

Learn More

Cataloging Threats

Once you’ve discovered applicable threats, it's important to organize and keep track of them. You can do this by making a table with the element name, threat, and any other identifiers. You can also organize your table by threat, element, what the threat does, and other identifiers.

Let’s look at the STRIDE threats, the elements they affect in your system, and how to frame a mitigation response in the context of each category in the chart below.

Threat tactic

Affected element

Security property

Spoofing

External entity and process

Authentication

Tampering

Data flow, data store, process

Integrity

Repudiation

External entity, data store (audit logs), process

Non-repudiation protocols

 Information Disclosure

Data flow, data store, process

Confidentiality

Denial of Service

Data flow, data store, process

Availability

Elevation of Privilege

Process

Authorization

If we change our perspective to an element point of view and look at how threats manifest, this may provide insight into the best working approach for your own in-depth analysis:

Element

S

T

R

I

D

E

External entity

x

x




Data flow

x

x

x


Data store

x

x*

x

x


Process

x

x

x

x

x

x

Here’s a further discussion based on each element type:

  • Data flow: The table above shows that data flows are susceptible to tampering, information disclosure, and denial of service. If your data flow is between an external entity like an ecommerce user and an authentication database, you may be worried about unauthorized disclosure of sensitive information and can document your mitigation response with TLS. What about data flow threats from dependencies? In a multi-tenant cloud environment, your data flow could be at risk from attacks on the network substack, which could redirect traffic to a spoofed recipient.

  • Data store: We tend to think of data stores as static, but it’s important to remember that data is consistently being read from, written to, or processed by these stores. Be sure to document those processes, as well as which entities use the data store and where they are coming from.

  • Process: At a high level, the process element can contain a complex process and more complex subprocesses in a subdiagram. Processes are the most sensitive of elements and are susceptible to all of the STRIDE elements. 

  • External entity: This is the user interacting with the rest of the elements and is susceptible to an unauthorized threat actor assuming the authorized user’s identity or a user denying to have either received a message or taken an action. 

Integrating STRIDE into your SDLC

Rather than fixing a problem, the most cost-effective solution is to avoid it in the first place. Putting threat modeling in your Secure Development Lifecycle (SDLC) as you are building your product from scratch is the best approach to avoid running into backward compatibility issues when applying security patches later.

Consider your threat exposure to be the collection of code and the interaction of services, protocols, and interfaces, as well as the users who will be using the final product, whether legitimate, unauthenticated, or remote users.

A safe assumption is that the first iteration of your software will be the most costly and time-consuming. However, that work can set the pace for smooth sailing if your team adopts “security by design” principles from the beginning by finding vulnerabilities early and focusing on product defects later. This can make more sense if you take into account the fact that secure designs can have fewer code-level errors and fewer critical vulnerabilities. This results in faster code reviews and implementation.  

Here are a couple of specific considerations:

  • Where to fit threat modeling into your existing SDLC: If your team generally follows test-driven development, then it means you are testing your design before writing code. This phase is closely related to threat modeling activities and would be a natural fit into your SDLC. The best times are right after achieving a milestone or after an issue arises.

  • Taking a shift-left security approach: This means literally shifting security activities from being a reactive practice on the right side of your product implementation to placing security into an integrated and cohesive process with the development of your product and implementation.

Zero Trust with STRIDE

Zero trust architecture (ZTA) is a security model where identity and access permissions to resources need to be continuously verified, and access to every protected object should be validated. One of the first steps to threat modeling with STRIDE is to define your perimeters or trust boundaries. 

In the age of ZTA adoption, where no trust is implied, both elements and trust boundaries need to be continuously verified and authenticated while your threat modeling identifies points of vulnerability within these boundaries. This means that when you are defining your assets and data flows, you’re not just looking at the connections being made—you are also looking at the asset itself as a point from which a threat can emerge.

For example, if you are in the healthcare industry, you might ask yourself if there’s a threat of information disclosure in a particular system where sensitive patient information lives and only authorized personnel should gain access. As an example of a data store that is susceptible to the threat of information disclosure, you might enable role-based access control. This approach aligns with ZTA’s principle of continuous verification and validation of a user’s identity and permissions while reducing the attack surface by minimizing the number of users with access to critical information. 

If ZTA assumes a breach then, in the context of threat modeling with STRIDE, the external entity element should be regarded as the attacker at all times. This shift from the outset can elevate the authentication and authorization principles from allowing the external entity implicit access based on their role alone to a more explicit and recurring validation process on a per-need basis.

Threat modeling is helpful for finding vulnerabilities as early as when you implement STRIDE. Vulnerabilities that otherwise would go unnoticed until later in your development can be costlier and inadequate, as retrofits are not always exact or the same as those developed in conjunction. But how do you measure success? Success can be found in closing vulnerability gaps or bugs, as long as your threat model closely resembles that of your real systems. 

Threat modeling is a building block to fulfill your business needs and prioritize your security. Not all threats can be mitigated in development. For example, in healthcare, you can mitigate some risk exposure by limiting the collection of patient information to what is minimally necessary; however, data stores and data flows are still inherently susceptible to threat actors. 

Where threats exist beyond development, threat modeling, evidence collection, and mitigation can support control mapping. If you have done threat modeling as a foundation, you may not want your teams to spend the additional time and effort necessary for evidence collection and application of mitigation controls. This is where automation tools such as Drata can significantly enhance your collection of evidence by integrating with the types of platforms already in use by your organization, giving you a fundamental understanding of your configuration and gaps associated with commonly used frameworks and regulatory requirements by your industry.

Get Audit-Ready Faster With Drata's Compliance Solution

Learn more about the benefits of compliance automation and then schedule a demo to see how you can streamline your audit processes.

Book Demo