Threat Modeling Methodology: STRIDE

STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege, developed by Loren Kohnfelder and Praerit Garg in 1999 to identify potential vulnerabilities and threats to company products. Microsoft's STRIDE methodology aims to ensure that an application meets the security requirements of Confidentiality, Integrity, and Availability (CIA), besides Authorisation, Authentication, and Non-Repudiation. STRIDE has evolved over time to include new threat-specific tables and the variants STRIDE-per-Element and STRIDE-per-Interaction.¹

The advantage of STRIDE is that it allows organizations to analyze systems and networks, classifying threats in a prioritized list, based on the likelihood of them occurring and the scale of their potential impact.

For example, a healthcare organization using STRIDE might consider the confidentiality of patient information as a top security priority, at risk of disclosure of sensitive data or unauthorized access. By elevating these threats as potentially highly consequential, the organization can develop and implement countermeasures that will be effective in preventing this from occurring. This methodology is particularly useful for companies that have a clear understanding of the threats and vulnerabilities it faces.

This is the oldest threat modeling methodology and helps identify mitigating techniques. It is relatively easy to use but can be time-consuming. See chart below on example use.²

‍

Threat	Property	Definition
Spoofing	Authentication	Impersonating something or someone else
Tampering	Integrity	Modifying data or code
Repudiation	Non-repudiation	Claiming to have not performed the action
Information Disclosure	Confidentiality	Exposing information to someone not authorized to see it
Denial of Service (DoS)	Availability	Deny or degrade service to users
Elevation of Privilege	Authorization	Gain capabilities without proper authorization

Some benefits of using STRIDE

It is flexible: STRIDE is an adaptable framework that can be applied across multiple industries. It is not limited to certain use cases or sectors.
Shows what can go wrong: If you are a user of the Shostack Four Question Framework, it can also assist with the question of 'What can go wrong' as it provides potential attack vectors or techniques that could be considered.
Risk prioritization: STRIDE helps teams with their prioritization and management of risks. Giving a focus and order in which to tackle the required security controls and activities.
Reduces breaches: If STRIDE is correctly used and controls implemented, this can result in breaches being less likely for the organization.

Are there any limitations to STRIDE?

Resource intensive: Conducting a thorough STRIDE analysis can be time-consuming. Particularly for complex systems.
Provides a static analysis: It primarily focuses on analyzing the system's design and architecture, potentially missing dynamic or runtime threats.
Subjective: This can arguably be positive or negative. But due to the adaptability of STRIDE, assessing the impact and likelihood of threats can be subjective and may give varying results between different teams or individuals.
Requires continuous maintenance: STRIDE cannot be done just once, it needs to be repeated to reflect changes in the system's design, architecture, and threat landscape.
Limited to Software: STRIDE is primarily designed for threat modeling in software development and may not be directly applicable to other domains or industries.

Things to remember when using STRIDE

It not a replacement for Security Testing: STRIDE is a modeling methodology and does not replace the need for actual security testing, such as penetration testing or code reviews.
It can depend on expertise: Effective implementation of STRIDE requires a certain level of expertise in threat modeling and security, which may pose a challenge for less experienced teams.
Incorporating non-technical threats: While STRIDE is well-suited for technical threats, it may not address non-technical threats, such as social engineering or physical security concerns.

Should I consider other Threat Modeling Methodologies?

To learn more about other methodologies please visit Threat Modeling Methodologies.

Can STRIDE work within IriusRisk?

The short answer? Yes! Read this blog on how you can use STRIDE Methodology and CAPEC, within IriusRisk.

Information Sources:

1. Software Engineering Institute, Threat Modeling: 12 Available Methods (2018) https://insights.sei.cmu.edu/blog/threat-modeling-12-available-methods/

2. Microsoft, STRIDE Chart (2007) microsoft.com/security/blog/2007/09/11/stride-chart/

‍