Threat Modeling

Overview

Threat modeling is the systematic identification of security threats to a system BEFORE the system is built. It answers four questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job? You cannot secure a system by adding security after the fact—security must be designed in. Threat modeling is how you design it in.

A threat model is not a penetration test. Penetration testing finds bugs in implementation. Threat modeling finds flaws in design. A perfectly implemented system with a flawed design is still insecure. You do threat modeling at design time; you do pen testing at implementation time. Both are required; neither replaces the other.

When to Use

• During the design phase of any new service or feature
• When adding new data flows (especially customer data or credentials)
• When changing authentication or authorization mechanisms
• When adding new external-facing endpoints (API, web, mobile)
• When integrating with a new third-party service
• When changing trust boundaries (new service-to-service communication)
• When an incident reveals a class of vulnerability (model similar systems)
• Before any Design Bar Raiser review for systems handling sensitive data

Agent Persona

Load agents/security-guardian.md when reviewing the threat model. Use it to challenge trust boundaries, data classification, least privilege, encryption, blast radius, and missing abuse cases.

Template

Write the threat model into .bla/design/<feature-name>/threat-model.md — <service-name> when /onboard Path A produces the baseline off existing code — following skills/threat-modeling/templates/threat-model-template.md; that file is the shape of the threat model, never its destination. The template records the decisions this skill produces — classification, boundaries, STRIDE per crossing, IAM, encryption, blast radius, accepted risks — and deliberately does not restate the tables below, which are the authority. It uses this skill's own Critical/High/Medium/Low severities, mapped to the canonical levels in AGENTS.md → One Severity Scale and One Verdict Scale, and adds no new label.

Amazon Context

Threat models are living documents maintained alongside design documents. They are updated when the system changes, when new threat intelligence emerges, or when incidents reveal gaps. Every system that handles customer data, credentials, or payment information requires a formal threat model reviewed by security teams before launch.

The principle of "blast radius minimization" is paramount: design systems so that a compromise of one component cannot cascade to compromise the entire system. This drives decisions about service boundaries, IAM scope, encryption key separation, and network isolation.

The Process

1. Data Classification

Before identifying threats, classify the data your system handles:

Rule: A system's classification is determined by the HIGHEST classification of data it handles. A service that processes one Restricted field is a Restricted service.

2. System Decomposition

Create a Data Flow Diagram (DFD) that identifies:

Elements

• External entities: Users, third-party services, partner systems (outside your trust boundary)
• Processes: Your services, Lambda functions, containers, batch jobs
• Data stores: Databases, caches, S3 buckets, queues, logs
• Data flows: Every arrow between elements (API calls, events, file transfers)

Trust Boundaries

Draw lines around components that share the same trust level:

┌─────────────────────── Internet (Untrusted) ───────────────────────┐
│  [Browser]    [Mobile App]    [Partner API]                        │
└──────────────────────────┬─────────────────────────────────────────┘
                           │ TLS
┌──────────────────────────┼─── Public Subnet ───────────────────────┐
│                    [API Gateway + WAF]                              │
└──────────────────────────┬─────────────────────────────────────────┘
                           │ IAM Auth
┌──────────────────────────┼─── Private Subnet ──────────────────────┐
│                    [Application Service]                            │
│                           │                                        │
│              ┌────────────┼────────────┐                           │
│              ▼            ▼            ▼                           │
│        [DynamoDB]   [S3 Bucket]  [SQS Queue]                      │
└────────────────────────────────────────────────────────────────────┘
                           │ Cross-account role
┌──────────────────────────┼─── Separate Account ────────────────────┐
│                    [Audit Log Store]                                │
└────────────────────────────────────────────────────────────────────┘

Every crossing of a trust boundary is a potential attack surface.

3. STRIDE Analysis

For each element and data flow in the DFD, systematically analyze threats using STRIDE:

STRIDE Per Element

For each component in your DFD, fill in:

Component: [Name]
Trust Level: [What trust boundary is it in?]
Data Classification: [Highest classification of data it touches]

