Threat Modeling

Threat modeling is a structured approach to identifying, quantifying, and addressing security threats to a system. It should be performed during the design phase and updated throughout the development lifecycle.

What is Threat Modeling?

Threat modeling answers four key questions:

When to Perform Threat Modeling

STRIDE Threat Model

Microsoft's STRIDE framework categorizes threats by type:

STRIDE per Element

Apply STRIDE based on system element type:

DREAD Risk Rating

Quantify threat severity using DREAD scoring:

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

Threat Modeling Process

Step 1: Define Scope

Document the system boundaries:

Step 2: Create Data Flow Diagram

Document how data moves through the system:

Step 3: Identify Threats

For each data flow and component, apply STRIDE:

Step 4: Document Mitigations

For each identified threat, define controls:

Step 5: Validate and Review

• Review threat model with security team
• Verify mitigations are implemented
• Update model when system changes
• Track remediation of open items

Threat Modeling Templates

Threat Card Template

## Threat: [Threat Name]

**ID**: T-001
**Category**: [STRIDE Category]
**Component**: [Affected Component]
**Data Flow**: [Affected Data Flow]

### Description
[Detailed description of the threat]

### Attack Scenario
1. Attacker does X
2. This causes Y
3. Resulting in Z

### Impact
- Confidentiality: [High/Medium/Low]
- Integrity: [High/Medium/Low]
- Availability: [High/Medium/Low]

### DREAD Score
- Damage: X/10
- Reproducibility: X/10
- Exploitability: X/10
- Affected Users: X/10
- Discoverability: X/10
- **Total**: X.X

### Mitigations
| Control | Description | Status |
|---------|-------------|--------|
| [Control 1] | [Description] | [Status] |

### References
- [Related standards, CVEs, etc.]

Common Threat Patterns

Authentication Threats

Authorization Threats

Data Threats

Tools for Threat Modeling

Threat Modeling for Compliance

FDA Requirements (Medical Devices)

• Document all identified threats
• Map threats to mitigations
• Include in Design History File (DHF)
• Update with design changes

HIPAA Requirements

• Focus on PHI data flows
• Document access controls
• Include in security risk assessment
• Annual review required

FedRAMP Requirements

• Map to NIST SP 800-53 controls
• Document in System Security Plan
• Include in security assessment
• Continuous monitoring updates

Best Practices

Do

• Include threat modeling in design phase
• Involve developers, security, and ops
• Update models when system changes
• Prioritize based on risk scores
• Document assumptions and trust boundaries
• Link threats to specific mitigations

Don't

• Skip threat modeling for "simple" features
• Create models and never update them
• Ignore threats because they seem unlikely
• Focus only on external attackers
• Treat threat modeling as a checkbox
• Keep models separate from development docs

Related Resources

• Security Overview
• Secure Coding
• Vulnerability Scanning
• Microsoft Threat Modeling Tool
• OWASP Threat Dragon

Compliance

This section fulfills ISO 13485 requirements for risk management (7.1) and design inputs (7.3.3), and ISO 27001 requirements for threat intelligence (A.5.7), risk assessment (A.5.8), and secure architecture (A.8.27).

View full compliance matrix