📖 STRIDE Threat Modeler Complete Guide
Everything you need to know to create professional threat models for your applications and systems.
📑 Table of Contents
1 Getting Started
The STRIDE Threat Modeler guides you through a structured process to identify and document security threats in your system. Here's how to begin:
🆕 Starting Fresh
- Click "New Model" in the toolbar
- Give your system a name
- Follow the wizard steps in order
📚 Using a Template
- Click "Templates" in the toolbar
- Choose a pre-built architecture
- Customize it for your needs
💡 Tip: Your work is automatically saved to your browser's local storage. You can close the tab and come back later without losing progress.
2 System Information
The first step is documenting your system's basic information. This appears in all reports and helps stakeholders understand what's being modeled.
| Field | Description | Example |
|---|---|---|
| Name | System or application name | "Customer Portal v2" |
| Description | What the system does | "Web app for customer account management" |
| Version | Model version number | "1.0", "2.3" |
| Scope | What's included/excluded | "Frontend and API, excludes CDN" |
3 Adding Components
Components are the building blocks of your system. Add all significant parts that process, store, or transmit data.
Component Types
Apache, Nginx, IIS
MySQL, PostgreSQL, MongoDB
REST, GraphQL, gRPC
Users, third-party services
Microservices, workers
AWS S3, Azure Blob, etc.
Trust Zones
Assign each component to a trust zone to define security boundaries:
Untrusted
Semi-trusted
Trusted
Highly trusted
4 Data Flows & Trust Boundaries
Data flows show how information moves between components. This is critical for identifying where threats can occur.
For each data flow, specify:
- → Source & Target: Which components are connected
- → Label: What data is being transmitted (e.g., "User credentials", "API response")
- → Data Type: Classification of the data (PII, credentials, public, etc.)
- → Protocol: How it's transmitted (HTTPS, gRPC, WebSocket, etc.)
- → Encrypted: Whether the data is encrypted in transit
⚠️ Trust Boundary Crossings: Flows between different trust zones are automatically flagged as "crossing trust boundaries" - these are high-priority areas for threat analysis.
5 STRIDE Analysis
STRIDE is Microsoft's threat classification framework. For each component and data flow, consider these threat categories:
Spoofing
Pretending to be someone or something else
Examples: Stolen credentials, session hijacking, IP spoofing, fake certificates
Ask: Can an attacker pretend to be a legitimate user or system?
Tampering
Modifying data or code without authorization
Examples: SQL injection, parameter manipulation, binary patching, man-in-the-middle
Ask: Can an attacker modify data in transit or at rest?
Repudiation
Denying having performed an action
Examples: Missing audit logs, unsigned transactions, deleted evidence
Ask: Can a user deny performing an action, with no way to prove otherwise?
Information Disclosure
Exposing data to unauthorized parties
Examples: Data breaches, verbose errors, insecure logging, unencrypted storage
Ask: Can sensitive information be exposed to unauthorized users?
Denial of Service
Making a system unavailable
Examples: Resource exhaustion, crash bugs, network flooding, algorithmic complexity attacks
Ask: Can an attacker make the system unavailable to legitimate users?
Elevation of Privilege
Gaining higher access than authorized
Examples: Privilege escalation, IDOR, broken access control, JWT tampering
Ask: Can an attacker gain access to resources they shouldn't have?
🤖 AI Suggestions: Click "Suggest Threats" on any component to get auto-generated threats based on the component type. You can accept, modify, or reject suggestions.
New Features
🔍 Search & Filter Threats
Use the search box to filter threats by keyword. Filter by status (Identified, Mitigated, Accepted, Transferred) using the dropdown.
🏷️ CWE Auto-Suggestions
The tool automatically suggests relevant CWE IDs based on your threat title keywords (e.g., "SQL injection" → CWE-89).
📚 Threat Library Import
Import pre-built threat libraries in JSON or CSV format. Great for standardizing threats across multiple projects.
⚠️ Trust Boundary Warnings
Automatic warnings when data flows cross trust boundaries without encryption. Helps identify high-risk data transfers.
6 Risk Scoring (DREAD & CVSS)
The tool supports two industry-standard scoring methods. You can toggle between DREAD and CVSS 3.1 based on your organization's preference.
Toggle Scoring Method
Use the toggle in the Scoring section to switch between DREAD (simpler, faster) and CVSS 3.1 (industry standard, more detailed).
DREAD Scoring
DREAD helps prioritize threats by scoring them on five factors. Each factor is rated 1-10, and the average gives the overall risk score.
| Factor | Question | Low (1-3) | Medium (4-6) | High (7-10) |
|---|---|---|---|---|
| Damage | How bad is the impact? | Minor disruption | Data leak | Full compromise |
| Reproducibility | How easy to reproduce? | Very difficult | Sometimes works | Always works |
| Exploitability | What skill is needed? | Expert required | Some skill | Script kiddie |
| Affected Users | How many impacted? | Single user | Some users | All users |
| Discoverability | How easy to find? | Hidden | Requires effort | Obvious |
CVSS 3.1 Scoring
The Common Vulnerability Scoring System (CVSS) provides a standardized, industry-recognized method for rating security vulnerabilities. The tool calculates the Base Score from 8 metrics.
Exploitability Metrics
- • Attack Vector: Network, Adjacent, Local, Physical
- • Attack Complexity: Low or High
- • Privileges Required: None, Low, High
- • User Interaction: None or Required
Impact Metrics
- • Confidentiality: None, Low, High
- • Integrity: None, Low, High
- • Availability: None, Low, High
- • Scope: Unchanged or Changed
💡 Tip: CVSS scores range from 0.0 to 10.0. The tool automatically calculates the Base Score and severity rating (None, Low, Medium, High, Critical) based on your selections.
7 Adding Mitigations
For each threat, document the security controls that reduce or eliminate the risk.
Mitigation Status
- ⏳ Identified - Threat recognized, no action yet
- ✅ Mitigated - Controls in place
- ⚡ Accepted - Risk accepted as-is
- ↗️ Transferred - Risk passed to third party
Good Mitigations Include:
- ✓ Specific control name
- ✓ Implementation details
- ✓ Who is responsible
- ✓ Timeline for implementation
- ✓ How effectiveness is measured
8 Attack Paths
Attack paths chain multiple threats together to show realistic attack scenarios. This helps prioritize which threats to address first.
Example Attack Path:
Attacker exploits SQL injection to extract password hashes, cracks admin credentials, and gains full system access.
9 Reports & Export
Generate professional reports in multiple formats:
PDF Report
Complete formatted report for stakeholders
HTML Report
Self-contained web page to share
Word Document (.docx)
OOXML format, editable in Word/LibreOffice
Markdown
For documentation systems (Confluence, GitHub)
CSV Export
Import threats to Jira, Excel, or other tools
Copy to Clipboard
Quick paste into any document
Report Tabs
- Full Report: Complete detailed view with all threats and mitigations
- Executive Summary: High-level overview with key metrics and risk scores
- Risk Heat Map: Visual matrix of threats by component and STRIDE category
10 Templates & Versioning
📚 Built-in Templates
Start with pre-configured architectures:
- • Web Application (3-tier)
- • Microservices Architecture
- • Mobile App with Backend
- • API Gateway Pattern
- • And more...
📜 Version History
Track changes over time:
- • Save snapshots with descriptions
- • Restore previous versions
- • Compare changes between versions
- • Export specific versions
11 Best Practices
✅ Do
- • Include all external interfaces
- • Document trust boundaries clearly
- • Be specific about data types
- • Update models when architecture changes
- • Review with development teams
- • Prioritize high-risk threats first
❌ Don't
- • Skip components because they seem "safe"
- • Use generic threat descriptions
- • Ignore accepted risks without documentation
- • Create threat models in isolation
- • Treat this as a one-time exercise
- • Over-complicate the model
12 Frequently Asked Questions
How often should I update my threat model?
Update your threat model whenever there are significant architecture changes, new features, or after security incidents. At minimum, review quarterly.
Is my data stored anywhere?
All data is stored locally in your browser's localStorage. Nothing is sent to any server. Use Export/Import to backup your work or share with others.
Can I share my threat model with my team?
Yes! Use the Export button to save a JSON file, then share it. Team members can Import the file to view or edit. You can also export as HTML for read-only sharing.
What's the difference between STRIDE and DREAD?
STRIDE is a classification framework for categorizing threats. DREAD and CVSS are scoring frameworks for prioritizing those threats by risk level. STRIDE categorizes threats (what type), while scoring methods rate severity (how dangerous).
Should I use DREAD or CVSS scoring?
Use DREAD for quick assessments and internal threat models. Use CVSS 3.1 when you need industry-standard scores for compliance, vendor communication, or vulnerability databases. Many organizations prefer CVSS for formal security documentation.
Should I use DREAD or CVSS scoring?
Use DREAD for quick assessments and internal threat models. Use CVSS 3.1 when you need industry-standard scores for compliance, vendor communication, or vulnerability databases. Many organizations prefer CVSS for formal security documentation.
Should I use DREAD or CVSS scoring?
Use DREAD for quick assessments and internal threat models. Use CVSS 3.1 when you need industry-standard scores for compliance, vendor communication, or vulnerability databases. Many organizations prefer CVSS for formal security documentation.