| STRIDE | Applicable? | Threat Scenario | Likelihood | Impact | Mitigation |
|--------|-------------|----------------|-----------|--------|-----------|
| Spoofing | Yes/No | [Specific scenario] | H/M/L | H/M/L | [Control] |
| Tampering | Yes/No | [Specific scenario] | H/M/L | H/M/L | [Control] |
| Repudiation | Yes/No | [Specific scenario] | H/M/L | H/M/L | [Control] |
| Info Disclosure | Yes/No | [Specific scenario] | H/M/L | H/M/L | [Control] |
| DoS | Yes/No | [Specific scenario] | H/M/L | H/M/L | [Control] |
| EoP | Yes/No | [Specific scenario] | H/M/L | H/M/L | [Control] |

4. IAM Boundary Design

Principles

1. Each service has its own IAM role. No shared roles between services.
2. Roles are scoped to minimum needed actions and resources. Use IAM Access Analyzer.
3. Cross-service access uses role assumption, not shared credentials.
4. Human access to production is time-bounded and audited. No persistent admin access.
5. Separate accounts for separate blast radii. Production, staging, and security tooling in different accounts.

IAM Threat Patterns

5. Encryption Requirements

Encryption Decision Matrix

Key Management

• Key per service: Each service has its own KMS key. Compromise of one service's key doesn't expose another service's data.
• Key per data classification: Restricted and Confidential data use different keys.
• Key rotation: Automatic annual rotation enabled. Manual rotation immediately on suspected compromise.
• Key access policy: Only the owning service's role can use the key for Encrypt/Decrypt. Admin access (for rotation, deletion) is a separate role.
• Cross-account key access: Grant via key policy, not IAM policy. Explicit deny for any principal not explicitly allowed.

6. Blast Radius Analysis

Blast radius = the extent of damage if a single component is fully compromised.

Analysis Process

For each component, answer:

1. If this component is fully compromised (attacker has complete control), what can they access?
2. What other systems trust this component? (follow the trust relationships)
3. What data can be exfiltrated? (follow the data flows)
4. Can the attacker move laterally? (check network access, shared credentials, role chaining)
5. What's the recovery time? (how long to detect, contain, and recover)

Blast Radius Containment Strategies

Blast Radius Scoring

Rate each component:

Any component scoring "Critical" must be re-architected to reduce blast radius.

7. Common Attack Patterns (Cloud-Specific)

Mechanisms Over Good Intentions

Common Rationalizations

Red Flags

• No threat model exists for a service handling customer data
• Threat model was written once and never updated (system has changed significantly since)
• STRIDE analysis is superficial ("Spoofing: N/A" for an authentication system)
• IAM policies use Resource: "*" with no documented justification
• Same encryption key used across multiple services
• No data classification has been performed; team can't articulate what classification their data falls under
• Blast radius analysis shows a single component compromise = system-wide breach
• Secrets (API keys, passwords, tokens) found in code repositories, config files, or logs
• No audit logging for access to Restricted or Confidential data
• Trust boundaries aren't defined; all services communicate freely without authentication
• No automated credential scanning in the CI pipeline
• IMDSv1 is enabled (allows SSRF-based credential theft)

Verification

• Data classification is documented for all data the system handles
• Data Flow Diagram exists showing all components, data stores, and trust boundaries
• STRIDE analysis completed for every component crossing a trust boundary
• IAM roles follow least privilege (verified by IAM Access Analyzer)
• Encryption requirements match data classification (see matrix above)
• Blast radius analysis completed; no "Critical" components exist without documented mitigation plan
• Secrets are stored in Secrets Manager/Parameter Store, never in code or config files
• Automated credential scanning runs in CI pipeline
• Audit logging enabled for all access to Restricted/Confidential data
• IMDSv2 enforced on all EC2 instances
• Network segmentation verified (security groups have explicit allow lists, not 0.0.0.0/0)
• Threat model reviewed by AppSec for any system handling Restricted data
• Threat model update schedule defined (at minimum: every major feature addition)

Tenets

1. Security is designed in, not bolted on. Threat modeling happens at design time. If you're threat modeling after launch, you're patching, not designing.
2. Blast radius above all. The most important security property is containment. A compromised component must not cascade. Design for breach, not just prevention.
3. Data classification drives everything. Encryption, access control, logging, retention—all determined by data classification. Classify first, then secure.
4. Assume breach. Design every component as if the adjacent component is already compromised. This drives proper authentication, authorization, and isolation between every boundary.
5. Least privilege is the default. Zero permissions until explicitly granted. Every grant is documented, justified, scoped, and auditable.