CYBER-01-002-P · Primer — Threat Modeling (STRIDE)

The idea in one sentence

Threat modeling is asking, before you build, how each part of your system could be attacked — and STRIDE is the checklist that makes sure you ask every question.

Why it exists

"Is this design secure?" is a blank page, and blank pages get skipped. Left to intuition, teams guess at a few scary attacks, miss whole categories, and only discover the gaps after a breach. Threat modeling replaces the guess with a routine: draw the system, then walk a fixed list of threat types against each piece. It is the security equivalent of a pilot's pre‑flight checklist — the point is not that pilots forget how to fly, it is that a written list catches the one item a busy human skips. Imagine a homeowner who only checks the front door before leaving; they might forget the back window, the garage door, or the basement hatch. The checklist forces them to verify every possible entry point, just as STRIDE forces a team to verify every possible threat vector.

How it works

Two beats. First, decompose — draw the system as components and the data flowing between them: users, services, the database, the queue, every trust boundary they cross. That diagram is your list of assets. Second, enumerate — for each component, run the six STRIDE categories and ask "can this happen here?" Spoofing (pretending to be someone else), Tampering (altering data or code), Repudiation (denying an action with no proof), Information disclosure (leaking data), Denial of service (making it unavailable), Elevation of privilege (gaining rights you shouldn't have). Each letter maps to a property you want: authentication, integrity, non‑repudiation, confidentiality, availability, and authorization. Six questions, per component, on purpose.

Worked example: Suppose you have an e‑commerce checkout flow with three components: a web front‑end, a payment service, and a database. The web front‑end handles 10,000 transactions per day, each worth an average of $75 (≈ $750,000 daily volume). You draw the diagram and then ask the STRIDE questions for the payment service.

• Spoofing: Could an attacker impersonate the payment service? You discover the service uses a static API key stored in plain text, so the answer is yes – assign a risk score of 8/10.
• Tampering: Could transaction amounts be altered in transit? The API uses HTTP instead of HTTPS, giving a risk score of 9/10.
• Repudiation: Does the service log who initiated each payment? No logs exist, risk 7/10.
• Information disclosure: Does the service return full credit‑card numbers? It returns only the last four digits, risk 2/10.
• Denial of service: Can an attacker flood the service and halt payments? Rate‑limiting is missing, risk 6/10.
• Elevation of privilege: Can a compromised front‑end gain admin rights on the payment service? The service trusts any caller from the internal network, risk 8/10. Summing the scores highlights that spoofing, tampering, and elevation of privilege are the biggest gaps, directing you to rotate API keys, enforce TLS, and implement mutual TLS for internal calls.

See it — A simple STRIDE threat model showing system components and data flow.

flowchart LR
A["User"] --> B["API Service"]
B --> C["Database"]
B --> D["Message Queue"]

The one gotcha

The most common pitfall is treating the diagram as the complete system when it is merely a snapshot. If a component—say, a legacy admin console that still runs on port 8080—is omitted, STRIDE never evaluates it, and the real attack surface remains invisible. A flawless STRIDE pass on an incomplete diagram creates a false sense of security; the hidden piece becomes the low‑hanging fruit for attackers. The discipline, therefore, is exhaustive inventory: every server, every temporary script, every third‑party webhook must be drawn before you start the checklist.

The one-line takeaway

You can't defend what you never listed as an asset.

Where you'll meet it

STRIDE is the default lens in Microsoft's Threat Modeling Tool and the backbone of most design‑review templates; OWASP's Threat Modeling guidance folds it into the four questions "what are we building, what can go wrong, what will we do, did we do a good job." You will meet it in security design reviews, architecture sign‑offs, and any pull request big enough to change a trust boundary — usually as a table with one row per component and six columns.

Named concepts: threat modeling, STRIDE