Threat Modeling Skill — STRIDE Methodology

1. When to Use

If a target is provided via arguments, focus the review on: $ARGUMENTS

Invoke this skill whenever any of the following conditions are met:

• New service or microservice design — A new component is being introduced into the architecture and needs threat analysis before implementation begins.
• Architecture review — An existing system is undergoing redesign, migration, or significant refactoring (e.g., monolith-to-microservices, on-prem-to-cloud).
• PRD with infrastructure implications — A product requirements document describes features that involve new data stores, external integrations, authentication changes, or network topology modifications.
• API design — New or modified API endpoints are being defined, especially those that accept user input, handle authentication tokens, or expose sensitive data.
• Pre-launch security review — A system is approaching production deployment and requires a structured assessment of threats before go-live.
• Compliance-driven review — Regulatory requirements (SOC 2, PCI DSS, HIPAA, FedRAMP) mandate documented threat analysis.
• Incident post-mortem — A security incident has occurred and the team needs to re-evaluate the threat landscape to prevent recurrence.

2. Context the Agent Needs

Before beginning the threat model, gather the following. Mark each item as obtained or missing and proceed with what is available, noting gaps as assumptions.

• System description — High-level purpose, business context, and intended users.
• Component inventory — Services, databases, message queues, caches, CDNs, third-party APIs, serverless functions, and any other runtime components.
• Data flow descriptions — How data moves between components, including protocols (HTTPS, gRPC, AMQP), serialization formats (JSON, Protobuf), and transport security (TLS version, mTLS).
• Trust boundaries — Where authentication and authorization are enforced; boundaries between internal networks, DMZs, public internet, third-party services, and user devices.
• Authentication and authorization mechanisms — OAuth 2.0 flows, API keys, JWTs, SAML, RBAC/ABAC policies, service-to-service identity (SPIFFE/mTLS).
• Data classification — What data is stored or processed (PII, PHI, financial data, credentials, secrets) and its sensitivity level.
• Threat actor profiles — External attackers, malicious insiders, compromised supply chain, nation-state actors, automated bots.
• Compliance and regulatory requirements — Applicable standards (SOC 2, PCI DSS, HIPAA, GDPR, FedRAMP).
• Existing security controls — WAF, IDS/IPS, SIEM, secret management (Vault, AWS Secrets Manager), encryption at rest and in transit.
• Deployment environment — Cloud provider (AWS, GCP, Azure), Kubernetes, serverless, on-premises, hybrid.

3. Process

Step 1: Identify Assets and Entry Points

Enumerate all assets that an adversary would target and all entry points through which an attack could originate.

Assets:

• User credentials and session tokens
• Personally identifiable information (PII)
• Financial or payment data
• Intellectual property and proprietary business logic
• Cryptographic keys and secrets
• Audit logs and monitoring data
• Infrastructure control plane (CI/CD pipelines, IaC templates, container registries)

Entry Points:

• Public-facing API endpoints (REST, GraphQL, gRPC)
• Web application front-ends
• Mobile application interfaces
• Administrative consoles and dashboards
• Message queue consumers (Kafka, RabbitMQ, SQS)
• File upload endpoints
• Webhook receivers
• CI/CD pipeline triggers
• DNS and network edge (load balancers, CDN origins)

Step 2: Define Threat Actor Profiles

Identify which threat actors are relevant to the system under review. Use the summary table below to scope the threat model; adjust likelihood ratings based on the actors most likely to target this system.

Actor Type	Capabilities	Motivation	Persistence	Primary STRIDE Targets	Example ATT&CK TTPs
Nation-State APT	Zero-days, supply chain, unlimited budget	Espionage, pre-positioning	Very High	S, I, E	T1195, T1556, T1071
Organized Cybercrime	RaaS, credential markets, exploit brokers	Financial gain	Medium	I, D, T	T1486, T1078, T1566
Malicious Insider	Legitimate creds, internal knowledge	Revenge, financial, coercion	Persistent (employed)	I, T, R	T1530, T1567, T1070
Hacktivist	DDoS tools, public exploits	Ideological, embarrassment	Low	D, T, I	T1498, T1491, T1190
Script Kiddie	Public exploits, scanners, defaults	Curiosity, bragging rights	Very Low	S, E, D	T1078, T1190, T1059
Supply Chain	Inherited trust, code-level access	Varies (state or financial)	High	T, E, I	T1195.001, T1195.002

For each relevant actor, document: (1) why they would target this system, (2) their most likely attack path, and (3) which components are in their primary blast radius.

Detailed profiles: See threat-actor-profiles.md for expanded capabilities, modeling guidance, and full TTP mappings for each actor type.

