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.