stride-threat-modeling

What this owns, and what it does not

This skill turns "we are adding feature X" into a table of candidate threats against the design of X, classified by STRIDE, each with a named mitigation.

The output is a planning document about a design, not a finding about a system. That boundary decides what belongs here:

If the design already shipped and you want to know whether it is actually vulnerable, you want a scanner or a tester. This produces the list of things those tools should later be pointed at.

The six STRIDE categories

STRIDE is Microsoft's threat classification, "derived from an acronym for the following six threat categories" (ms-stride (opens in new window)); the Microsoft Security Development Lifecycle and its Threat Modeling Tool use the same model (ms-tmt-threats (opens in new window)).

Each letter is the negation of one security property. Microsoft's own mapping (MSDN Magazine, Figure 3, "Threats and Security Properties") pairs them as below (ms-stride-approach (opens in new window)):

The property column is not decoration: the property an attack actually breaks is what tells you whether a candidate row really belongs in that category (ms-stride-approach (opens in new window), Figure 2).

Microsoft is explicit that the classification is not rigorous: the categories cross-correlate, because "escalation of privilege (E) tends to imply spoofing and loss of non-repudiation, and could imply tampering, information disclosure, and denial of service" (ms-dreadful (opens in new window)). Do not spend time arguing which letter a threat belongs under. Pick the property the attack actually breaks, record the row, and move on.

Step 1 - Inventory what the design contains

Walk the spec and tag four things. Microsoft's data-flow-diagram vocabulary gives the element types (ms-stride-approach (opens in new window), Figure 4): data flows, data stores, processes, interactors, plus trust boundaries, which are added specifically for threat modeling.

Two sanity rules from the same source keep the inventory honest (ms-stride-approach (opens in new window)):

• No magic sources or sinks. "data isn't created out of thin air. Make sure you have a user represented as a reader or writer for each data store." A store nobody reads means the spec omitted a reader, not that the reader is out of scope.
• No psychokinesis as transport. "make sure there is always a process that reads and writes data. It doesn't go directly from a user's head to the disk."

Record the inventory before you write a single threat. The completeness of the threat table is bounded by the completeness of this list.

Step 2 - Ask the STRIDE question per element

For each (element x STRIDE category), ask: what is the most plausible threat in this category against this element? Ask it as a question, not as an assertion, which is the form Microsoft recommends ("How can an attacker change the authentication data?", "What is the impact if an attacker can read the user profile data?", "What happens if access is denied to the user profile database?") (ms-stride (opens in new window)).

Not every category applies to every element type. Microsoft's threats-affecting-elements matrix narrows the grid before you start (ms-stride-approach (opens in new window), Figure 5):

Model the asynchronous surface as well as the synchronous one. Queues, cron jobs, and batch workers are processes and data flows like any other, and the matrix above applies to them identically.

Step 3 - Filter

Drop the intersections where no credible threat exists for this design. A static asset with no service contract has no meaningful denial-of-service row. A read-only page with no write path has no tampering row. An empty cell is a result; a fabricated cell is noise that costs a reviewer real time.

If the inventory turns up no security-relevant assets at all (a copy edit on a public marketing page, for example), the correct output is a statement that no STRIDE-relevant assets were identified. Padding the table to look thorough is the single most common way these documents lose their audience.

Step 4 - Score for triage (practitioner convention, not part of STRIDE)

STRIDE is a classification scheme and carries no scoring rule. Nothing in Microsoft's STRIDE definition ranks or prioritizes threats (ms-stride (opens in new window)). The rule below is a practitioner convention for getting a triage order out of a threat table. Treat it as a team agreement you can change, not as a standard you are conforming to.

score = likelihood x impact       # each rated 1 (low), 2 (medium), 3 (high)
                                  # possible scores: 1, 2, 3, 4, 6, 9

Two things this is not:

• It is not DREAD. DREAD is a separate Microsoft risk-rating scheme with five factors: damage, reliability (reproducibility), exploitability, affected users, discoverability. Its co-author has published that the original "rate them from 1-10, add them up, and divide by 5" scoring is "an obvious malfunction", and that at Microsoft "we're NOT using this internally very much. This is NOT how MSRC does things" (ms-dreadful (opens in new window)). Do not present the 1-3 rule above as DREAD, and do not import DREAD's factors into it.
• It is not CVSS. CVSS scores disclosed vulnerabilities in shipped software. A design-stage threat has no confirmed vector to score. Coarse triage is the right resolution here.

Step 5 - Attach a specific mitigation

