threat-modeling

Name: threat-modeling
Author: briiirussell

116installs36forks

How to install threat-modeling?

briiirussell/cybersecurity-skills/threat-modeling

$npx -y skills add briiirussell/cybersecurity-skills --skill threat-modeling

Installs into the current project.

Summary

Run a structured threat-modeling session for a new feature, system, or architecture — STRIDE, attack trees, data flow diagrams, abuse cases. Use when the user mentions 'threat model,' 'threat modeling,' 'STRIDE,' 'attack tree,' 'abuse case,' 'data flow diagram,' 'DFD,' 'security

Files · 1

View on GitHub

SKILL.md

1	# Threat Modeling — Pre-Implementation Security Design
2
3	Run a structured threat-modeling session against a proposed feature, system, or architecture. This is the design-time security skill — different from audit (which inspects code that exists). Use this when there's a design doc, a feature spec, an architecture diagram — but not yet code.
4
5	When to use:
6	- New feature touching auth, payments, multi-tenant data, or sensitive PII
7	- New external integration (third-party API, OAuth provider, webhook receiver)
8	- New service / microservice being added to the architecture
9	- Significant refactor of a security-sensitive component
10	- Before committing to a major architecture decision (event-driven vs request/response, monolith split, AI-feature introduction)
11
12	Cross-references: `owasp-audit` (code-level checklist that lines up with the threats this surfaces), `api-audit` (API-specific category mapping), `iam-audit` (identity decisions touch every threat model).
13
14	## The four questions
15
16	Adam Shostack's framing — every threat model answers these four:
17
18	1. What are we working on? (Scope and model)
19	2. What can go wrong? (Threats)
20	3. What are we going to do about it? (Mitigations)
21	4. Did we do a good job? (Validation)
22
23	The rest of this skill walks through each in order.
24
25	## Step 1 — What are we working on?
26
27	Produce a Data Flow Diagram (DFD) at one of three levels:
28
29	- Level 0 — Context diagram. One bubble for the system, lines to every external entity (users, third-party APIs, internal admin tools). Use this when the question is "what does this system even touch?"
30	- Level 1 — Major processes. Auth service, API gateway, primary data store, payment integration, etc. Use this for most feature-level threat models.
31	- Level 2 — Detailed component model. Specific endpoints, specific tables, specific queues. Use this for the trickiest parts only.
32
33	A useful DFD has:
34	- External entities (rectangles) — users, third-party services, admins
35	- Processes (circles) — your services, functions, handlers
36	- Data stores (parallel lines / cylinders) — databases, caches, blob storage, queues
37	- Data flows (arrows, labeled with what crosses) — request bodies, tokens, files, events
38	- Trust boundaries (dashed lines) — every crossing is a place data is validated, authenticated, or filtered
39
40	Trust boundaries are the most useful element. If you can draw exactly one diagram that shows every trust boundary in your feature, you've already done 60% of the work.
41
42	For text-only environments, render the DFD in Mermaid:
43
44	```mermaid
45	flowchart LR
46	User[User] -- HTTPS --> WAF[WAF / CDN]
47	WAF -- request --> API[API Gateway]
48	API -- JWT --> Service[Service]
49	Service -- SQL --> DB[(Postgres)]
50	Service -- HTTPS --> Stripe[Stripe]
51
52	classDef trust fill:#fff,stroke:#f00,stroke-dasharray:4 4
53	class API,Service trust
54	```
55
56	## Step 2 — What can go wrong? (STRIDE)
57
58	For each process, data store, and data flow, ask STRIDE — one threat category per letter. Not every category applies to every element, and that's fine.
59
60	\| Letter \| Threat \| Property violated \| Examples \|
61	\|---\|---\|---\|---\|
62	\| S \| Spoofing \| Authentication \| Stolen token, forged JWT, replay attack, impersonating a service \|
63	\| T \| Tampering \| Integrity \| Modifying a request mid-flight, parameter tampering, modifying stored data \|
64	\| R \| Repudiation \| Non-repudiation \| User denies an action; logs don't prove they did it \|
65	\| I \| Information Disclosure \| Confidentiality \| Leak via error messages, IDOR exposing other users' data, exposed S3 bucket \|
66	\| D \| Denial of Service \| Availability \| Resource exhaustion, expensive query bomb, billing exhaustion via paid downstream APIs \|
67	\| E \| Elevation of Privilege \| Authorization \| User → admin via mass assignment, BFLA, escape from sandbox \|
68
69	### STRIDE per element
70
71	A useful threat-modeling habit: for each element of the DFD, write a short table.
72
73	```markdown
74	Element: API Gateway
75
76	\| STRIDE \| Threat \| Likelihood \| Impact \|
77	\|---\|---\|---\|---\|
78	\| S \| Forged JWT — symmetric secret in env, leaks if .env exposed \| M \| H \|
79	\| T \| Request body modified between gateway and upstream service \| L \| M \|
80	\| R \| Gateway access logs deleted by attacker post-breach \| L \| H \|
81	\| I \| Verbose error responses expose internal hostnames \| M \| L \|
82	\| D \| No rate limit at the gateway → upstream services overwhelmed \| H \| H \|
83	\| E \| "X-Admin: true" header p

People who liked this also viewed

6 picks

Type

threat-modeling

116installs36forks

View on GitHub

How to install threat-modeling?

briiirussell/cybersecurity-skills/threat-modeling

$npx -y skills add briiirussell/cybersecurity-skills --skill threat-modeling

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Threat Modeling — Pre-Implementation Security Design
2
3	Run a structured threat-modeling session against a proposed feature, system, or architecture. This is the design-time security skill — different from audit (which inspects code that exists). Use this when there's a design doc, a feature spec, an architecture diagram — but not yet code.
4
5	When to use:
6	- New feature touching auth, payments, multi-tenant data, or sensitive PII
7	- New external integration (third-party API, OAuth provider, webhook receiver)
8	- New service / microservice being added to the architecture
9	- Significant refactor of a security-sensitive component
10	- Before committing to a major architecture decision (event-driven vs request/response, monolith split, AI-feature introduction)
11
12	Cross-references: `owasp-audit` (code-level checklist that lines up with the threats this surfaces), `api-audit` (API-specific category mapping), `iam-audit` (identity decisions touch every threat model).
13
14	## The four questions
15
16	Adam Shostack's framing — every threat model answers these four:
17
18	1. What are we working on? (Scope and model)
19	2. What can go wrong? (Threats)
20	3. What are we going to do about it? (Mitigations)
21	4. Did we do a good job? (Validation)
22
23	The rest of this skill walks through each in order.
24
25	## Step 1 — What are we working on?
26
27	Produce a Data Flow Diagram (DFD) at one of three levels:
28
29	- Level 0 — Context diagram. One bubble for the system, lines to every external entity (users, third-party APIs, internal admin tools). Use this when the question is "what does this system even touch?"
30	- Level 1 — Major processes. Auth service, API gateway, primary data store, payment integration, etc. Use this for most feature-level threat models.
31	- Level 2 — Detailed component model. Specific endpoints, specific tables, specific queues. Use this for the trickiest parts only.
32
33	A useful DFD has:
34	- External entities (rectangles) — users, third-party services, admins
35	- Processes (circles) — your services, functions, handlers
36	- Data stores (parallel lines / cylinders) — databases, caches, blob storage, queues
37	- Data flows (arrows, labeled with what crosses) — request bodies, tokens, files, events
38	- Trust boundaries (dashed lines) — every crossing is a place data is validated, authenticated, or filtered
39
40	Trust boundaries are the most useful element. If you can draw exactly one diagram that shows every trust boundary in your feature, you've already done 60% of the work.
41
42	For text-only environments, render the DFD in Mermaid:
43
44	```mermaid
45	flowchart LR
46	User[User] -- HTTPS --> WAF[WAF / CDN]
47	WAF -- request --> API[API Gateway]
48	API -- JWT --> Service[Service]
49	Service -- SQL --> DB[(Postgres)]
50	Service -- HTTPS --> Stripe[Stripe]
51
52	classDef trust fill:#fff,stroke:#f00,stroke-dasharray:4 4
53	class API,Service trust
54	```
55
56	## Step 2 — What can go wrong? (STRIDE)
57
58	For each process, data store, and data flow, ask STRIDE — one threat category per letter. Not every category applies to every element, and that's fine.
59
60	\| Letter \| Threat \| Property violated \| Examples \|
61	\|---\|---\|---\|---\|
62	\| S \| Spoofing \| Authentication \| Stolen token, forged JWT, replay attack, impersonating a service \|
63	\| T \| Tampering \| Integrity \| Modifying a request mid-flight, parameter tampering, modifying stored data \|
64	\| R \| Repudiation \| Non-repudiation \| User denies an action; logs don't prove they did it \|
65	\| I \| Information Disclosure \| Confidentiality \| Leak via error messages, IDOR exposing other users' data, exposed S3 bucket \|
66	\| D \| Denial of Service \| Availability \| Resource exhaustion, expensive query bomb, billing exhaustion via paid downstream APIs \|
67	\| E \| Elevation of Privilege \| Authorization \| User → admin via mass assignment, BFLA, escape from sandbox \|
68
69	### STRIDE per element
70
71	A useful threat-modeling habit: for each element of the DFD, write a short table.
72
73	```markdown
74	Element: API Gateway
75
76	\| STRIDE \| Threat \| Likelihood \| Impact \|
77	\|---\|---\|---\|---\|
78	\| S \| Forged JWT — symmetric secret in env, leaks if .env exposed \| M \| H \|
79	\| T \| Request body modified between gateway and upstream service \| L \| M \|
80	\| R \| Gateway access logs deleted by attacker post-breach \| L \| H \|
81	\| I \| Verbose error responses expose internal hostnames \| M \| L \|
82	\| D \| No rate limit at the gateway → upstream services overwhelmed \| H \| H \|
83	\| E \| "X-Admin: true" header p

People who liked this also viewed

6 picks

Type