Ravindra BagaleCourses & study guides Track your progress

Guides

STRIDE Threat Modeling Guide for Builders and Defenders

By , Cyber Security trainer LinkedIn Published: Last updated:

STRIDE is a practical threat-modeling checklist from Microsoft: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Use it on a simple diagram of your system to find mitigations early — educational design work, not an attack playbook or exploit list.

Friends! Drawing boxes on a whiteboard before coding builds confidence in security interviews. STRIDE = six questions per box / arrow. Today: threat modeling habit — no PoC exploits. Your app / lab design only.

Quick answer

Threat-model with STRIDE:

  1. Draw a simple data-flow diagram: users, apps, data stores, trust boundaries (internet vs LAN vs admin).
  2. For each process / data store / flow, ask the six STRIDE questions.
  3. Write mitigations next to each realistic threat (authN, integrity checks, logs, rate limits, least privilege).
  4. Track residual risk and owners — “accepted” needs a name and review date.
  5. Revisit when architecture changes (new API, new vendor, new admin tool).
  6. Keep models short enough that builders read them — a 2-page living doc beats a 80-page shelf ornament.
  7. Never use threat modeling as cover to attack third-party systems; model what you build or are authorised to review.

Tiny mental model:

Diagram → STRIDE questions → mitigations → owners
No diagram = security debates stay vague

What do I need before this guide?

What is STRIDE?

STRIDE threat modeling Draw the system, apply STRIDE categories, then pick mitigations — a defender design habit, not an attack recipe. STRIDE checklist on your diagram SSpoofing TTampering RRepudiation IInfo leak DDoS EElevation 1. Draw DFDs Trust boundaries 2. Mitigate AuthN, logs, limits

Draw the system, walk STRIDE categories, then record mitigations — a design habit for defenders, not an attack recipe.

The six categories (defender definitions)

  1. Spoofing — pretending to be another user, service or host (fix with strong authentication, MFA, mutual TLS where needed).
  2. Tampering — changing data or code in transit or at rest (integrity: signatures, checksums, authenticated APIs, locked configs).
  3. Repudiation — denying an action with no proof (non-repudiation: good audit logs, signed transactions, time sync).
  4. Information disclosure — reading data you should not (encryption, access control, minimise PII, careful errors).
  5. Denial of service — making the system unavailable (rate limits, quotas, capacity, graceful degradation — high-level).
  6. Elevation of privilege — acting with more power than intended (least privilege, secure admin paths, input validation).

Educational warning: STRIDE finds design weaknesses. It is not a licence to probe production without authorisation, and this page does not provide exploit payloads for any category.

Real incident: Capital One (2019) — design / metadata lesson

Public reporting on the Capital One 2019 breach described abuse of a misconfigured web application firewall and access to cloud metadata-style credentials, leading to significant data exposure. Threat-modeling fans read it as a reminder: trust boundaries around management interfaces and instance metadata must appear on the diagram with explicit Spoofing / Elevation / Disclosure mitigations — not only “we have encryption at rest”.

Takeaways (vertical):

  1. What happened — cloud-hosted application path led to broad data access.
  2. What went wrong (theme) — a trust-boundary control did not match the intended model.
  3. Care-take — draw metadata / IMDS and admin APIs as separate elements with STRIDE notes.
  4. Care-take — least privilege on roles that apps receive.
  5. Care-take — logging and detection for unusual role usage.
  6. Bonus parallel — many SSRF-class lessons are really “we never put that flow on the whiteboard”.

How to sketch a beginner DFD

  1. Boxes: Browser, App server, Database, Identity provider, Email/SMS vendor.
  2. Arrows: login, read order, password reset, admin export.
  3. Dashed line: trust boundary between internet and VPC / private subnet.
  4. Note where secrets live (vault vs env vs none).
  5. Fictional Nashik grape exporter portal: farmers upload invoices — mark the upload bucket and the admin export arrow for Disclosure + Elevation questions.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

  • Spoof support identity; abuse password-reset flows (high-level social + tech mix).
  • Tamper with unsigned client updates or weak API authorisation.
  • Overwhelm public endpoints (DoS) to hide other noise.
  • Climb from a low-privilege bug into admin functions (Elevation).

