Structured Threat Model Analysis Using STRIDE

v20260618

security-threat-model

This skill generates a comprehensive, structured threat model for any given service or feature using the STRIDE framework. It guides users through identifying critical assets, defining trust boundaries, enumerating specific threats (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), assessing risk, and proposing concrete mitigation controls. Ideal for security design reviews and documentation.

Security Threat Modeling STRIDE Architecture Design Review

Get Skill

237 downloads

Overview

Security Threat Model Skill

Produce a complete STRIDE-based threat model for a service or feature. A threat model is not a list of things that could go wrong — it is a structured analysis of attackers, assets, boundaries, and controls that lets an engineering team make informed, documented security decisions.

A good threat model is specific enough that a new engineer can understand what is being protected, why each control exists, and what risk the team has accepted.

Required Inputs

Ask for these if not already provided:

Service name and description — what the service does, who uses it
Architecture overview — components, dependencies, data flows (a diagram description or ASCII diagram is fine)
Deployment environment — cloud provider, VPC/network topology, where it runs (Kubernetes, ECS, VMs, serverless)
Data sensitivity — what data does this service handle? PII, payment data, credentials, internal-only?
Existing controls — authentication method, encryption in transit/at rest, current WAF/firewall, existing security scanning
Trust levels — who are the principals? (anonymous public, authenticated users, internal services, admins)

Output Format

Security Threat Model: [Service Name]

Service: [Name] | Team: [Team name] Author: [Name] | Reviewed by: [Security lead / peer] Date: [Date] | Next review: [Date — recommend 6 months or after major architecture change] Classification: [Internal / Confidential]

1. Overview

[2–3 sentences describing the service, its role in the system, and the scope of this threat model. State what is in scope and what is explicitly out of scope.]

In scope:

[Component or data flow]
[Component or data flow]

Out of scope:

[e.g. Third-party payment processor internals]
[e.g. Corporate network / end-user devices]

2. Asset Register

Assets are the things worth protecting — data, capabilities, and reputational value.

Asset	Description	Sensitivity	Owner
[e.g. User PII]	Names, email addresses, profile data	High — GDPR-regulated	[Team]
[e.g. API credentials]	Service-to-service auth tokens	Critical	[Team]
[e.g. Session tokens]	User authentication state	High	[Team]
[e.g. Audit logs]	Record of user and admin actions	Medium	[Team]
[e.g. Service availability]	Uptime of the [X] endpoint	Medium	[Team]

Data classification key:

Critical — Credential material; exposure enables direct system compromise
High — PII, financial data, health data; regulated or high reputational impact
Medium — Internal configuration, non-sensitive business data
Low — Public information, anonymised data

3. Trust Boundaries and Architecture

Trust boundaries are the lines that separate zones with different trust levels. Threats often occur when data or requests cross a boundary.

  ┌─────────────────────────────────────────────────────────────────┐
  │  INTERNET (Untrusted)                                           │
  │                                                                 │
  │   [Public User]          [Bot / Attacker]                       │
  └──────────────────────────────┬──────────────────────────────────┘
                                 │ HTTPS
                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
                    Trust Boundary: Public → DMZ
                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
                                 ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │  DMZ / Edge Layer                                                │
  │   ┌────────────┐     ┌──────────────┐                           │
  │   │  WAF / CDN │────▶│  API Gateway │                           │
  │   └────────────┘     └──────┬───────┘                           │
  └──────────────────────────────┼───────────────────────────────────┘
                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
                    Trust Boundary: Edge → Application VPC
                    ─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
                                 ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │  Application VPC (Private)                                       │
  │   ┌──────────────┐     ┌────────────┐     ┌──────────────────┐  │
  │   │  [Service A] │────▶│ [Service B]│────▶│  [Database]      │  │
  │   └──────────────┘     └────────────┘     └──────────────────┘  │
  │                                ▲                                  │
  │                                │                                  │
  │   ┌──────────────┐             │                                  │
  │   │  Admin (IAM) │─────────────┘                                 │
  └──────────────────────────────────────────────────────────────────┘

Trust Boundaries identified:

Boundary	From	To	Auth mechanism	Encrypted
TB-1	Public internet	API Gateway	[JWT / OAuth / API key]	TLS 1.2+
TB-2	API Gateway	Service A	[mTLS / internal JWT / IAM role]	[Yes/No]
TB-3	Service A	Database	[Connection string + IAM / username+password]	[Yes/No]
TB-4	Admin	Service B	[IAM role / VPN + MFA]	TLS

