Skip to main content

STRIDE Applied to Your System

What This Concept Is​

STRIDE is a checklist for finding threats by category against a specific system boundary. Adam Shostack codified it at Microsoft in the 1990s; OWASP adopted it as the most widely taught threat-modeling technique. The letters stand for:

  • Spoofing -- an actor claims to be someone they are not
  • Tampering -- data or code is modified without authorization
  • Repudiation -- an actor denies having taken an action you cannot prove
  • Information disclosure -- data is read by someone who should not see it
  • Denial of service -- legitimate use is blocked by resource exhaustion
  • Elevation of privilege -- an actor gains more access than they should have

You apply STRIDE to a data-flow diagram (DFD): boxes for processes and data stores, arrows for flows, a trust boundary drawn wherever trust changes. For each element and flow, walk through S-T-R-I-D-E and ask: "which of these are plausible here, and what mitigation already blocks them?"

STRIDE sits inside the broader "four questions" framework from the Threat Modeling Manifesto and OWASP: (1) What are we working on? (2) What can go wrong? (3) What are we going to do about it? (4) Did we do a good enough job? STRIDE is a structured answer to question 2; the DFD answers question 1; the walked mitigations answer question 3; the PRR in concept 15 answers question 4.

STRIDE does not find novel attacks. It finds obvious attacks you have not yet mitigated. That is exactly what you need for a capstone: a high-hit-rate, low-ceremony pass that produces an auditable worksheet, not a three-week penetration test.

Why It Matters Here (In the Capstone)​

A capstone goes live with whatever security posture you happen to have built. "I'll think about it later" is not a posture. Running STRIDE once, finding three real threats, and walking one of them all the way to a deployed mitigation does three things:

  • it gives you a concrete, defensible story for the security section of the PRR (concept 15 item 8)
  • it uncovers at least one easy win -- usually rate-limiting, a missing auth check, or a logging gap that blocks the R in Repudiation
  • it builds the habit so you do not have to reinvent threat modeling the next time the design changes

It also feeds the downstream concepts: Spoofing and Elevation of Privilege become least-privilege work (concept 9); Information Disclosure becomes secrets and data classification (concept 8); Denial of Service becomes load shedding and circuit breakers (concept 11).

Concrete Example(s) -- from a real capstone​

Consider the webhook-handler capstone with this DFD:

[External provider] --HTTPS--> [API service] --TLS--> [Queue] --TLS--> [Worker] --TLS--> [Database]
                                   |
                                   +--read/write--> [Secrets store]
                                   |
                                   +--writes-audit--> [Audit log bucket]

Trust boundary: between external provider and API service. Everything inside (queue, worker, DB, audit bucket, secrets store) is inside your VPC -- but the secrets store itself is a second, finer trust boundary.

Run STRIDE on the flow [External provider] -> [API service]:

LetterPlausible threat here?Current stateGap
S -- SpoofingSomeone impersonates the provider and sends forged webhooksWebhook body is HMAC-signed with a provider-shared secret; API verifiesNone critical
T -- TamperingBody modified in transitTLS 1.2+ enforced; HMAC covers bodyNone
R -- RepudiationProvider later claims "we never sent that event"We log body hash + provider_id + timestamp per requestNone
I -- Information disclosureRequest body contains PII that ends up in logsWe log the hash, not the body, but signature verification errors dumped body[:200] to logYes -- fix this
D -- Denial of serviceProvider sends bursts that saturate the APINo rate limit per provider. One chatty provider can choke the shared APIYes -- add per-provider limits
E -- Elevation of privilegeProvider can make API perform privileged action it should notAPI has no admin endpoints. Provider token only accepted on /webhookNone

Now pick one letter -- let us walk I all the way:

Information disclosure -- full walk:

  1. Threat: when signature verification fails, we log a 200-byte slice of the body to debug the failure. Some providers send PII in their body.
  2. Evidence: search logs for event=webhook.signature_rejected -- confirmed, bodies appear.
  3. Mitigation: replace the body-slice with body_hash=sha256(body) and len=len(body). Keep the first 8 bytes of the hash for debugging correlation.
  4. Detection: add a test that emits a fake failing signature and asserts the log line contains body_hash= but no body= substring. Fail CI on regression.
  5. Residual risk: debug tooling may still surface raw bodies in traces. Scrub http.request.body attributes in the OTel pipeline. Documented.
  6. Deployed: commit, code review, deploy, verify in staging with a signed fixture. Audit log shows the redaction is active.

That is what "walking a threat all the way" looks like: threat -> evidence -> mitigation -> detection -> residual -> deployed. Do not check a STRIDE box off without finishing the walk.

Common Confusion / Misconceptions​

"STRIDE is a security audit." It is not. It is a discovery checklist. It catches obvious categorical gaps; a real audit would include static analysis, dependency scanning, penetration testing, and a human review. Do STRIDE first because it is cheap and the hit rate is high.

"STRIDE on every element" -- for a capstone, focus on flows that cross trust boundaries. That is where categorical threats are most likely. Internal flows inside a single trust zone usually have much lower yield per hour spent.

"Every threat deserves a mitigation." Some threats are accepted with documented rationale ("not worth the engineering cost at current scale"). A STRIDE worksheet with "accepted: X" and a reason is stronger than one that pretends the threat is mitigated when it is not.

"R is hard to mitigate, skip it." Repudiation is usually mitigated with logs. If your logs do not contain enough signed evidence to prove "user X did action Y at time Z," you have an R problem in every compliance conversation you will ever have.

How To Use It (In Your Capstone)​

  1. Draw the DFD for your capstone on one page. Mark every trust boundary.
  2. For each flow crossing a trust boundary, make a STRIDE table with six rows.
  3. Mark each cell: mitigated (how), gap, or accepted (why). Do not leave any cell empty.
  4. Pick the highest-value gap. Walk it all the way: threat -> evidence -> mitigation -> detection -> residual -> deployed.
  5. Map every gap to a downstream capstone artifact: secrets policy (concept 8) for keys/credentials, IAM policy (concept 9) for S/E, rate limits (concept 11) for D, audit logs (concept 4) for R.
  6. Commit the worksheet and the walk into library/raw/threat-model.md and link it from the PRR checklist.
  7. Re-run STRIDE when the architecture changes -- new external dependency, new data store, new authentication scheme.

See also (integrative)​

Check Yourself​

  1. Why do trust boundaries matter more than internal-process boundaries for STRIDE yield?
  2. What evidence would prove that a repudiation threat has actually been mitigated?
  3. Which letter of STRIDE most often surfaces issues that belong in logs and runbooks, not in code changes?
  4. Why is "accepted: X with reason Y" stronger than "mitigated" with no evidence?
  5. Which OWASP threat-modeling question does STRIDE answer, and which three questions does it not answer?
  6. Pick one capstone flow: which of the six letters is least likely to produce a real gap, and why?

Mini Drill or Application (Capstone-scoped)​

  1. In 60 minutes: draw your capstone's DFD and mark trust boundaries.
  2. Pick the single most important flow across a boundary (usually the one your SLO guards).
  3. Fill in a 6-row STRIDE table for that flow. Be specific; "probably fine" is not an entry.
  4. Pick the one cell most likely to be a real gap. Walk it all the way to deployed using the five-step chain above.
  5. File the worksheet at library/raw/threat-model.md, commit the mitigation PR, and link both from the PRR checklist (concept 15, item 8).

Source Backbone​

Capstone operations applies security, reliability, and distributed-systems material. These books are the source backbone for readiness review.