Two days ago on this blog we made a point of not quoting a cost multiplier for skipping design-time analysis — the "100x cheaper to fix at design" figures are real numbers from real studies, but their methodology and applicability to modern delivery are genuinely disputed, and quoting one to an engineering audience invites a rebuttal you will lose. We said the direction of the inequality is not controversial and the magnitude is unknowable, so don't claim it.
This post takes the other approach. Instead of a multiplier, three breaches, three regulatory settlements, three numbers that are not in dispute because they are matters of public record — and in each case, the specific design question that, had anyone asked it in a design review, would have surfaced the flaw an attacker later found in production.
The short version: Capital One paid $270 million in fines and settlements over a cloud credential that could reach more than it needed to. Target paid at least $292 million over a vendor connection nobody had asked "why does this reach the card network?" about. Equifax paid up to $700 million over a breach where an unpatched library got an attacker in the door, and a segmentation gap let them walk through the rest of the building. Two of these are clean threat-modeling failures. The third is a patch-management failure with a threat-modeling failure riding along inside it — and the honest version of this article says so.
Why case studies instead of a multiplier
A cost multiplier is a claim about the average. It has to account for every threat modeling session that caught nothing important, every design flaw that never got exploited, every near-miss nobody ever wrote down because nothing happened. Averaging that honestly is a research problem, and the studies that try are the ones whose methodology gets disputed.
A specific breach sidesteps the averaging problem entirely. Capital One's $80 million OCC penalty is not an estimate — it's a number in a consent order. Target's $18.5 million multistate settlement is not modeled — it's a number 47 state attorneys general signed. You don't need a methodology to defend a fact that already happened to someone else, in public, with regulators attached. What you lose is generality: three breaches are three data points, not a distribution, and treating them as more than illustrative is exactly the kind of overreach the closing section of this piece pushes back on.
Case 1 — Capital One: a credential that could reach more than its job
On July 29, 2019, Capital One disclosed that a former Amazon Web Services employee had exploited a server-side request forgery (SSRF) vulnerability in the bank's web application firewall. The WAF was tricked into making a request to AWS's internal instance metadata service, which handed back temporary security credentials for the IAM role attached to that WAF. That role turned out to be able to list and read a wide set of S3 buckets — far more than a web application firewall has any operational reason to reach. The attacker used the credentials to pull data on more than 106 million individuals: names, addresses, credit scores, and roughly 140,000 Social Security numbers.
The SSRF itself is a pen-test-shaped finding — an implementation defect in a specific firewall rule, the kind of thing a scanner or a tester probing that endpoint could plausibly have caught. It is the second half of the chain that a threat model, not a test, is built to catch: an attacker who compromises this one component now holds a credential — what does that credential actually reach? That is not a question about whether the WAF has a bug. It is a question about whether the IAM role's permissions were scoped to the WAF's job, and it is answerable at design time, on a diagram, before a single line of the firewall rule exists.
The Office of the Comptroller of the Currency's consent order didn't cite the SSRF as the finding — it cited Capital One's "failure to establish effective risk assessment processes prior to migrating significant information technology operations to the public cloud environment." That is regulator language for exactly the gap this blog's cloud infrastructure post argues for: model the control plane and the identity boundary, not just the network boundary, because in a cloud architecture the credential is the perimeter.
What it cost: an $80 million civil penalty from the OCC, plus a $190 million class-action settlement — $270 million total, before counting incident response, legal fees, and the multi-year cloud risk-management overhaul the consent order also required.
The design question that was skipped: "This component's credential can reach every bucket in the account. Does its job require that, or does it require three buckets?"
Case 2 — Target: a vendor invoicing system with a path to the card network
In November and December 2013, attackers stole network credentials from Fazio Mechanical Services, a Pennsylvania HVAC and refrigeration contractor that had remote access into Target's systems for billing, project management, and contract administration. From that foothold, they moved laterally into the point-of-sale environment and installed memory-scraping malware on registers across roughly 1,800 stores, harvesting card data from an estimated 40 million accounts and personal information from up to 70 million customers.
A vendor with billing-system access reaching a network segment that handles live cardholder data is not a bug in the HVAC vendor's software — it's an architectural decision, made at some point by someone, about how many degrees of separation the vendor portal has from the point-of-sale environment. Our vendor integration post makes the point directly: you cannot threat model a vendor, only the integration, and the question that matters is what the integration can reach, not whether the vendor is trustworthy.
Nothing public says Target skipped a design review for this specific integration — attributing intent in hindsight is exactly the kind of claim this article's closing section warns against. What is verifiable is the outcome: a billing-and-scheduling connection had a network path into the payment environment, and once that path exists, the question of whether the vendor's own security is any good stops being the load-bearing control.
What it cost: $18.5 million in a 2017 multistate settlement across 47 states and DC — at the time, the largest multistate data breach settlement on record — against cumulative breach-related expenses Target's own 2017 10-K put at $292 million.
The design question that was skipped: "Does a system that schedules HVAC maintenance need a network path to the systems that process a card swipe?"
Case 3 — Equifax: the honest, mixed case
In September 2017, Equifax disclosed a breach affecting approximately 147 million people — names, dates of birth, Social Security numbers, and addresses. The initial entry point was CVE-2017-5638, a critical remote code execution vulnerability in Apache Struts. Apache published a patch on March 7, 2017. Equifax's own systems were compromised starting May 13, 2017 — roughly two months during which the fix existed and had not been applied. A House Oversight Committee investigation called the breach "entirely preventable" on exactly this basis.
We are not going to claim threat modeling would have prevented this one, because it wouldn't have. An unpatched dependency is a vulnerability-management failure — the domain of scanning, patch cadence, and asset inventory, not of a design-time review. Calling every breach a threat-modeling failure is precisely the kind of overclaiming that makes an experienced engineer stop taking the argument seriously, and we said as much when we ran the symmetric case in the pen testing comparison: unknown vulnerabilities in your dependencies are one of the things a model structurally cannot find.
What is a design question is what happened after the initial compromise. Investigators found that the compromised web application server had network reachability into a wide range of other internal systems — inadequate segmentation let the intrusion spread well beyond the one application that got popped. Separately, a digital certificate used to inspect encrypted traffic on a particular monitoring device had expired nineteen months earlier and was never renewed, which meant outbound traffic on that segment went uninspected for the length of the intrusion. Neither of those is "unpatched software." Both are architecture and operations decisions: how far does a compromise of this one server reach, and does our detection actually cover the path an attacker would take out.
This is the case worth including precisely because it doesn't fit the clean narrative. A patch-management failure got the attacker in. A segmentation-and-monitoring design gap is why "one exploited library" became "147 million records" instead of a contained incident on one server.
What it cost: up to $700 million in a 2019 settlement with the FTC, the CFPB, 48 states, DC, and Puerto Rico — the largest data breach settlement on record at the time.
The design question that was skipped (for the part threat modeling actually addresses): "If this internet-facing application is compromised, what else on the network can it reach — and would we know if it did?"
What the three cases have in common
| Capital One (2019) | Target (2013) | Equifax (2017) | |
|---|---|---|---|
| How the attacker got in | SSRF against a WAF rule | Stolen vendor credentials | Unpatched Apache Struts CVE |
| Why it became catastrophic | Over-permissioned IAM role could reach far more than the WAF's job required | Vendor billing network had a path into the cardholder-data environment | Flat segmentation let one compromised server reach systems well beyond it; a lapsed monitoring certificate hid the exfiltration |
| Kind of failure | Design — trust assumption about a credential's reach | Design — trust boundary drawn in the wrong place | Mixed — patch management got them in; design let it spread |
| Confirmed cost | $270M ($80M OCC penalty + $190M settlement) | $292M cumulative (incl. $18.5M multistate settlement) | Up to $700M settlement |
None of the three headline numbers is "what a data breach costs." They're what these three specific breaches cost these three specific companies, under these three specific regulatory regimes, at the scale each operated at. A smaller company with a similar design flaw pays a smaller number, or a larger one, depending on the industry, the data, and which regulator shows up. What generalizes is not the dollar figure. It's that in two of three cases, and in part of the third, the finding traces to a question about what a component can reach that a structured review — not a scanner, not a test against what already exists — is the tool built to ask.
The cost that never makes a breach report
Every dollar figure above is visible because the flaw was found by an attacker instead of a design review. The inverse case is real and invisible by construction: the vendor integration that got scoped down to read-only after someone asked what it needed to reach, the IAM role that got split into three narrower ones during a cloud migration review, the network segment that got its own boundary because a workshop asked "what happens if this one server is popped." None of those produce a headline, a settlement, or a case study. They produce nothing happening, which is the actual product being sold and the hardest one to put a number on.
This is also why "we've never been breached" is weak evidence that the design is sound. Capital One, Target, and Equifax were also not-yet-breached companies for years before they weren't. The absence of an incident tells you the flaw hasn't been found yet, not that it isn't there — which is the same point our buy-in post makes about the hardest objection to answer: "we haven't had a problem" is a statement about attacker behavior, not about your architecture.
Where this argument overreaches
It would be easy to end here on three big numbers and imply that a workshop would have stopped nine-figure settlements. That claim is stronger than the evidence supports, for reasons worth stating plainly rather than leaving for a critic to point out:
- Three breaches are an illustration, not a sample. They were chosen because they're exceptionally well documented — congressional testimony, regulatory consent orders, and forensic reports exist for all three — not because they're statistically representative of what threat modeling prevents on average. Availability bias runs in exactly this direction: famous breaches are famous partly because they're legible case studies, which makes them persuasive and not necessarily typical.
- Hindsight makes every flaw look obvious. "Why would a WAF's role need to list every bucket in the account" reads as self-evidently a mistake once you know it was exploited. Before the breach, it was one scoping decision among hundreds made under normal delivery pressure, by competent people, without the benefit of knowing which one an attacker would eventually use. The lesson is about the process that catches this class of decision, not about the individuals who made it.
- We don't know these companies skipped threat modeling. We know the outcomes. Whether Target's HVAC integration went through a design review that missed the risk, or never got one, isn't public information, and the article doesn't claim to know which. Either way the architecture is a fact regardless of process; be careful not to overstate the second claim to make the first one look better.
- A model would not have found all of it. Equifax's initial entry point is a category threat modeling doesn't cover, full stop. Presenting it otherwise, to make the case study cleaner, would be the same overclaiming failure this series has criticized in other contexts.
- Correlation with a design gap is not proof of causation with the fine. Regulators cite process failures broadly; the settlement amounts reflect the scale of the breach and the regulatory environment as much as the specific technical root cause. Treat the numbers as evidence that the stakes are large, not as a receipt proving a specific workshop would have saved a specific dollar amount.
The defensible claim is narrower than "threat modeling would have stopped these breaches," and it doesn't need the stronger version to be worth making: in at least two of three of the most expensive, most scrutinized breaches of the last decade, the mechanism that turned a single weakness into a catastrophic one is a category of question a design-time review is specifically built to ask, and an after-the-fact test or scanner structurally is not. That's not a multiplier. It's three receipts.
If your organisation is regulated the way these three were, see the industry threat modeling guides for what applies in fintech, healthcare, and critical infrastructure specifically. The free templates include a pre-labelled DFD and risk register if you want to run this exercise on your own architecture before someone else finds the gap first.