STRIDE Threat Modeling

Best Practice: STRIDE Threat Modeling

STRIDE is a structured method for finding security threats in a system design. The name is an acronym for six threat categories: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Developed at Microsoft, STRIDE guides teams to examine each component and data flow and ask which of these threats could apply. It matters because it makes threat modeling systematic instead of relying on intuition. By categorizing threats, teams find gaps they would otherwise miss and can plan mitigations before any code is written. For a developer it converts a blank-page "what could go wrong?" into six concrete prompts; for a leader it produces an auditable record of risks considered and mitigated. STRIDE pairs naturally with data flow diagrams, which is why trust boundaries, where data crosses a privilege line, deserve the closest attention. A good model is short and frequent rather than long and rare. Many teams run a one-hour STRIDE session per significant design change, focusing on the few components that handle sensitive data or sit on a trust boundary, and capture the resulting mitigations directly as backlog items so nothing is lost.

Step-by-Step Implementation Guidance

1. Draw a data flow diagram of the system, including processes, data stores, and trust boundaries.
2. For each element, walk through the six STRIDE categories and ask how each threat could occur.
3. Record each plausible threat with the affected component.
4. Rate threats by likelihood and impact to prioritize them.
5. Define a mitigation for each significant threat (for example authentication counters spoofing).
6. Turn mitigations into tracked requirements or backlog items.
7. Re-run the model when the architecture or trust boundaries change.

Common Mistakes Teams Make When Ignoring This Practice

• Relying on ad hoc brainstorming that misses entire threat categories.
• Skipping trust boundaries, the places where most real attacks occur.
• Producing a threat list but never converting it into mitigations.
• Modeling once at the start and never updating after design changes.
• Treating threat modeling as a security-team-only activity instead of involving developers.
• Modeling only the happy path and ignoring error states and administrative interfaces where threats hide.

Tools and Techniques That Support This Practice

• The Microsoft Threat Modeling Tool for diagramming and auto-suggesting threats.
• OWASP Threat Dragon, an open-source threat modeling tool.
• Data flow diagrams to map components and trust boundaries.
• DREAD or simple likelihood-impact scoring to prioritize threats.
• Backlog and issue trackers to manage mitigations as requirements.
• Lightweight threat-modeling templates that map each STRIDE category to a default mitigation.

How This Practice Applies to Different Migration Types

• Cloud Migration: Model new trust boundaries introduced by cloud services and shared responsibility.
• Database Migration: Examine tampering and information disclosure threats on new data flows.
• SaaS Migration: Model the integration points and data shared with the new vendor.
• Codebase Migration: Re-model components whose responsibilities or boundaries change during the rewrite.

Checklist

• Drew a data flow diagram with trust boundaries
• Walked each element through all six STRIDE categories
• Recorded plausible threats per component
• Prioritized threats by likelihood and impact
• Defined a mitigation for each significant threat
• Tracked mitigations as requirements
• Scheduled re-modeling on architecture changes