Blue Team — defend, detect, respond

  • Put mitigations in tickets before coding “nice to have”.
  • Log security-relevant decisions (authZ denials, admin exports).
  • Rate-limit and cache thoughtfully; know your provider’s shields.
  • Re-run STRIDE when adding AI tools, webhooks or new admin panels.
  • Share the one-page model in onboarding so juniors inherit context.

How do I run a STRIDE session step by step?

Step 1 — Scope one feature

  1. Pick a thin slice (e.g. “password reset” or “invoice upload”), not the whole company.
  2. Time-box 60–90 minutes with a developer + someone security-curious.
  3. Write assumptions (“admins use SSO”, “DB not on internet”).

Step 2 — Apply STRIDE with a table

Element S T R I D E Mitigation
Login API … … … … … … MFA, lockout policy, logs
Invoice bucket … … … … … … Private ACL, encryption, signed URLs

Fill cells with short phrases, not essays. Skip empty theoretical noise; mark “N/A” when honest.

Step 3 — Prioritise

  1. Internet-facing + sensitive data first.
  2. Missing authentication / authorisation beats polishing TLS ciphers for a beginner backlog.
  3. Assign owners and target dates; accepted risks need a review month.

Step 4 — Feed engineering

  1. Convert rows into user stories or security acceptance checks.
  2. Link related OWASP items for builders.
  3. Store the diagram next to the repo README.

Step 5 — Lab / classroom only

  1. Threat-model a toy app you wrote.
  2. Optionally validate mitigations with authorised tests on that app.
  3. Do not STRIDE someone else’s bank and then “verify” with scans.

Ravindra Bagale's Tip

💡 Students drop STRIDE as a buzzword on a PowerPoint with no diagram. The interviewer asks: "name one trust boundary." Boxes + arrows + MFA/least-privilege mitigation = concrete. No exploit poetry. Got it?

STRIDE vs “we will pentest later”

  1. Pentests find what slipped through; STRIDE reduces what you ship broken.
  2. Ethical pentest still needs rules of engagement — modeling is earlier and cheaper.
  3. Use both: model → build → authorised test → fix → re-model changed pieces.

When STRIDE is “good enough”

  1. Startups: one afternoon per major feature beats zero modeling.
  2. Enterprises: align STRIDE rows to existing risk registers without duplicating jargon.
  3. Students: a single graded diagram with six honest mitigations proves skill.

Care-take — organisation habits

  1. New microservice template includes an empty STRIDE table.
  2. Architecture review gate: “show the DFD”.
  3. Vendor onboarding: where does our data flow into their trust zone?
  4. Update the model after incidents — living document.
  5. Do not confuse compliance paperwork with thinking; keep language plain.
  6. Pair with IR planning for high-impact rows.

How do I fix common threat-modeling mistakes?

Ghabru naka 😅 — these are the usual ones:

Symptom Likely cause Fix
80-page model nobody reads Boiling the ocean One feature per session
Only crypto discussed Comfort zone Force Spoofing + Elevation rows
“Hackers gonna hack” fatalism No owners Mitigation + name + date
Model outdated in 3 months No trigger Revisit on architecture RFCs
Used as attack brainstorm only Wrong culture End every item with a control
Scanned prod to “confirm” Scope creep Authorised test environments only

Try it at home

Educational design practice:

  1. Draw a 6-box diagram of an app you use daily (e.g. notes app) as a learning sketch — no testing their servers.
  2. Fill STRIDE for the login arrow and the sync cloud store.
  3. Write three mitigations you would want if you built it.
  4. Time yourself: 45 minutes maximum.
  5. Bring the paper to study group; compare vocabulary, not attack ideas.

Learn it properly

Course lessons:

Related guides: OWASP Top 10 · Zero Trust · Cloud IAM · Ethical pentest (RoE)

Got it? STRIDE = Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation. Diagram → questions → mitigations → owners. No attack recipes — design habit. Capital One-style lessons = trust boundaries on the whiteboard. Next: digital forensics beginners guide.

Frequently asked questions

What does STRIDE stand for?

Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.

Is threat modeling the same as a pentest?

No. Modeling is early design review; pentests are later authorised tests with RoE.

How detailed should the diagram be?

Short enough that builders read it — one feature per session beats an unread 80-page binder.

How does Capital One 2019 relate?

Public lessons highlight trust boundaries around cloud metadata and app roles — put them on the diagram.

Does this page include exploits?

No. Categories map to mitigations only.

Where should I read next?

OWASP Top 10, Zero Trust and ethical pentest guides on this site.