Threat Modeling & Risk Management

Analogy: Threat modeling is the security version of an architect's structural review before the concrete is poured, or a pilot's pre-flight checklist before takeoff. It is far cheaper and saner to find the crack on paper than after it's holding up the building. IBM's Cost of a Data Breach Report 2025 backs this up: breaches caught and contained quickly cost dramatically less. Finding the flaw early — at design time — is the cheapest fix you will ever make. This is what people mean by "shift left": move security thinking earlier in the build.

7.1 When to do it

Do threat modeling early — during design, when changing the diagram costs nothing — and then re-do it whenever the system changes in a meaningful way: a new feature, a new third-party integration, a jump in how sensitive the data is, or a new trust boundary (a line where the level of trust changes — defined fully below). It is a loop, not a one-off.

7.2 The Four Questions (the backbone — memorize THIS)

The durable skill is not memorizing acronyms. It is the habit captured by Adam Shostack's Four Questions, codified in the Threat Modeling Manifesto (published 2020 by 15 practitioners; still the canonical reference, and Shostack was still teaching it in late 2025):

1. What are we working on? Build a model — diagram the system, its data flows, and its trust boundaries.
2. What can go wrong? Enumerate threats. STRIDE, attack trees, PASTA, LINDDUN are just tools that help you answer this one question.
3. What are we going to do about it? For each threat, choose to mitigate, accept, transfer, or avoid.
4. Did we do a good job? Validate that the model is complete and the mitigations actually work; feed the lessons back in.

The framework is deliberately method-agnostic: every named method below simply plugs into Question 2. The Manifesto's values are worth absorbing — "people and collaboration over processes, methodologies, and tools," and "a journey of understanding over a security-or-privacy snapshot."

7.3 Question 1 — modeling the system: DFDs and trust boundaries

The classic artifact for "what are we working on" is a Data Flow Diagram (DFD) — a picture of how data moves through your system. It has four element types:

External entity (square)

Something outside your control — a user, a third-party API.

Process (circle)

Your code or services that act on data.

Data store (parallel lines)

Where data rests — databases, caches, S3 buckets.

Data flow (arrow)

Data moving between the above.

The crucial overlay is the trust boundary: a dotted line drawn wherever the level of trust changes — internet to server, app to database, browser to backend, or (critically for multi-tenant SaaS) tenant A to tenant B. Rule of thumb: most threats live where data crosses a trust boundary.

   [ Customer ]                         (Internet -> Server boundary)
       |  login + order data            ............................
       v                                .                          .
   ( Storefront API ) --- query ---> | Tenant DB (per-tenant) |   .
       |                              .                            .
       |  cross-tenant boundary  - - - - - - - - - - - - - - - -  .
       v                              .                            .
   ( Admin API ) ----- read -----> | Other Tenant's Data |  <-- IDOR
                                      .  risk lives HERE         .
   [ 3rd-party Payment API ] <--- token ---> ( Payment Service )