Step 3: Map Data Flows and Trust Boundaries

Construct a Data Flow Diagram (DFD) that captures processes, data stores, data flows, external entities, and trust boundaries.

DFD Template:

+------------------------------------------------------------------+
|                        TRUST BOUNDARY: Public Internet            |
|                                                                   |
|  +-----------+         HTTPS/TLS 1.3        +----------------+   |
|  |  Browser  | ----------------------------> |  API Gateway / |   |
|  |  / Mobile |                               |  Load Balancer |   |
|  +-----------+                               +-------+--------+   |
|                                                      |             |
+------------------------------------------------------+-------------+
                                                       |
+------------------------------------------------------+-------------+
|                   TRUST BOUNDARY: DMZ / Edge                       |
|                                                      |             |
|                                              +-------v--------+   |
|                                              |   Web App /     |   |
|                                              |   API Server    |   |
|                                              +---+--------+---+   |
|                                                  |        |        |
+--------------------------------------------------+--------+--------+
                                                   |        |
+--------------------------------------------------+--------+--------+
|              TRUST BOUNDARY: Internal Network / VPC                |
|                                                  |        |        |
|                                          +-------v--+ +---v------+ |
|                                          | Database  | | Cache    | |
|                                          | (RDS/     | | (Redis/  | |
|                                          |  Postgres)| | Memcached| |
|                                          +----------+ +----------+ |
|                                                                    |
|  +------------------+          +------------------+                |
|  | Message Queue    |          | Object Storage   |                |
|  | (Kafka/SQS)      |          | (S3/GCS)         |                |
|  +------------------+          +------------------+                |
|                                                                    |
+--------------------------------------------------------------------+
                              |
+-----------------------------+--------------------------------------+
|         TRUST BOUNDARY: Third-Party Services                       |
|                                                                    |
|  +------------------+    +------------------+                      |
|  | Payment Provider |    | Identity Provider|                      |
|  | (Stripe/Adyen)   |    | (Okta/Auth0)     |                      |
|  +------------------+    +------------------+                      |
+--------------------------------------------------------------------+

Implicit Trust Boundary Discovery Checklist:

Use this checklist to identify trust boundaries that are often missed:

• Inter-service boundaries — Services owned by different teams or deployed from different repositories
• Container/pod boundaries — Between containers in the same pod, between pods, between namespaces
• Network segment boundaries — VPC, subnet, security group, and firewall rule boundaries
• Cloud account/subscription boundaries — Cross-account access, shared services, peered VPCs
• CI/CD pipeline boundaries — Between source control, build system, artifact registry, and deployment target
• Third-party SDK/library boundaries — Between your code and vendor SDKs, open-source packages, or embedded interpreters

For each data flow crossing a trust boundary, document:

1. Source and destination components
2. Protocol and transport security
3. Authentication mechanism on the flow
4. Data classification of the payload

DFD Annotation Requirements:

Every data flow in the DFD must be annotated with the following properties:

Property	Values / Examples
Protocol and version	TLS 1.3, HTTP/2, gRPC, AMQP 0-9-1, WebSocket over TLS
Authentication mechanism	mTLS, JWT (RS256), API key, OAuth 2.0 client credentials, none
Data classification	Public, Internal, Confidential, Restricted
Encryption at rest	AES-256-GCM, envelope encryption (KMS), none
Encryption in transit	TLS 1.3, WireGuard, none
Key management	AWS KMS, HashiCorp Vault, application-managed, N/A
Failure mode	Fail-closed (deny on error) or fail-open (allow on error)

Mark any flow with Authentication: none or Failure mode: fail-open as requiring immediate threat analysis.

Step 4: Apply STRIDE per Element

For every component and data flow identified in the DFD, systematically ask the following questions organized by STRIDE category.

S — Spoofing (Authentication Threats)

Threat: An attacker pretends to be another user, service, or system component.

Question	Example Threat
Can an external user authenticate without valid credentials?	Credential stuffing, brute force
Can one service impersonate another service?	Missing mTLS, forged service tokens
Can an attacker replay a valid authentication token?	Stolen JWT without expiration
Are API keys rotated and scoped appropriately?	Leaked long-lived API key
Is multi-factor authentication enforced for privileged accounts?	Admin account takeover

T — Tampering (Integrity Threats)

Threat: An attacker modifies data, code, or configuration without authorization.

Question	Example Threat
Can request parameters be modified in transit?	Man-in-the-middle on non-TLS connections
Can database records be altered by unauthorized users?	SQL injection, insecure direct object reference
Can CI/CD pipeline artifacts be tampered with?	Compromised build server, dependency confusion
Are configuration files protected from unauthorized modification?	Writable config in production containers
Is input validated and sanitized before processing?	XSS, command injection, deserialization attacks

R — Repudiation (Audit and Accountability Threats)

Threat: A user or system denies performing an action, and the system cannot prove otherwise.

Question	Example Threat
Are all security-relevant actions logged with immutable timestamps?	Missing audit trail for privilege changes
Can log entries be modified or deleted by the actors they record?	Logs stored in writable user-accessible storage
Are logs centralized and protected from tampering?	Local-only logs on compromised host
Do transactions include non-repudiation controls (digital signatures)?	Disputed financial transactions
Is there sufficient log detail to reconstruct the sequence of events?	Logs missing source IP, user ID, or action detail

I — Information Disclosure (Confidentiality Threats)

Threat: Sensitive data is exposed to unauthorized parties.

Question	Example Threat
Is sensitive data encrypted at rest (AES-256, envelope encryption)?	Database breach exposes plaintext PII
Is data encrypted in transit (TLS 1.2+)?	Network sniffing captures credentials
Do error messages or stack traces leak internal details?	Verbose error pages reveal DB schema
Are secrets stored in environment variables or dedicated vaults?	Hardcoded credentials in source code
Is access to data stores restricted by least-privilege IAM policies?	Over-permissive S3 bucket policy

D — Denial of Service (Availability Threats)

Threat: An attacker makes the system unavailable to legitimate users.

Question	Example Threat
Are API endpoints rate-limited?	Volumetric API abuse exhausts compute
Is there protection against application-layer DoS (Slowloris, ReDoS)?	Regex-based input causes CPU exhaustion
Are resource quotas enforced (memory, CPU, storage, connections)?	Memory leak triggered by crafted input
Is the system resilient to dependency failures (circuit breakers)?	Cascading failure from downstream outage
Are there auto-scaling policies and DDoS mitigation services?	Sustained DDoS overwhelms fixed capacity

E — Elevation of Privilege (Authorization Threats)

Threat: An attacker gains access to resources or actions beyond their authorized scope.

Question	Example Threat
Are authorization checks enforced at every layer (API, service, data)?	Broken access control, IDOR
Can a regular user access admin functionality?	Missing role checks on admin endpoints
Are privilege boundaries enforced in containerized environments?	Container escape, privileged container
Can an attacker exploit deserialization or injection for code execution?	Remote code execution via insecure deserialization
Are default credentials and unnecessary services removed?	Default admin/admin on management interfaces

Step 5: Build Component-Threat Matrix

Synthesize the STRIDE-per-element analysis into a heatmap-style matrix. For each component, rate the threat level (H=High, M=Medium, L=Low, N=None) per STRIDE category based on Step 4 findings, then derive an overall risk.

Component	S	T	R	I	D	E	Overall Risk
Auth Service	H	M	M	L	L	H	Critical
API Gateway	H	M	L	M	H	M	High
Database	L	H	L	H	M	M	High
Object Storage	L	M	L	H	L	M	Medium
Message Queue	L	M	L	M	M	L	Medium

How to fill in:

1. For each component from the DFD, review every threat identified in Step 4.
2. Assign H/M/L/N per STRIDE column based on the highest-severity threat in that category for that component.
3. Derive Overall Risk: Critical if any H+H combination; High if 2+ H ratings; Medium if 1 H or 2+ M; Low otherwise.
4. Use this matrix to prioritize which components need the deepest mitigation analysis.

Step 6: Map Threat Actors to Components

Combine threat actor profiles (Step 2) with the component-threat matrix (Step 5) to produce a three-dimensional mapping showing which actors target which components via which threats.

Mapping Template:

Actor	Capability Used	Target Component	STRIDE Threat	Likelihood Modifier	Resulting Risk
Nation-State APT	Supply chain implant	CI/CD Pipeline	Tampering	+1 (high sophistication)	Critical
Organized Cybercrime	Credential stuffing	Auth Service	Spoofing	+0 (standard capability)	High
Malicious Insider	Legitimate DB access	Database	Info Disclosure	+1 (internal access)	Critical
Hacktivist	DDoS toolkit	API Gateway	Denial of Service	+0	High
Supply Chain	Compromised package	Application Runtime	Elev. of Privilege	+1 (trusted context)	Critical

Instructions:

1. For each relevant actor from Step 2, identify their most likely target components.
2. Map the actor's capabilities to specific STRIDE threats on those components.
3. Apply a likelihood modifier: +1 if the actor has special access or sophistication that increases likelihood beyond the base rating, +0 otherwise.
4. Recalculate risk using the modified likelihood in the Step 8 risk matrix.
5. Flag any component targeted by 3+ actor types as a high-value target requiring defense-in-depth.

Step 7: Map Threats to MITRE ATT&CK Techniques

Map each identified threat to the corresponding MITRE ATT&CK Enterprise technique to enable standardized tracking and correlation with threat intelligence.

STRIDE Category	Common ATT&CK Techniques
Spoofing	T1078 — Valid Accounts, T1134 — Access Token Manipulation, T1556 — Modify Authentication Process, T1528 — Steal Application Access Token, T1539 — Steal Web Session Cookie
Tampering	T1565 — Data Manipulation, T1195 — Supply Chain Compromise, T1059 — Command and Scripting Interpreter, T1190 — Exploit Public-Facing Application, T1210 — Exploitation of Remote Services
Repudiation	T1070 — Indicator Removal, T1070.001 — Clear Windows Event Logs, T1070.002 — Clear Linux or Mac System Logs, T1562 — Impair Defenses, T1562.001 — Disable or Modify Tools
Information Disclosure	T1530 — Data from Cloud Storage, T1552 — Unsecured Credentials, T1552.001 — Credentials In Files, T1040 — Network Sniffing, T1557 — Adversary-in-the-Middle, T1119 — Automated Collection
Denial of Service	T1498 — Network Denial of Service, T1499 — Endpoint Denial of Service, T1499.003 — Application Exhaustion Flood, T1499.004 — Application or System Exploitation, T1489 — Service Stop
Elevation of Privilege	T1068 — Exploitation for Privilege Escalation, T1548 — Abuse Elevation Control Mechanism, T1611 — Escape to Host, T1053 — Scheduled Task/Job, T1055 — Process Injection

Step 8: Risk Rating

Use a Likelihood x Impact matrix to assign a risk rating to each threat. This approach is aligned with OWASP Risk Rating Methodology.

Likelihood Scale:

Rating	Value	Description
Low	1	Requires significant skill, insider access, or rare conditions
Medium	2	Exploitable with moderate skill and publicly known techniques
High	3	Easily exploitable, automated tools available, broad attack surface

Impact Scale:

Rating	Value	Description
Low	1	Minor inconvenience, no data loss, limited business impact
Medium	2	Partial data breach, service degradation, moderate financial loss
High	3	Full data breach, complete service outage, regulatory penalties, reputational damage

Risk Matrix:

                    I M P A C T
                  Low(1)  Med(2)  High(3)
              +--------+--------+--------+
  L   High(3)|  Med   |  High  |Critical|
  I          +--------+--------+--------+
  K   Med(2) |  Low   |  Med   |  High  |
  E          +--------+--------+--------+
  L   Low(1) |  Info  |  Low   |  Med   |
  I          +--------+--------+--------+
  H
  O
  O
  D

Risk Levels and Response:

Risk Level	Score Range	Required Response
Critical	9	Immediate remediation; blocks release
High	6	Must remediate before production deployment
Medium	2-4	Remediate within current sprint or next release cycle
Low	1-2	Accept with documented rationale or address in backlog
Info	1	Document for awareness; no action required

Step 9: Prioritize Mitigations

Rank mitigations using the following prioritization criteria:

1. Risk reduction — Prioritize mitigations that address Critical and High risks first.
2. Blast radius — Prefer controls that protect multiple assets or reduce impact across several threat vectors.
3. Implementation cost — Factor in engineering effort, operational overhead, and third-party costs.
4. Defense in depth — Ensure mitigations span multiple layers (network, application, data, identity).
5. Compliance alignment — Prefer mitigations that simultaneously satisfy regulatory requirements.

Mitigation Categories:

Category	Examples
Preventive	Input validation, parameterized queries, TLS enforcement, MFA, least-privilege IAM
Detective	Centralized logging, SIEM alerting, anomaly detection, integrity monitoring
Corrective	Incident response playbooks, automated rollback, secret rotation, patch management
Compensating	WAF rules, rate limiting, network segmentation, runtime application self-protection

4. Findings Classification

Severity	Label	Definition	SLA
P0	Critical	Active exploitation likely; full system compromise, mass data breach, or safety impact. Requires immediate action.	Remediate within 24 hours
P1	High	Significant risk of exploitation; major data exposure or service disruption. Blocks production release.	Remediate within 7 days
P2	Medium	Moderate risk; limited data exposure or partial service impact. Exploitable under specific conditions.	Remediate within 30 days
P3	Low	Minor risk; defense-in-depth gap or informational finding. Requires non-trivial attack chain.	Remediate within 90 days
P4	Informational	Best-practice recommendation or hardening suggestion. No direct exploitability demonstrated.	Backlog / next planning cycle

5. Output Format — Threat Register

Produce the threat register as a structured table. Each row represents one identified threat.