Threat Modeling

Threat Modeling is a proactive security practice where you systematically identify threats, vulnerabilities, and attack vectors for your architecture before (or as) you build it.

Common Frameworks

• STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
• PASTA: Process for Attack Simulation and Threat Analysis (7-step risk-centric approach)
• AWS Threat Composer: free AWS tool for creating threat models based on your architecture

AWS-Specific Threats

• Overprivileged IAM roles enabling lateral movement
• Public S3 buckets or security groups exposing data/services
• Cross-account trust relationships being abused
• Credential exposure through metadata service (IMDSv1)
• Supply chain attacks through third-party Lambda layers or container images

Process

1. Define what you're building (architecture diagram)
2. Identify threats (what could go wrong)
3. Assess risk (likelihood × impact)
4. Design mitigations (security controls)
5. Validate (penetration testing, red team)

How It Goes Wrong in Practice

The most common failure is the perimeter-only model. Teams diagram the internet-facing edge, enumerate injection and DDoS threats against the load balancer, and stop there. Meanwhile the actual attack surface in AWS is mostly identity: a third-party monitoring vendor is granted a cross-account role, the trust policy names the vendor's account but omits an sts:ExternalId condition, and the architecture is now exposed to the confused deputy problem, where another customer of that same vendor can potentially direct the vendor's service at your account. This is a documented AWS attack pattern with a documented fix, yet it rarely appears in threat models written by teams thinking in terms of firewalls rather than trust relationships.

The second failure is the frozen model. A solid threat model gets produced for the launch review, then the architecture drifts: a new Lambda function gets an over-broad execution role, a bucket becomes cross-account shared, an SQS queue gets a wildcard resource policy. Eighteen months later the model describes a system that no longer exists. Treat the threat model as a living artifact that changes with every significant architecture change, not as launch paperwork.

Practical Tooling and Checks

Threat Composer is an open source AWS Labs project (Apache 2.0 licensed) with a hosted version at awslabs.github.io/threat-composer. It gives you a structured threat grammar so threat statements come out consistent and actionable, links assumptions to threats and mitigations, shows an insights dashboard on model quality, and exports to JSON, Markdown, DOCX, and PDF, which makes it easy to keep the model in the same repository as the code it describes.

To validate one recurring class of modeled threats (unintended access paths) against reality, check whether IAM Access Analyzer is actually running in your accounts:

aws accessanalyzer list-analyzers --type ACCOUNT

An empty analyzers array means nothing is continuously checking for resources shared outside your zone of trust, so the "cross-account trust abused" line in your threat model has no corresponding detective control. Access Analyzer also supports organization-wide and unused-access analyzer types, which map directly to the lateral movement and overprivilege threats listed above.

Frequently Asked Questions

When should threat modeling happen?

Ideally at design time, when mitigations are cheap because nothing is built yet, and then again at every significant architecture change: a new external integration, a new data store holding sensitive data, a new cross-account trust. A lightweight one-hour session per change beats an exhaustive annual exercise that is stale by the time it is signed off.

Do I need a formal framework like STRIDE?

No, but structure helps. STRIDE is a checklist that stops you from fixating on the threats you find most interesting and forgetting categories like repudiation or tampering. For AWS workloads, the practical move is to walk each trust boundary in the architecture (internet to VPC, account to account, service to service) and ask the STRIDE questions at each one.

Who should be in the room?

At minimum the people who built the system and one person whose job is to think adversarially. Threat models written by security teams alone miss how the system actually works; models written by builders alone miss how systems actually get attacked. The tooling matters far less than having both perspectives present. Keep the output small and testable: a threat statement, the mitigation you chose, and where that mitigation lives in code or configuration. A model whose mitigations can be checked automatically, in CI or through detective controls like Access Analyzer, is the one that survives contact with the next reorganization.