4.9 KiB
Threat Modelling with STRIDE
A structured approach to identifying, classifying, and mitigating security threats during the design phase.
STRIDE Categories
| Category | Threat | Violated Property | Example |
|---|---|---|---|
| S — Spoofing | Attacker pretends to be another user or system | Authentication | Stolen JWT used to access another user's data |
| T — Tampering | Attacker modifies data in transit or at rest | Integrity | Man-in-the-middle alters API request payload |
| R — Repudiation | Attacker denies performing an action | Non-repudiation | User disputes a financial transaction with no audit trail |
| I — Information Disclosure | Sensitive data exposed to unauthorized parties | Confidentiality | Error message leaks stack trace and database schema |
| D — Denial of Service | System made unavailable to legitimate users | Availability | Unbounded API request floods Lambda concurrency |
| E — Elevation of Privilege | Attacker gains higher access than authorized | Authorization | Regular user exploits IDOR to access admin endpoints |
Threat Modelling Process
Step 1: Define Scope
Identify what you are threat-modelling: a single microservice, a complete feature, or an entire system. Smaller scopes produce more actionable results.
Step 2: Create a Data Flow Diagram (DFD)
Draw the system showing:
- External entities: Users, third-party systems, partner APIs
- Processes: Lambda functions, ECS services, API Gateway
- Data stores: DynamoDB tables, S3 buckets, RDS instances
- Data flows: Arrows showing data movement, labelled with protocol and data type
- Trust boundaries: Lines separating zones of different trust levels (public internet, VPC, private subnet)
Step 3: Identify Threats
Walk through each element and data flow in the DFD. For each, ask the six STRIDE questions:
- Can an attacker spoof this identity?
- Can an attacker tamper with this data?
- Can an attacker deny this action?
- Can this component leak information?
- Can this component be denied service?
- Can an attacker elevate privilege through this component?
Step 4: Assess Risk
For each identified threat, score it using likelihood and impact.
Step 5: Define Mitigations
Map each threat to a specific countermeasure. Track mitigations as actionable tasks in the backlog.
Risk Scoring: Likelihood x Impact
Use a simple 3x3 or 5x5 matrix:
| Low Impact | Medium Impact | High Impact | |
|---|---|---|---|
| High Likelihood | Medium | High | Critical |
| Medium Likelihood | Low | Medium | High |
| Low Likelihood | Low | Low | Medium |
- Likelihood factors: Attack complexity, required access level, availability of exploits, attacker motivation.
- Impact factors: Data sensitivity, financial loss, regulatory penalties, reputational damage, blast radius.
The DREAD Model (Alternative Scoring)
Score each threat 1-10 on five dimensions, then average:
- Damage: How severe is the impact?
- Reproducibility: How reliably can the attack be repeated?
- Exploitability: How much skill/effort is required?
- Affected Users: How many users are impacted?
- Discoverability: How easy is the vulnerability to find?
DREAD is useful when STRIDE identifies many threats and you need to prioritize.
Attack Surface Analysis
Enumerate all entry points an attacker could target:
- Public API endpoints (API Gateway, ALB)
- Authentication flows (Cognito hosted UI, custom login)
- File upload endpoints (S3 pre-signed URLs)
- WebSocket connections
- Third-party integrations (webhooks, OAuth callbacks)
- Administrative interfaces (console access, SSH, bastion)
- CI/CD pipelines (build scripts, deployment credentials)
Minimize attack surface: disable unused endpoints, restrict network access, apply least-privilege IAM.
Mitigation Mapping
For each STRIDE category, common AWS mitigations include:
| Category | Mitigations |
|---|---|
| Spoofing | Cognito + MFA, mutual TLS, API key rotation, IAM roles (no long-lived credentials) |
| Tampering | HTTPS everywhere, S3 Object Lock, DynamoDB encryption, request signing |
| Repudiation | CloudTrail logging, application audit logs, DynamoDB Streams for change history |
| Information Disclosure | Encryption at rest (KMS), VPC endpoints, security groups, suppress verbose errors |
| Denial of Service | WAF rate limiting, API Gateway throttling, Lambda reserved concurrency, Shield Advanced |
| Elevation of Privilege | Least-privilege IAM, ABAC policies, input validation, IDOR checks in application logic |
When to Threat Model
- During design (Stage 3 of AI-DLC) before implementation begins.
- When adding a new external integration or data flow.
- When changing authentication or authorization mechanisms.
- After a security incident, to update the model with newly discovered threats.
- Review and refresh threat models at least annually.