Threat Modeling Guide

Threat Modeling Guide¶

Overview¶

This guide provides developers and architects with comprehensive guidance on implementing threat modeling throughout the software development lifecycle. Threat modeling is essential for building secure systems by proactively identifying and mitigating security risks before they become vulnerabilities in production.

For guidance on Non-Functional Requirements (NFRs), see the Non-Functional Requirements Guide.

When to Apply Threat Modeling¶

• New feature development: Before design begins
• Architecture changes: When modifying system boundaries or data flows
• Third-party integrations: When adding external dependencies
• Pre-release: As part of security and quality gates
• Incident response: After security incidents to prevent recurrence

Quick Start Checklist¶

For New Projects:¶

• Create initial threat model during architecture phase
• Establish security controls and mitigation strategies
• Document threat model in project repository
• Track mitigations as backlog items

For Existing Projects:¶

• Review and update existing threat models
• Assess new threats from recent changes
• Update security controls and monitoring
• Validate effectiveness of current mitigations

Threat Modeling¶

Threat modeling is a systematic approach to identify, assess, and mitigate security threats early in the development lifecycle. It helps teams proactively address security concerns before they become vulnerabilities in production.

Core Principles¶

• Shift Left: Address security during design, not after deployment
• Systematic Approach: Use structured methodologies for consistent results
• Collaborative Process: Involve developers, architects, and security teams
• Living Document: Update threat models as systems evolve
• Risk-Based: Focus on high-impact, high-likelihood threats

Threat Modeling Process¶

1. Define System Scope and Objectives¶

• Identify system boundaries and trust boundaries
• Define security objectives and compliance requirements
• Document data classifications and sensitivity levels
• Establish threat modeling scope (entire system vs. specific components)

2. Create Architecture Diagrams¶

Create detailed data flow diagrams including:

• System Components: Applications, services, databases, external systems
• Data Flows: How data moves between components
• Trust Boundaries: Where privilege levels change
• Entry/Exit Points: User interfaces, APIs, file uploads
• Data Stores: Databases, caches, file systems

3. Identify Threats Using STRIDE¶

Apply the STRIDE framework to systematically identify threats:

For each component and data flow, ask:

• Can someone spoof identity here?
• Can data be tampered with in transit or at rest?
• Could actions be denied or disputed?
• Could sensitive information be disclosed?
• Could the service be made unavailable?
• Could someone gain elevated privileges?

4. Risk Assessment Using DREAD¶

After identifying threats with STRIDE, use the DREAD framework to assess and quantify the risk level of each threat:

DREAD Scoring Matrix¶

Rate each factor on a scale of 1-3 or 1-10:

Damage Potential (Impact)

• High (3): Complete system compromise, data breach, financial loss
• Medium (2): Partial system compromise, limited data exposure
• Low (1): Minor impact, limited functionality affected

Reproducibility

• High (3): Attack works every time with minimal effort
• Medium (2): Attack works most of the time with some effort
• Low (1): Attack is difficult to reproduce consistently

Exploitability

• High (3): No special tools or skills required, easily automated
• Medium (2): Some specialized tools or knowledge required
• Low (1): Advanced skills, custom tools, or physical access required

Affected Users

• High (3): All users, anonymous users, or default installation
• Medium (2): Some users, authenticated users, or specific configuration
• Low (1): Administrative users only or very specific conditions

Discoverability

• High (3): Vulnerability is obvious, published, or easily found
• Medium (2): Vulnerability can be found with analysis
• Low (1): Vulnerability is very hard to discover

Risk Calculation¶

Total Risk Score = (D + R + E + A + D) / 5

Risk Level Classification:

• High Risk (2.5-3.0): Immediate attention required
• Medium Risk (1.5-2.4): Schedule for next release
• Low Risk (1.0-1.4): Fix when convenient or accept risk

DREAD Assessment Example¶

Threat: SQL Injection in user login form

5. Prioritize Risks Using Combined Assessment¶

Combine STRIDE identification with DREAD scoring to prioritize threats:

• High DREAD Score (2.5-3.0) + High Business Impact: Address immediately
• Medium DREAD Score (1.5-2.4) + Medium Business Impact: Schedule for next release
• Low DREAD Score (1.0-1.4) + Low Business Impact: Fix when convenient or accept risk

Consider additional factors:

• Regulatory Requirements: Compliance mandates may elevate priority
• Business Context: Customer-facing vs. internal systems
• Exploit Trends: Current attack patterns in the threat landscape
• Mitigation Cost: Balance risk reduction against implementation effort

6. Design Mitigations and Controls¶

For each high-priority threat, implement appropriate controls:

