Threat Modeling

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.

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:

| Classification | Definition | Examples | Requirements | |---------------|-----------|----------|-------------| | Restricted | Compromise causes severe harm to customers or business. Regulatory implications. | Payment card numbers, SSNs, authentication credentials, encryption keys | Encrypted at rest AND in transit. Access logged. Minimal retention. Need-to-know access. Annual audit. | | Confidential | Internal business data. Competitive advantage if disclosed. | Customer PII (name, email, address), internal financial data, unreleased product plans | Encrypted at rest AND in transit. Access controlled by role. Retention policy enforced. | | Internal | Not public but low sensitivity. Operational data. | Service metrics, internal documentation, team rosters, non-sensitive logs | Encrypted in transit. Access controlled by team. Standard retention. | | Public | Intended for public consumption. | Marketing content, public documentation, open-source code | Integrity protection (prevent tampering). No confidentiality requirements. |

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:

| Category | Threat | Question to Ask | Example | |----------|--------|----------------|---------| | Spoofing | Identity falsification | Can an attacker pretend to be someone/something else? | Attacker forges JWT to impersonate another user | | Tampering | Data modification | Can an attacker modify data in transit or at rest? | Man-in-the-middle modifies API request; attacker modifies S3 object | | Repudiation | Denying actions | Can an actor deny performing an action with no proof? | Admin deletes records with no audit trail | | Information Disclosure | Data leakage | Can an attacker access data they shouldn't? | Error messages expose internal system details; logs contain PII | | Denial of Service | Availability disruption | Can an attacker make the system unavailable? | Unbounded request causes OOM; regex DoS; resource exhaustion | | Elevation of Privilege | Unauthorized access escalation | Can an attacker gain higher privileges? | SSRF to access instance metadata; SQL injection to admin role |

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

| Pattern | Threat | Mitigation | |---------|--------|-----------| | Shared IAM role across services | Compromise of one service = compromise of all | Separate role per service, minimum permissions | | Wildcard resource in policy | Any resource accessible, not just intended ones | Explicit ARNs; use conditions for dynamic resources | | No MFA on privileged operations | Credential theft = full access | Require MFA for all human privileged operations | | Long-lived access keys | Keys leaked in code/logs = persistent access | Use IAM roles with temporary credentials; rotate keys <90 days | | Instance metadata accessible | SSRF → credential theft via 169.254.169.254 | IMDSv2 (require token); restrict network access to metadata | | Over-scoped Lambda execution role | Compromised function has broad access | Least privilege per function; separate roles per Lambda |

5. Encryption Requirements

Encryption Decision Matrix

| Data State | Classification: Restricted | Classification: Confidential | Classification: Internal | |-----------|---------------------------|-----------------------------|-----------------------| | At rest | KMS CMK (team-managed key), key rotation enabled | KMS CMK or AWS-managed key | AWS-managed key or SSE-S3 | | In transit | TLS 1.2+ (mandatory) | TLS 1.2+ (mandatory) | TLS 1.2+ (recommended) | | In memory | Clear from memory after use; don't log | Standard precautions | Standard precautions | | In backups | Same encryption as primary | Same encryption as primary | AWS-managed encryption | | In logs | MUST NOT appear in logs | Mask/redact; tokenize | Acceptable in logs |

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

| Strategy | Implementation | Reduces Blast Radius By | |----------|---------------|------------------------| | Service isolation | Separate IAM roles per service | Prevents lateral movement via credentials | | Network segmentation | Security groups with explicit allow lists | Prevents network-based lateral movement | | Account boundaries | Separate AWS accounts for different trust levels | Hard boundary; cross-account requires explicit grant | | Data compartmentalization | Different encryption keys per data domain | Compromised key exposes only one domain | | Privilege separation | Read and write through different roles/paths | Compromised read path can't modify data | | Secret rotation | Automated, frequent rotation of all secrets | Limits window of exposure for leaked secrets | | Circuit breakers | Rate limits between services | Prevents cascading resource exhaustion |

Blast Radius Scoring

Rate each component:

| Score | Blast Radius | Criteria | |-------|-------------|----------| | Critical | System-wide compromise | Component has admin access, cross-service credentials, or access to encryption keys for multiple services | | High | Multiple services affected | Component can access data or systems beyond its own boundary | | Medium | Single service affected | Compromise is contained to this service's data and functionality | | Low | Minimal impact | Component is stateless, has no persistent data access, and is easily replaced |

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

7. Common Attack Patterns (Cloud-Specific)

| Attack | Vector | Mitigation | |--------|--------|-----------| | SSRF to metadata | Application fetches attacker-controlled URL → 169.254.169.254 | IMDSv2; block metadata IP in application egress | | Confused deputy | Attacker tricks your service into acting on their behalf | External ID in cross-account roles; validate caller identity | | S3 bucket enumeration | Predictable bucket names → unauthorized access | Random bucket name suffixes; block public access; bucket policies | | Lambda event injection | Malicious input in event payload | Validate and sanitize all event fields; treat events as untrusted | | IAM privilege escalation | iam:PassRole + lambda:CreateFunction = arbitrary code execution as any role | Restrict iam:PassRole to specific role ARNs; permissions boundaries | | Supply chain attack | Compromised dependency in build pipeline | Pin dependencies; verify checksums; scan for vulnerabilities; use private registry | | Log injection | Attacker injects malicious content into logs → exploits log viewers | Sanitize log output; structured logging; separate log viewers from production |

Mechanisms Over Good Intentions

| Intention | Mechanism | |-----------|-----------| | "I'll encrypt sensitive data" | KMS key policies that deny unencrypted writes; S3 bucket policies that require SSE | | "I'll follow least privilege" | IAM Access Analyzer reviews weekly; over-permissioned roles auto-generate tickets | | "I'll audit access to sensitive data" | CloudTrail data events mandatory for all Restricted/Confidential data stores | | "I'll keep secrets safe" | Secrets Manager with automated rotation; credential scanning in CI blocks commits with secrets | | "I'll limit blast radius" | Separate AWS accounts per trust boundary; network isolation verified by automated tests |

Common Rationalizations

| What They Say | Why It's Wrong | What To Do Instead | |---------------|---------------|-------------------| | "We'll add security later, we need to ship fast" | Security bolted on after the fact is expensive and incomplete. Architecture decisions made without threat modeling create vulnerabilities that require re-architecture to fix. | Threat model during design. It takes 2-4 hours. Re-architecting for security later takes weeks. | | "We're not a target; attackers focus on bigger companies" | Automated attacks don't discriminate. Bots scan every public endpoint. Supply chain attacks target small components. You ARE a target the moment you have a public endpoint or store customer data. | Model threats regardless of perceived risk. The model will tell you which threats are low-likelihood. Don't skip the analysis. | | "Our data isn't that sensitive" | Have you classified it? PII includes name + email. Payment data includes partial card numbers. Internal data includes access patterns that reveal business strategy. | Classify your data formally. You may be surprised what's actually Confidential when you apply the classification framework. | | "IAM is too complex; we'll use broad permissions and tighten later" | Tightening permissions breaks things. Teams never tighten. Broad permissions persist forever and become the assumed blast radius. | Start with zero permissions. Add one permission at a time. Use IAM Access Analyzer to verify you're not over-provisioned. | | "Encryption at rest doesn't matter if the network is secure" | Networks are breached. Insiders exist. Backups are stolen. Disks are improperly decommissioned. Encryption at rest is defense in depth, not redundancy. | Encrypt at rest. Always. The cost is negligible. The protection is essential. |

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)

-

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: robisson
• Source: robisson/build-like-amazon-agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.