Every row needs a mitigation that is specific to that asset. Name the concrete control, and cite the verification requirement it maps to so a reviewer can check it later. OWASP's Application Security Verification Standard is the usual anchor: it "provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development" (owasp-asvs (opens in new window)).

Common threat shapes and their ASVS 4.0.3 anchors (session tokens, broken access control, IDOR, verbose errors, upload storage exhaustion, decompression bombs, polyglot files, executable upload paths) are tabulated in references/mitigations.md.

From-spec workflow

Turning "we're adding feature X" into a committed threat model runs the steps above against a concrete spec artifact:

1. Read the spec at the supplied path or URL (PRD section, user story, design doc, or architecture sketch).
2. Build the threat table end to end: the Step 1 asset and trust-boundary inventory, the Step 2 per-element STRIDE walk, the Step 3 relevance filter, the Step 4 triage score, the Step 5 mitigation anchors.
3. Write the artifact to docs/threat-models/<YYYY-MM-DD>-<feature-slug>.md in the output format below, so rows stay referenceable from tickets and test names.

Never fabricate threats. For a spec with no security-relevant assets (a static text edit on a public marketing page), the correct output is "No STRIDE-relevant assets identified" and a recommendation to skip - per the Step 3 filter and the anti-pattern catalog below.

Spec ambiguity discovered during the walk is a requirements defect, not a security finding: record it under "Open questions for the spec author" and route the sentence itself to the testability review workflow in spec-testability-heuristics.

Output format

# Threat model - <feature name>

**Spec source:** <path or URL>
**Date:** YYYY-MM-DD
**Spec authors should review every row.** A generated threat model is a
starting point, not a sign-off.

## Assets identified

| Asset | Trust boundary | Sensitive |
|---|---|---|
| `users` table (PII) | server-side DB | yes |
| Session token (JWT) | client localStorage to server | yes |
| Profile photo upload | client to object store | partial |

## Threats

| ID | STRIDE | Asset | Threat | Likelihood | Impact | Score | Mitigation |
|---|---|---|---|---|---|---|---|
| T-S1 | Spoofing | JWT | Stolen JWT replayed; attacker assumes user identity | 2 | 3 | 6 | Short-lived access tokens; refresh-token rotation; bind to client fingerprint or mTLS. ASVS 4.0.3 V3.5. |
| T-T1 | Tampering | Upload | Malformed image overflows the image-processing library | 2 | 3 | 6 | Hardened decoder; type by file content, not extension; per-user upload rate limits. ASVS 4.0.3 V12.2.1, V12.1.3. |
| T-I1 | Info disclosure | `users` table | Verbose errors leak DB column names | 2 | 2 | 4 | Generic error to client with a correlation ID; structured logging server-side only. ASVS 4.0.3 V7.4.1. |
| T-E1 | Elevation of privilege | Admin endpoint | Missing role check lets a non-admin call an admin route | 1 | 3 | 3 | Centralize authorization on the service layer; integration test asserts 403 for non-admin tokens on every admin route. ASVS 4.0.3 V4.1.1, V4.1.5. |

Scoring: likelihood x impact, each 1 (low) to 3 (high). Practitioner
convention, not part of STRIDE. 6 and above lands before ship; 3 to 5 are
backlog candidates; below 3 may be accepted with written rationale.

## Open questions for the spec author

<clarifying questions where the walk uncovered ambiguity>

Column notes: ID is T-<letter><n> so rows stay referenceable from tickets and test names. Asset names the specific element from the Step 1 inventory, never a whole subsystem. Threat is one sentence describing the attack, in the attacker's terms. Mitigation names a control plus its verification anchor.

Worked example

A full walk of a profile-photo-upload spec - the Step 1 inventory, the four surviving threat rows with ASVS anchors, and the contrast with a read-only page - is in references/mitigations.md.

Anti-patterns

Limitations

• A threat model is unproven by construction. Every row is a hypothesis about a design. Confirming exploitability is a separate activity.
• Completeness is not achievable. Microsoft's own position is that STRIDE was not "developed with any real academic rigor" and that a mitigated model does not prove a system secure, because "frequently threats materialize only when systems are joined to create larger systems" (ms-dreadful (opens in new window), ms-stride-approach (opens in new window)).
• Category assignment is ambiguous by design. The letters cross-correlate (ms-dreadful (opens in new window)). Consistency within one document matters; a globally correct assignment does not exist.
• ASVS requirement IDs are version-scoped. The IDs used above are ASVS 4.0.3. Later ASVS releases renumber chapters, so restate the version wherever a requirement ID appears (owasp-asvs (opens in new window)).