STRIDE Threat Framework
What Is STRIDE?
STRIDE is a framework for detecting, categorizing, and prioritizing potential threats to and vulnerabilities of applications and IT systems. It was one of the first and best-known frameworks for threat modeling, created by two Microsoft engineers in 1999 to help software developers remember confidentiality, integrity, and availability (CIA) requirements during early stages of development. Using STRIDE, developers and security teams can think like attackers, identifying and addressing weak points in an application or system before they can be exploited.
STRIDE is an acronym comprising six unique categories of security threats:
- Spoofing: Impersonating another user to gain unauthorized access
- Tampering: Altering data or code without authorization
- Repudiation: Denying having performed an action without proper accountability
- Information disclosure: Exposing privileged information to unauthorized users
- Denial of service (DoS): Disrupting availability by overloading system resources
- Elevation of privilege: Permitting insufficiently credentialed users to perform unauthorized actions
What Are the Elements of STRIDE?
STRIDE’s taxonomy of threats helps developers and security teams ask targeted questions for different types of weaknesses, along with potential impacts and countermeasures.
Spoofing: This action entails fraudulently accessing and using a user’s authorization information, such as usernames and passwords. Spoofing also generally applies to authenticity issues, such as misconfigured identity management or an absence of mutual authentication processes.
Key question: “How can we verify that all users are who they claim to be?”
Tampering: Malicious actors change data or code to manipulate how an application or system works. Data that is either at rest or in transit may also be a target for tampering.
Key question: “What measures are in place to detect and prevent unauthorized changes to our data or application code?”
Repudiation: Claiming that a legitimate transaction never happened—or that an illegitimate one did—and denying responsibility are examples of repudiation. This can undermine the ability of other parties in a system to hold a malicious actor accountable. A system that lacks substantial logging and monitoring processes is a potential target for repudiation exploits, leading to fraud and distrust.
Key question: “Do we have sufficient logging and audit trails to prove who did what in our system and when?”
Information disclosure: This refers to sensitive information shared with entities who shouldn’t have access to it. Unauthorized exposure of personal or confidential information can result from improper access controls, application vulnerabilities, or inadequate encryption.
Key question: “Is all sensitive data encrypted, and have we minimized the risk of accidental exposure?”
Denial of Service (DoS): This type of attack floods services with excessive traffic, consuming resources and disrupting normal functionality, making it unusable to legitimate users.
Key question: “What safeguards do we have in place to handle high traffic loads or block disruptive requests?”
Elevation of privilege: Also referred to as an “escalation of privilege,” this attack happens when a malicious actor gains privileged access to an account and disguises themself as a legitimate user. If the attacker gains administrator-level control, they could modify system configurations, install malware, and access private data.
Key question: “How often should we review our access controls and permissions to ensure no user has more access than necessary?”
How Is STRIDE Implemented?
Implementing threat modeling with STRIDE involves three activities:
- System decomposition: Map out the system or application to be assessed, including individual components. Create a data or process flow diagram and identify trust boundaries. Identify authorization and authentication points.
- Threat analysis: For each component in the application or system, use the STRIDE framework to identify potential threats and attack vectors. Document these threats and prioritize them according to their likelihood and severity.
- Mitigation planning: For each threat identified, propose corresponding security controls. Create mitigation strategies that include technical controls, procedural safeguards, monitoring requirements, and incident response protocols. Test these controls and strategies to ensure additional vulnerabilities are not created inadvertently.
After a successful implementation, train stakeholders on the STRIDE framework and integrate it into an organization’s software development lifecycle.
Benefits of the STRIDE Model
STRIDE was designed to be simple to understand. Its adaptability makes it easy to use across sectors, endpoints, and levels of security expertise.
- Proactive security and increased threat awareness: Simply including STRIDE as part of a software development lifecycle forces stakeholders to find and address security issues proactively and be aware of security postures.
- Comprehensive risk assessment and prioritization: The STRIDE structure enables a contextual evaluation of solution- and sector-specific threats and risks as well as mitigation strategies.
- Cost-effective mitigation and improved compliance: Since STRIDE encourages identifying threats early in the development cycle, organizations can minimize
- costly rework and lost cycles. For highly regulated industries, STRIDE can also help prevent non-compliance with data protection and user safety mandates.
Shortcomings of the STRIDE Model
STRIDE is a framework, not a methodology, in that it provides guidance on threats to anticipate rather than steps for addressing them. It also does not provide quantitative estimates of the potential impact of identified threats, necessitating deeper risk assessments.
- Labor-intensive: Using STRIDE properly is a manual exercise requiring significant time and cross-team collaboration to fully analyze threats, especially for complex systems, which can force organizations to choose which applications to assess instead of adopting STRIDE.
- Static analysis: STRIDE produces a point-in-time summary of security threats and must be kept current with repeated iterations. It is limited to six types of technical threats, which means teams may miss emerging or dynamic threats or non-technical security risks.
- Dependent on expertise: A STRIDE analysis is only as good as the intelligence and diligence behind it. Less experienced teams may miss complex threats, and security experts may not be aware of sector-specific challenges.
Other Threat Modeling Frameworks
STRIDE is one of a variety of threat modeling frameworks that are commonly used to identify and address potential vulnerabilities:
- OCTAVE: The Operationally Critical Threat, Asset, and Vulnerability Evaluation methodology focuses on quantitative risk weighting and organizational risks
- PASTA: The Process for Attack Simulation and Threat Analysis is a seven-step methodology for simulating attacks that combines an attacker-centric technical analysis to assess and minimize business risks and impacts.
- Trike Threat Modeling: This open-source framework emphasizes stakeholder-defined risk, meaning that the assigned level of risk for each asset is acceptable to stakeholders.
- VAST: Visual, Agile, and Simple Threat modeling provides an enterprise-centric view of risks using a dual-track system that provides visual models for application and operational analysis. Unlike other frameworks, VAST is designed for scalability and seamless integration into agile workflows.
Factors to Consider with Threat Modeling Frameworks
In selecting a threat modeling framework, an organization should consider these questions:
- Organizational Goals: Is the objective to evaluate technical security or organizational risks? Is a qualitative assessment sufficient, or is a quantitative risk analysis called for?
- System Complexity: How complex is the system in question—does it include multiple connected components or third-party integrations? Can the framework handle various levels of abstraction, from individual components to enterprise-wide systems?
- Resource Availability: How much staff time is available for a cross-functional exercise? Is the expertise for the desired depth of analysis available in-house?
- Technology Requirements: Does the framework play well with existing tools and workflows, including modern development methodologies? Are automated tools available to support and scale the framework by reducing the manual lift required?
In some cases, combinations of frameworks can lead to more thorough assessments. However, to produce stronger security postures, the chosen framework should offer practical benefits in integration and scalability.
VAST: A Scalable Enterprise Threat Modeling Framework
The VAST framework was created to address the shortcomings of data flow diagrams and manual threat modeling processes, bring threat modeling capabilities in-house, and make threat modeling scalable. Designed for automation and seamless integration into modern development environments, VAST is ideal for large organizations with complex, interconnected systems. Its ability to handle both application and operational threat modeling ensures comprehensive coverage, and its visual approach to threat modeling makes it easier for non-technical stakeholders to collaborate.
A key differentiator of the VAST methodology is its practical approach. ThreatModeler was founded on the same principle as VAST: To be effective, threat modeling must scale across an organization’s entire DevOps portfolio, integrate seamlessly into an agile environment, and consistently provide actionable and accurate outputs for developers, security teams, and senior leadership alike.