4. STRIDE Threat Analysis

STRIDE is a threat classification framework. For each significant component, enumerate threats in each category.

STRIDE key:

S — Spoofing: Impersonating another user, service, or system
T — Tampering: Modifying data or code without authorisation
R — Repudiation: Denying an action occurred; insufficient audit trail
I — Information Disclosure: Exposing data to unauthorised parties
D — Denial of Service: Making the service unavailable
E — Elevation of Privilege: Gaining capabilities beyond what is authorised

Component: [API Gateway / Auth Layer]

ID	Category	Threat	Attack vector	Existing control
T-001	S	Attacker forges a JWT token to authenticate as another user	Weak signing key or algorithm confusion (alg:none)	[e.g. RS256 with key rotation / none]
T-002	S	Attacker replays a stolen session token	Theft via XSS or network sniff	[e.g. Token expiry + refresh rotation]
T-003	T	Attacker modifies request headers to bypass tenant isolation	Missing validation of tenant ID header	[e.g. Server-side tenant resolution / none]
T-004	R	No audit trail for admin authentication events	Logging not configured for auth failures	[e.g. CloudTrail enabled / none]
T-005	I	Auth error messages reveal whether an email exists	Verbose error responses	[e.g. Normalised error responses / none]
T-006	D	Credential stuffing exhausts rate limits and blocks legitimate users	Automated login attempts	[e.g. Rate limiting per IP + CAPTCHA / none]
T-007	E	Compromised low-privilege token used to call admin endpoint	Missing role check on admin routes	[e.g. RBAC middleware on all routes / none]

Component: [Application Service / Business Logic]

ID	Category	Threat	Attack vector	Existing control
T-008	T	SQL/NoSQL injection via unsanitised user input	Unparameterised queries	[e.g. ORM with parameterised queries / none]
T-009	T	Mass assignment — attacker sets fields they should not (e.g. `isAdmin: true`)	API accepts extra fields without allowlist	[e.g. Input validation / none]
T-010	I	Insecure direct object reference — user accesses another user's resource	Missing ownership check on resource ID	[e.g. Ownership middleware / none]
T-011	I	Sensitive data in application logs (PII, tokens)	Over-logging in debug mode	[e.g. Log scrubbing / none]
T-012	D	Unprotected expensive endpoint triggers large DB scan	No pagination or query cost limit	[e.g. Pagination enforced / none]
T-013	R	Business-critical state changes not logged	No audit event on [operation]	[e.g. Audit log table / none]

Component: [Database]

ID	Category	Threat	Attack vector	Existing control
T-014	I	Database exposed to internet (misconfigured security group)	Direct connection from outside VPC	[e.g. No public IP, security group restricts to app subnet]
T-015	I	Backup snapshots not encrypted or accessible to wrong accounts	Unencrypted snapshot, public S3	[e.g. Encrypted snapshots, private S3 bucket]
T-016	T	Privilege escalation via DB account with excessive permissions	App uses a superuser DB account	[e.g. Least-privilege DB role per service / none]
T-017	D	Runaway query or bulk delete causes data loss or outage	No query timeout or soft-delete	[e.g. Statement timeout, soft-delete on critical tables / none]

Component: [Internal Service-to-Service Communication]

ID	Category	Threat	Attack vector	Existing control
T-018	S	Rogue internal service impersonates a trusted service	No mutual authentication between services	[e.g. mTLS / service mesh / none]
T-019	I	Internal traffic sniffed on shared network	Unencrypted service-to-service calls	[e.g. Service mesh with TLS / none]
T-020	E	Compromised internal service calls privileged endpoints	No scoping on internal tokens	[e.g. Scoped service tokens / none]

5. Risk Register

Score each threat: Likelihood (1–5) × Impact (1–5) = Risk Score (1–25)

Priority bands: Critical (20–25) | High (12–19) | Medium (6–11) | Low (1–5)

