STRIDE Threat Modeling

Threat model a system in a structured workshop format.

1. Model the System

Draw the diagram: processes, data stores, data flows, external actors, and trust boundaries (dashed lines where privilege/context changes).

• Every element numbered; technologies noted on processes/stores
• Include the boring parts: auth flows, async jobs, admin tooling, backups

2. Enumerate with STRIDE

For each element, apply the applicable categories:

| Category | Applies To | Question | |---|---|---| | Spoofing | Processes, actors | Can someone pretend to be this? (auth) | | Tampering | Flows, stores | Can data be modified in transit/at rest? (integrity) | | Repudiation | Processes | Can actions be denied? (logging/audit) | | Information disclosure | Flows, stores | Can data leak to unauthorized parties? (confidentiality) | | Denial of service | Processes, flows | Can this be exhausted or crashed? (availability) | | Elevation of privilege | Processes | Can rights be gained? (authz) |

Work systematically: element × category grid so nothing is skipped.

3. Rank

Score each threat by impact (worst realistic outcome) × likelihood (attack complexity, exposure). Prioritize: unauthenticated remote > authenticated remote > local > physical.

4. Mitigate

For each accepted threat, pick a strategy: reduce (control), transfer, accept (documented, with owner), or avoid (design change). Map mitigations to concrete backlog tickets with acceptance criteria.

5. Validate

• Review the model when the architecture changes (trigger: new external dependency, new trust boundary, new data class)
• Retro: incidents found in prod vs threats previously modeled — feed misses back into the method

Output

System diagram with trust boundaries, element × STRIDE threat grid, ranked risk register, and mitigations as tracked tickets.