Threat Modeling

Analyze systems for security threats using the STRIDE methodology. Produce data flow diagrams, identify trust boundaries, map attack surfaces, and assess risk.

When to Use

Designing a new system or feature that handles sensitive data.
Reviewing architecture for security before implementation.
Conducting a security review or threat assessment.
Identifying trust boundaries and attack surfaces.
Prioritizing security work by risk (likelihood x impact).

Instructions

STRIDE Methodology

Analyze each component and data flow for six threat categories:

Category	Threat	Property Violated
Spoofing	Pretending to be someone else	Authentication
Tampering	Modifying data or code	Integrity
Repudiation	Denying an action occurred	Non-repudiation
Information Disclosure	Exposing data to unauthorized	Confidentiality
Denial of Service	Making the system unavailable	Availability
Elevation of Privilege	Gaining unauthorized access	Authorization

Step 1: Data Flow Diagram

Map the system showing processes, data stores, data flows, and external entities:

                    Trust Boundary
                    +---------------------------------+
  [User Browser] ---|---> [Web Server] ---> [App Server] ---> [Database]
                    |         |                  |
                    |         v                  v
                    |    [Static Files]    [Cache (Redis)]
                    +---------------------------------+
                           |
                           v
                    [External Auth Provider]

Label each element:

Processes (circles/boxes): Web server, app server, background workers.
Data stores (parallel lines): Database, cache, file system, message queue.
Data flows (arrows): HTTP requests, database queries, API calls.
External entities (rectangles): Users, third-party services, admin.
Trust boundaries (dashed lines): Network segments, process boundaries.

Step 2: Identify Trust Boundaries

Trust boundaries exist where data crosses between different trust levels:

Internet to DMZ (user requests entering the network).
DMZ to internal network (web server to application server).
Application to database (app server to data store).
Service to service (between microservices).
User privilege levels (regular user vs admin).

Every trust boundary crossing is a potential attack point.

Step 3: Apply STRIDE to Each Element

For each process, data store, and data flow, ask:

Spoofing: Can an attacker impersonate a legitimate entity?
Tampering: Can data be modified in transit or at rest?
Repudiation: Can a user deny performing an action?
Info Disclosure: Can sensitive data leak?
DoS: Can this component be overwhelmed or crashed?
Elevation: Can a user gain higher privileges?

Step 4: Risk Assessment

Rate each threat using likelihood and impact:

Rating	Likelihood	Impact
High	Exploitable with public tools	Data breach, full compromise
Medium	Requires some skill or access	Partial data exposure, downtime
Low	Requires insider access or luck	Minor data exposure, degradation

Risk = Likelihood x Impact

Likelihood \ Impact	High	Medium	Low
High	Critical	High	Medium
Medium	High	Medium	Low
Low	Medium	Low	Low

Step 5: Mitigation Strategies

For each identified threat, document a mitigation:

STRIDE Category	Common Mitigations
Spoofing	MFA, certificate pinning, mutual TLS
Tampering	Digital signatures, checksums, immutable audit logs
Repudiation	Audit logging, tamper-evident logs, digital signatures
Information Disclosure	Encryption (TLS, AES), access controls, data masking
Denial of Service	Rate limiting, auto-scaling, CDN, circuit breakers
Elevation of Privilege	Least privilege, input validation, sandboxing

Attack Surface Mapping

Enumerate all entry points an attacker could use:

Network: Open ports, exposed services, public endpoints.
Application: API endpoints, file upload, search, user input fields.
Authentication: Login, password reset, session management.
Data: Database access, file storage, backups, logs.
Infrastructure: Cloud console, CI/CD pipeline, container registry.
Human: Phishing targets, social engineering, insider threats.

Output Format

Structure threat model output as:

## Threat Model: [System Name]

### System Description
Brief description of the system and its purpose.

### Data Flow Diagram
ASCII diagram showing components and trust boundaries.

### Assets
List of valuable data and resources to protect.

### Threats
| ID | STRIDE | Component | Threat | Risk | Mitigation |
|----|--------|-----------|--------|------|------------|
| T1 | S      | Login API | Credential stuffing | High | Rate limiting, MFA |
| T2 | I      | Database  | SQL injection leaks PII | Critical | Parameterized queries |

### Recommendations
Prioritized list of security improvements.

Examples

Example 1: Threat model a web application

User: Create a threat model for our e-commerce application.

Agent: Reads the architecture and codebase, then produces:
  1. Data flow diagram showing: browser -> CDN -> load balancer -> API servers
     -> database / cache / payment gateway. Trust boundaries at each hop.
  2. STRIDE analysis of each component:
     - Spoofing: session hijacking on API server (Medium risk).
     - Tampering: price manipulation in cart requests (High risk).
     - Info Disclosure: PII exposure in error messages (Medium risk).
     - DoS: no rate limiting on search endpoint (High risk).
  3. Risk-prioritized mitigation recommendations.

Example 2: Assess a microservices architecture

User: Review our microservices architecture for security threats.

Agent: Maps service communication patterns:
  - Identifies 12 services with 28 inter-service data flows.
  - Trust boundaries: public internet, API gateway, service mesh, database tier.
  - Key findings:
    - 3 services communicate over unencrypted HTTP internally (Tampering, Info Disclosure).
    - No mutual TLS between services (Spoofing).
    - Shared database credentials across services (Elevation of Privilege).
    - No circuit breakers — cascade failure risk (DoS).
  Recommends: service mesh with mTLS, per-service DB credentials, circuit breakers.

Example 3: Pre-launch security review

User: We're launching next week. Do a threat model focused on the highest risks.

Agent: Focuses on critical-path components:
  - Payment flow: identifies missing webhook signature verification (Tampering, Critical).
  - User registration: no rate limiting (DoS, High), email enumeration (Info Disclosure).
  - Admin panel: accessible without VPN (Elevation of Privilege, Critical).
  - File uploads: no type validation (Injection via uploaded HTML, High).
  Produces a prioritized punch list:
    1. [Critical] Add webhook signature verification before processing payments.
    2. [Critical] Restrict admin panel to VPN or IP allowlist.
    3. [High] Add rate limiting to registration and login.
    4. [High] Validate file upload types and serve from separate domain.

threat-modeling

NPX Install

Tags

SKILL.md Content