Authentication & Authorization¶

• Multi-factor authentication (MFA)
• Role-based access control (RBAC)
• OAuth 2.0 / OpenID Connect
• API key management

Data Protection¶

• Encryption in transit (TLS 1.3+)
• Encryption at rest (AES-256)
• Data masking and tokenization
• Secure key management (Azure Key Vault)

Input Validation & Sanitization¶

• Server-side validation
• SQL injection prevention
• Cross-site scripting (XSS) protection
• File upload security

Monitoring & Detection¶

• Security logging and SIEM integration
• Anomaly detection
• Real-time alerting
• Audit trails

7. Document and Track¶

• Create threat model documents in project repository
• Track mitigations as security backlog items
• Link threats to specific features or user stories
• Include threat model reviews in definition of done
• Document DREAD scores for each identified threat
• Maintain risk register with periodic reviews

Tools and Templates¶

Recommended Tools¶

• Microsoft Threat Modeling Tool: Free, STRIDE-based modeling
• OWASP Threat Dragon: Open-source, web-based tool
• Miro/Lucidchart: For collaborative diagram creation
• ThreatSpec: Code-based threat modeling

Documentation Template¶

# Threat Model: [System Name]

## System Overview

- Business purpose and objectives
- Key stakeholders and users
- Compliance requirements

## Architecture Diagram

[Include data flow diagram]

## Assets and Data Classification

| Asset          | Classification | Sensitivity |
| -------------- | -------------- | ----------- |
| User PII       | Confidential   | High        |
| Financial data | Restricted     | Critical    |

## Identified Threats

| ID   | Component   | Threat                 | STRIDE Category | Risk Level | Mitigation          |
| ---- | ----------- | ---------------------- | --------------- | ---------- | ------------------- |
| T001 | API Gateway | Unauthenticated access | Spoofing        | High       | Implement OAuth 2.0 |

## Security Controls

[List implemented and planned controls]

## Review and Updates

- Last reviewed: [Date]
- Next review: [Date]
- Change triggers: [Architecture changes, new features]

Integration with Development Workflow¶

Design Phase¶

• Include threat modeling in architecture reviews
• Require threat model approval before development begins
• Document security requirements derived from threat analysis

Development Phase¶

• Implement security controls identified in threat model
• Include threat-specific test cases
• Conduct secure code reviews focusing on identified threats

Testing Phase¶

• Penetration testing based on threat model findings
• Security scanning aligned with identified vulnerabilities
• Validate implemented controls effectiveness

Deployment Phase¶

• Security configuration review
• Monitoring setup for threat detection
• Incident response procedures for identified threats

Common Threat Scenarios¶

Web Applications¶

• Injection attacks: SQL, NoSQL, command injection
• Broken authentication: Session management flaws
• Cross-site scripting: Reflected, stored, DOM-based XSS
• Insecure direct object references: Authorization bypass

APIs¶

• Broken object-level authorization: Accessing other users' data
• Excessive data exposure: Returning sensitive information
• Mass assignment: Binding client input to internal objects
• Rate limiting: Preventing DoS attacks

Cloud Services¶

• Misconfigured security groups: Unintended network access
• Insecure storage: Publicly accessible S3 buckets
• Privilege escalation: Over-permissioned service accounts
• Data residency: Compliance with geographic restrictions

Getting Started: Step-by-Step Implementation¶

Week 1: Foundation¶

1. Team Training: Conduct threat modeling workshop
2. Tool Setup: Install Microsoft Threat Modeling Tool or OWASP Threat Dragon
3. Template Creation: Customize documentation templates for your organization
4. Initial Assessment: Identify 2-3 pilot projects for implementation

Week 2-3: Pilot Implementation¶

1. Create First Models: Develop threat models for pilot projects
2. Define NFRs: Establish quantitative requirements for pilot systems
3. Implement Controls: Begin security control implementation
4. Setup Monitoring: Configure basic monitoring for NFR tracking

Week 4: Review and Scale¶

1. Pilot Review: Assess effectiveness and gather feedback
2. Process Refinement: Update templates and procedures based on learnings
3. Team Rollout: Expand to additional development teams
4. Integration: Incorporate into existing SDLC processes

Resources and References¶

Threat Modeling Resources¶

• Microsoft Threat Modeling Tool
• OWASP Threat Dragon
• STRIDE Framework Training
• Microsoft Security Development Lifecycle
• OWASP Threat Modeling Process

NFR and Quality Resources¶

• ISO/IEC 25010 Quality Model
• NIST Cybersecurity Framework
• Azure Architecture Center
• Google Site Reliability Engineering
• OWASP ASVS