In a system like PF360, the dotted line between two tenants is exactly where cross-tenant IDOR (Insecure Direct Object Reference — accessing another user's record by changing an ID) and isolation bugs live. The diagram doesn't need to be pretty: a whiteboard sketch counts. Free tools like OWASP Threat Dragon and the Microsoft Threat Modeling Tool can auto-suggest threats per element. Good-enough-and-current beats perfect-but-stale.

7.4 Question 2, tool #1 — STRIDE in detail

STRIDE (Microsoft, ~1999) is the dominant developer-facing method. Each letter is a threat that violates one security property. Walk every DFD element and ask, "Can this happen here?"

Letter	Threat	Violates	Example & real incident	Mitigation
S	Spoofing	Authentication	Pretending to be someone you're not — stealing a session cookie. 2024 Snowflake breach: attackers used stolen credentials to log into accounts with no MFA, hitting AT&T, Ticketmaster, Santander — hundreds of millions of records.	Strong auth, MFA, mutual TLS, signed tokens
T	Tampering	Integrity	Altering data/code — SQL injection, changing a price in a request. 2023 MOVEit zero-day (CVE-2023-34362): a SQLi flaw exploited across 2,500+ orgs, ~100M people.	Input validation, parameterized queries, hashing, TLS, code signing
R	Repudiation	Non-repudiation	A user denies an action and you can't prove otherwise — deleting logs, "I never placed that order."	Tamper-evident audit logs, signed transactions, secure timestamps
I	Information disclosure	Confidentiality	Exposing data — verbose stack traces, IDOR, a leaky S3 bucket, unencrypted PII (Personally Identifiable Information).	Encryption, access control, least privilege, generic error messages
D	Denial of service	Availability	Making a system unusable — traffic floods, an expensive unbounded query.	Rate limiting, throttling, autoscaling, quotas, CAPTCHA
E	Elevation of privilege	Authorization	Gaining powers you shouldn't — editing a JWT to set role=admin. 2024 Change Healthcare: attackers entered a Citrix portal with no MFA, then escalated; ~$22M ransom, 192.7M records — the worst US healthcare breach ever.	Server-side authz on every request, least privilege, deny-by-default

Quick mapping: external entities mostly face S and R; processes face all six; data stores face T, I, D (and R for logs); data flows face T, I, D.

7.5 Question 2, other tools (briefly)

Attack trees (Schneier, 1999)

Attacker-centric. The attacker's goal is the root; branches are ways to reach it down to concrete leaf steps. Nodes are OR (any one child works) or AND (all children needed). Annotate leaves with cost, skill, or probability and propagate upward to find the cheapest path — that's where to defend. Schneier's toy example: goal "open the safe" with OR branches (pick lock / learn combo / cut it open). The UK NCSC maintains a current guide.

PASTA (~2015)

Heavyweight, business-and-risk-centric, 7 stages from business objectives through decomposition, threat/vulnerability analysis (using CVSS), attack modeling (produces attack trees), to risk & impact. Strength: ties technical threats to business impact so executives can prioritize. Cost: time. Use for high-stakes systems only.

LINDDUN (KU Leuven)

The privacy counterpart to STRIDE: Linking, Identifying, Non-repudiation, Detecting, Data disclosure, Unawareness, Non-compliance. Note the twist — here Non-repudiation is a threat (a user can't plausibly deny something they wanted kept private). Linking = correlating two records to the same person without naming them; Identifying = unmasking them. "LINDDUN GO" is a lightweight card deck. It's referenced by the NIST Privacy Framework and ISO/IEC TR 27550 — use it whenever the system handles personal data, increasingly required under GDPR's "data protection by design."

7.6 Risk = Likelihood × Impact

You can't fix everything, so you prioritize. The single most important formula here is Risk = Likelihood × Impact — how probable the threat is, times how much damage it would do.

• Qualitative risk: ratings like Low/Medium/High, often a 5×5 likelihood-vs-impact "heat map." Fast, subjective, great for ranking and for non-technical stakeholders.
• Quantitative risk: real money. The classic formula is ALE = SLE × ARO — Annual Loss Expectancy = Single Loss Expectancy × Annual Rate of Occurrence. Rigorous; lets you justify spend ("a $50k control prevents $400k/yr expected loss"). But it needs data you often don't have.

The 2025 norm: use qualitative to triage everything, then run quantitative on the top few. To make "impact" concrete, anchor it: IBM's 2025 report puts the global average breach at $4.44M (down 9% year-over-year thanks to faster AI-assisted detection), with the US a record $10.22M; healthcare remains the costliest sector.

7.7 The risk register and risk treatment

The risk register is the durable, audit-friendly artifact: a living log, one row per risk, capturing description, owner, likelihood, impact, score, chosen treatment, status, and review date. It proves to an auditor that risks were considered, not ignored. For each risk you pick one of four canonical treatments (ISO 31000 / NIST SP 800-39):

Treatment	What it means	Watch out for
Mitigate / Reduce	Add controls to lower likelihood or impact (the default).	Leaves residual risk — check it's now acceptable.
Avoid	Don't do the risky thing; remove the feature.	Sometimes the safest answer.
Transfer / Share	Push it elsewhere — cyber insurance, outsourcing, contracts.	You can't outsource trust: reputational + residual risk stay with you.
Accept	Knowingly tolerate it (below tolerance, or fixing costs more than it's worth).	Must be a documented, signed-off decision by a risk owner — never silent.

Two concepts to know: inherent risk (before controls) versus residual risk (after controls). You treat down until residual risk fits your risk appetite. Standards to name-drop: ISO 31000 (principles/process), NIST SP 800-30 (assessment) and 800-37 (the Risk Management Framework).

7.8 DREAD — and why it's deprecated

DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) rates each 0–10 and averages them. Microsoft created it, then abandoned it. Why: it's hopelessly subjective (two analysts score the same threat wildly differently — ironic for a discipline about being methodical); its Discoverability dimension rewards security-through-obscurity (it implies a hard-to-find bug is safer, which contradicts "assume the attacker will find it"); and it has no industry calibration, so scores can't be compared across teams. Treat DREAD as a teaching on-ramp to "rate likelihood and impact," but don't ship with it.

7.9 CVSS — scoring known vulnerabilities

CVSS (Common Vulnerability Scoring System, from FIRST.org) is the industry standard for scoring how severe a known vulnerability is, 0.0–10.0 (None → Critical). The current version is CVSS v4.0 (released November 2023; v3.1 still common through 2025–26). It groups metrics into Base (intrinsic), Threat (renamed from "Temporal," now a single Exploit Maturity metric), Environmental (your deployment), and new Supplemental (context that doesn't change the score). v4.0 added an Attack Requirements metric and replaced the confusing "Scope" with explicit Vulnerable-System vs Subsequent-System impacts.

7.10 Common mistakes

• Treating threat modeling as a one-time document instead of a recurring activity.
• Skipping trust boundaries — where the real threats live.
• Confusing CVSS severity with actual risk in your environment.
• "Accepting" a risk informally, with no owner and no sign-off (silent acceptance).
• Using DREAD's subjective scores as if they were objective.
• Modeling only security and forgetting privacy (LINDDUN).
• Over-engineering with PASTA on a low-stakes feature when a 30-minute STRIDE-on-a-whiteboard would do.
• Insuring or outsourcing a risk and assuming it's gone — residual and reputational risk remain.

7.11 Best practices

• Run the Four Questions early, at design time, and re-run them whenever the system or data sensitivity changes.
• Always draw the trust boundaries first; concentrate your STRIDE effort where data crosses them.
• Right-size the method: lightweight STRIDE for most features, PASTA only for high-stakes systems, LINDDUN whenever personal data is involved.
• Triage with a qualitative heat map, then run quantitative (ALE) on the top few.
• Keep a living risk register; make every "accept" a documented, owner-signed decision with a review date.
• Score vulnerabilities with CVSS v4.0, but prioritize patching with KEV + EPSS + your context.

7.12 The throughline to the audit discipline

Threat modeling and risk management are the methodical, repeatable, durable skill this guide is building toward. The Four Questions are a repeatable loop; the DFD, threat list, and risk register are the auditable artifacts; and treatment decisions — especially "accept" — must be documented and owned, which is exactly what an auditor checks. This thinking is now law, not just good hygiene: the EU AI Act (in force 1 Aug 2024) uses a risk-based tiering — unacceptable / high / limited / minimal — identical in spirit to everything above, with fines up to €35M or 7% of global turnover.