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); the Microsoft Security Development Lifecycle and its Threat Modeling Tool use the same model (ms-tmt-threats).

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):

The property column is not decoration. Microsoft defines each property as follows, and the definition is what tells you whether a candidate row is really in that category (ms-stride-approach, Figure 2):

• Authentication: "The identity of users is established (or you're willing to accept anonymous users)."
• Integrity: "Data and system resources are only changed in appropriate ways by appropriate people."
• Non-repudiation: "Users can't perform an action and later deny performing it."
• Confidentiality: "Data is only available to the people intended to access it."
• Availability: "Systems are ready when needed and perform acceptably."
• Authorization: "Users are explicitly allowed or denied access to resources."

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). 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, 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):

• 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).

Not every category applies to every element type. Microsoft's threats-affecting-elements matrix narrows the grid before you start (ms-stride-approach, 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). 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). 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). Requirement IDs below are ASVS 4.0.3.

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

Input spec:

"Users can upload a profile photo. We accept JPEG and PNG up to 5MB. Photos are stored in an object store and served via CDN."

Step 1 inventory: interactor = authenticated user; process = upload handler and image processor; data store = object bucket; data flows = browser to handler, handler to bucket, CDN to public internet; trust boundary = browser to server, and private bucket to public CDN.

Step 2 and 3 output:

No spoofing, repudiation, or elevation-of-privilege rows: the upload is authenticated by the existing session and grants no new capability, so those intersections were filtered in Step 3 rather than padded.

Contrast with a read-only /profile spec on the same system. Only two rows survive: session replay (S, against the interactor) and an insecure direct object reference (I, against the profile record: authorize by the session's user ID, never by a path parameter, per V4.1.2 (asvs-v4)). Small, but real. For a static text edit on a public marketing page, the inventory turns up no security-relevant assets and the honest output is exactly that.

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, ms-stride-approach).
• Category assignment is ambiguous by design. The letters cross-correlate (ms-dreadful). 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).