ID	Threat summary	Likelihood	Impact	Score	Priority	Status
T-001	JWT forgery — auth bypass	2	5	10	Medium	[Open / Mitigated / Accepted]
T-002	Session token replay	3	4	12	High	[Open / Mitigated / Accepted]
T-007	Privilege escalation via missing role check	3	5	15	High	[Open / Mitigated / Accepted]
T-008	SQL injection	2	5	10	Medium	[Open / Mitigated / Accepted]
T-010	IDOR — cross-user data access	3	4	12	High	[Open / Mitigated / Accepted]
T-014	Database exposed to internet	1	5	5	Low	[Open / Mitigated / Accepted]
T-018	Rogue internal service impersonation	2	4	8	Medium	[Open / Mitigated / Accepted]

6. Mitigations Table

For every Open threat with priority Medium or above, define a specific mitigation.

ID	Threat	Mitigation	Owner	Target date	Ticket
T-002	Session token replay	Implement token rotation on refresh — invalidate old token server-side immediately	[Engineer name]	[Date]	[JIRA-123]
T-007	Privilege escalation	Add RBAC middleware to all `/admin/*` routes; write integration test for role boundary	[Engineer name]	[Date]	[JIRA-124]
T-010	IDOR	Add ownership assertion to all resource-fetching service methods; add to code review checklist	[Engineer name]	[Date]	[JIRA-125]
T-011	PII in logs	Audit logging calls for PII fields; add scrubbing to logger middleware	[Engineer name]	[Date]	[JIRA-126]
T-018	Rogue service impersonation	Enable mTLS via service mesh or issue scoped service tokens per service	[Engineer name]	[Date]	[JIRA-127]

7. Accepted Risks

Accepted risks are threats the team has decided not to mitigate right now. Every accepted risk must have a named owner and a review date.

ID	Threat	Reason for acceptance	Risk owner	Review date
T-014	Database public exposure	Database has no public IP assigned; control already in place — accepted as low likelihood	[Name]	[Date]
[ID]	[Threat]	[Reason — e.g. "Effort exceeds risk at current scale; re-evaluate at 10× traffic"]	[Name]	[Date]

8. Security Controls Summary

Control	Type	Covers threats	Implemented
JWT RS256 with 15-min expiry	Preventive	T-001, T-002	[Yes / Partial / No]
RBAC middleware on all routes	Preventive	T-007, T-020	[Yes / Partial / No]
Parameterised queries (ORM)	Preventive	T-008	[Yes / Partial / No]
Rate limiting (100 req/min per IP)	Preventive	T-006, T-012	[Yes / Partial / No]
CloudTrail / audit logging	Detective	T-004, T-013	[Yes / Partial / No]
Automated SAST in CI pipeline	Detective	T-008, T-009	[Yes / Partial / No]
Encrypted backups + private S3	Preventive	T-015	[Yes / Partial / No]
Least-privilege DB role	Preventive	T-016	[Yes / Partial / No]
Incident response runbook	Corrective	All	[Yes / Partial / No]

9. Review Cadence

Trigger	Action
Every 6 months	Full threat model review — update risk scores, close mitigated items
Major architecture change	Update trust boundary diagram and re-run STRIDE for new components
Security incident	Review relevant threats; add any newly discovered vectors
New data classification	Add assets to register; assess whether new STRIDE categories apply
Third-party dependency added	Assess supply chain threats for the new dependency

Next scheduled review: [Date] Review owner: [Name / Security lead]

Quality Checks

Every trust boundary is named and its authentication mechanism is specified — not left as "TBD"
Every Critical and High risk in the risk register has a mitigation with a named owner and a target date
Every accepted risk has a named risk owner and a review date — no unowned accepted risks
The asset register includes data sensitivity levels and at least one entry for credential material
STRIDE analysis covers all major components — not just the API layer
Mitigation actions are specific enough to become a ticket (not "improve security")
The ASCII trust boundary diagram matches the architecture description provided

Anti-Patterns

Do not restrict STRIDE analysis to only the API layer — threats exist at every component including the database and internal services
Do not leave mitigations as vague directives like "improve security" — every mitigation must be specific enough to become a ticket
Do not accept risks without a named owner and a review date — unowned accepted risks are not managed risks
Do not write a threat model that covers only theoretical threats — prioritise by likelihood and impact using the risk register
Do not omit the asset register — without knowing what is being protected, the STRIDE analysis has no anchor

Info

Category Development

Name security-threat-model

Version v20260618

Size 16.21KB

Source mohitagw15856/pm-claude-skills

Updated At 2026-06-19