Threat modeling
π Professional Multi-Agent Skills
npx -y skills add kinhluan/skills --skill threat-modelingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Security threat modeling and risk assessment using STRIDE, Attack Trees, and DREAD scoring. Use when designing secure architecture, conducting security design reviews, assessing risks, or creating threat models for applications, systems, or cloud infrastructure.
SKILL.md
8.2 KB, as published. Nobody here has run it
Threat Modeling
Systematic approach to identifying, quantifying, and addressing security threats in software architecture and system design.
"Threat modeling is the key to a secure design." β Adam Shostack
π― When to Use
- Designing new systems or architecture
- Conducting security design reviews
- Assessing risks before implementation
- Reviewing third-party integrations
- Cloud migration security planning
- Compliance and audit preparation
π§ Core Methodologies
STRIDE
| Threat Category | Description | Example |
|---|---|---|
| Spoofing | Pretending to be someone else | Fake JWT token, stolen credentials |
| Tampering | Modifying data or code | Man-in-the-middle, code injection |
| Repudiation | Denying an action | Missing audit logs, no transaction records |
| Information Disclosure | Exposing sensitive data | SQL injection, verbose error messages |
| Denial of Service | Making system unavailable | DDoS, resource exhaustion |
| Elevation of Privilege | Gaining unauthorized access | Privilege escalation, IDOR |
DREAD Scoring
| Factor | Question | Score (1-10) |
|---|---|---|
| Damage | How bad is the damage? | 1=Minimal, 10=Total compromise |
| Reproducibility | How easy to reproduce? | 1=Very hard, 10=Always works |
| Exploitability | How easy to exploit? | 1=Expert only, 10=Script kiddie |
| Affected Users | How many users affected? | 1=None, 10=All users |
| Discoverability | How easy to discover? | 1=Very hard, 10=Obvious |
Risk Score = (D + R + E + A + D) / 5
| Risk Level | Score Range |
|---|---|
| Critical | 9.0-10.0 |
| High | 7.0-8.9 |
| Medium | 4.0-6.9 |
| Low | 0.1-3.9 |
ποΈ Threat Modeling Process
Step 1: Define Scope & Assets
Identify:
ββ What are we building? (system, feature, API)
ββ What data flows through it?
ββ Who are the users/actors?
ββ What are the trust boundaries?
ββ What are the high-value assets?
Step 2: Create Data Flow Diagram (DFD)
Elements:
ββ External Entity (rectangle) β User, third-party service
ββ Process (circle) β Application, microservice
ββ Data Store (two horizontal lines) β Database, cache
ββ Data Flow (arrow) β HTTP request, message queue
ββ Trust Boundary (dashed line) β Network perimeter, tenant boundary
Example: E-commerce Checkout
[User] --HTTPS--> [Web App] --SQL--> [Database]
| |
| | --API--> [Payment Gateway]
| |
Trust Boundary 1 Trust Boundary 2
Step 3: Identify Threats (STRIDE-per-Element)
For each element in DFD, apply STRIDE:
External Entity:
ββ Spoofing: Can someone impersonate this user?
ββ Repudiation: Can the user deny their actions?
Process:
ββ Spoofing: Can someone fake the process identity?
ββ Tampering: Can the process code be modified?
ββ Repudiation: Are actions logged?
ββ Information Disclosure: Does the process leak data?
ββ Denial of Service: Can the process be overwhelmed?
ββ Elevation of Privilege: Can the process gain more rights?
Data Store:
ββ Tampering: Can stored data be modified?
ββ Information Disclosure: Can unauthorized access occur?
ββ Denial of Service: Can the store be made unavailable?
Data Flow:
ββ Tampering: Can data in transit be modified?
ββ Information Disclosure: Can data be intercepted?
ββ Denial of Service: Can the flow be blocked?
Step 4: Score & Prioritize (DREAD)
Example: SQL Injection in Checkout API
Damage: 9 (Full database access, customer data exposed)
Reproducibility: 8 (Always reproducible with crafted input)
Exploitability: 7 (Basic SQL knowledge needed)
Affected Users: 9 (All customers)
Discoverability: 6 (Requires some probing)
Risk Score = (9 + 8 + 7 + 9 + 6) / 5 = 7.8 β HIGH
Step 5: Mitigate & Validate
Mitigation Strategies:
ββ Eliminate: Remove the threat entirely
ββ Reduce: Lower likelihood or impact
ββ Transfer: Move risk to another party (insurance)
ββ Accept: Document and monitor
For each threat, define:
ββ Mitigation technique
ββ Implementation owner
ββ Validation method
ββ Timeline
π³ Attack Trees
Structure
Goal: Steal customer credit card data
β
ββ AND: Gain database access
β ββ Exploit SQL injection
β β ββ Find vulnerable endpoint
β β ββ Craft payload
β ββ Compromise application server
β β ββ Exploit RCE
β β ββ Use stolen credentials
β ββ Social engineer DBA
β
ββ OR: Intercept payment data
β ββ Man-in-the-middle attack
β β ββ Compromise network infrastructure
β ββ Compromise payment gateway
β β ββ Exploit API vulnerability
β ββ Insider threat
β ββ Bribe employee
β
ββ AND: Exfiltrate data
ββ Establish covert channel
ββ Bypass DLP controls
Attack Tree Analysis
For each node, calculate:
ββ Cost (effort/resources needed)
ββ Time (how long to execute)
ββ Skill (expertise required)
ββ Detection (likelihood of being caught)
Leaf nodes with lowest cost + time + skill = highest risk paths
βοΈ Cloud-Specific Threat Modeling
AWS Threat Model Template
Assets:
ββ S3 buckets (customer data, backups)
ββ RDS databases (transaction records)
ββ Lambda functions (business logic)
ββ IAM roles (privilege escalation vectors)
ββ VPC (network segmentation)
Trust Boundaries:
ββ Internet β CloudFront/WAF
ββ CloudFront β ALB
ββ ALB β ECS/EKS (container workloads)
ββ ECS β RDS (database tier)
ββ Cross-account boundaries
Key Threats:
ββ S3 bucket misconfiguration (public access)
ββ IAM over-permission (wildcard policies)
ββ Lambda injection (event source poisoning)
ββ VPC peering exposure
ββ Secrets in CloudWatch logs
Kubernetes Threat Model
Assets:
ββ etcd (cluster state, secrets)
ββ API Server (control plane)
ββ kubelet (node agent)
ββ Container images
ββ Network policies
Threats:
ββ etcd unauthorized access β cluster compromise
ββ API Server exposed β entire cluster at risk
ββ Privileged containers β host escape
ββ Weak network policies β lateral movement
ββ Malicious images β supply chain attack
π Threat Modeling Checklist
Pre-Modeling
- System architecture documented
- Data classification completed
- User roles and permissions defined
- Third-party integrations identified
- Compliance requirements known
During Modeling
- DFD created with trust boundaries
- STRIDE applied to all elements
- Attack trees for critical assets
- DREAD scoring for all threats
- Mitigations identified per threat
Post-Modeling
- Threats prioritized by risk score
- Mitigation roadmap created
- Validation tests defined
- Review scheduled (quarterly)
- Documentation updated
π οΈ Tools
| Tool | Purpose |
|---|---|
| Microsoft Threat Modeling Tool | DFD creation, STRIDE analysis |
| OWASP Threat Dragon | Open-source threat modeling |
| pytm | Python threat modeling framework |
| ThreatSpec | Threat modeling as code |
| IriusRisk | Enterprise threat modeling platform |