Threat Model STRIDE

A threat found at design review costs a paragraph in a doc; the same threat found in production costs an incident, a credential rotation, and sometimes a disclosure. STRIDE catches whole classes of flaws - spoofed callers, tamperable payloads, privilege leaks - before there is code to review. Apply it to any feature touching auth, data storage, external calls, or privilege changes; skip it and the same flaws surface later in secure-code-review or, worse, in vulnerability-triage.

Operating procedure

Follow the steps in order. Threats enumerated before trust boundaries are explicit come out vague and unactionable, and mitigations written before scoring waste effort on Low findings.

Step 1: Gather inputs

Collect these before modeling. Where the user cannot answer, use the default and label the assumption a guess.

• Feature description in 3-5 sentences: what it does, who calls it, what it stores.
• Actors: users, internal services, external APIs, admin roles. Default: anonymous internet user, authenticated user, one backend service.
• Data assets and a sensitivity tier for each: credentials > financial > PII > internal > public.
• Deployment context: internet-facing or internal-only; behind a WAF or VPN or not.
• Existing controls: auth mechanism (session, JWT, mTLS), rate limiting, audit logging.
• Compliance regime in scope (SOC 2, PCI, HIPAA, GDPR), if any.