STRIDE threat modeling, with a worked example

Threat modeling is, in the words of the Threat Modeling Manifesto, “analyzing representations of a system to highlight concerns about security and privacy characteristics.”[2] The manifesto organizes the work around four questions: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? STRIDE answers the second one systematically.

What does STRIDE stand for?

STRIDE is a classification of threats developed at Microsoft. Each letter is the violation of one security property. The pairing below is Figure 3 of the 2006 MSDN Magazine article by Hernan, Lambert, Ostwald and Shostack, which is still the clearest primary description.[1]

Threat	Violates	Typical question
Spoofing	Authentication	Is it really who or what it claims to be?
Tampering	Integrity	Could it be changed without authorization?
Repudiation	Non-repudiation	Could someone deny doing it, with no proof otherwise?
Information disclosure	Confidentiality	Could it be read by someone who should not?
Denial of service	Availability	Could it be made unavailable?
Elevation of privilege	Authorization	Could someone gain rights they were not given?

Which threats apply to which elements?

Use a data-flow diagram with four element types plus trust boundaries. The same article’s Figure 5 lists which threats each element type is susceptible to:[1]

Element	S	T	R	I	D	E
External entity (interactor)	x		x
Process	x	x	x	x	x	x
Data store		x		x	x
Data flow		x		x	x

This is what keeps STRIDE from being a brainstorm. Each element gets a fixed set of questions, and you can show you asked all of them.

Worked example: a document upload service

Customers upload documents; an API stores them; a scanner process reads new files and checks them. The diagram above has six elements:

• Customer: external entity.
• Upload API and Scanner: processes.
• Document store: data store.
• F1 (Customer to Upload API), F2 (API to store), F3 (API to Scanner, a queue message) and F4 (store to Scanner): data flows. Only F1 crosses the trust boundary.

That gives 2 + 6 + 6 + 3 + (4 × 3) = 29 element-threat pairs. A few of them, worked through:

Customer, Spoofing. Could someone upload as another customer? This turns on how the API authenticates callers and binds uploads to the authenticated identity. Candidate controls: IA-2 Identification and Authentication (Organizational Users), IA-8 Identification and Authentication (Non-organizational Users).

Customer, Repudiation. Could a customer deny uploading a file that later turns out to be malicious? Only if the upload is not logged with the authenticated identity, time and file hash. Candidate controls: AU-3 Content of Audit Records, AU-10 Non-repudiation.

F1, Tampering. Could the file be modified in transit? With TLS terminated at the API, the exposure is at any proxy that terminates TLS earlier. Candidate controls: SC-8 Transmission Confidentiality and Integrity, SC-8(1) Cryptographic Protection.

Upload API, Elevation of privilege. Could a crafted filename or archive make the API write outside its directory, or make the scanner execute content? This is where input validation and process isolation matter. Candidate controls: SI-10 Information Input Validation, SC-39 Process Isolation.

Document store, Information disclosure. Who can read the store, including backups, snapshots and exports? Candidate controls: SC-28 Protection of Information at Rest, AC-3 Access Enforcement.

Upload API, Denial of service. What happens with a 50 GB upload, or a zip that expands to fill the disk? Candidate controls: SC-5 Denial-of-service Protection, SC-6 Resource Availability.

Where should you spend the effort?

On the trust boundary. The STRIDE article’s authors discuss a flow that stays inside one boundary and conclude that a flow crossing the boundary is “clearly more exposed” and deserves effort to match, while noting that boundaries can be drawn wrong and situations change.[1] In the example, the six questions on F1 and the Customer deserve the deepest answers. The STRIDE worksheet flags boundary-crossing flows for this reason.

What do you do with each threat?

Record a decision for every pair:

• Mitigated: name the control and where it is implemented.
• Open: a gap with an owner, carried into the architecture review.
• Risk accepted: who accepted it, and until when.
• Not applicable: say why, briefly. “Not applicable” without a reason is how threats get lost.

Common mistakes

• Modeling the implementation, not the function. Collapse similar elements inside the same boundary into one. The article’s authors advise thinking “major function,” not implementation.[1]
• Skipping the reader of a data store. A store that is written but never read hides the second half of its threats.
• Treating STRIDE categories as exclusive. One weakness often produces several threats; spoofing an administrator becomes denial of service. Record it where you found it and move on.
• Stopping at the list. The fourth manifesto question, “Did we do a good enough job?”, is answered by checking that each threat has a decision and an owner.

References

1. Uncover Security Design Flaws Using The STRIDE Approach. Shawn Hernan, Scott Lambert, Tomasz Ostwald, Adam Shostack, MSDN Magazine (Microsoft), 2006-11.Practitioner article (vendor, archived) · checked 11/04/2026 (full text)
2. Threat Modeling Manifesto. Threat Modeling Manifesto working group.Community document (CC BY 4.0) · checked 11/04/2026 (page)
3. SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (OSCAL release 5.2.0). National Institute of Standards and Technology (Joint Task Force), 10/22/2026.Official standard (machine-readable) · checked 11/04/2026 (dataset)

Revisions

Rev	Date	Description
0	11/04/2026	First issue.