Breach Lessons Are Not a Threat Model

“Target had a vendor problem, so we just need the control Target was missing.”

Hold on.

That sentence is one approval away from being a purchase order.

A breach lesson is not your threat model.

Target had vendor access.

Target had insufficient segmentation between a vendor-facing system and its point-of-sale network.

Target had monitoring that reportedly flagged the malware activity, and was not acted on.

Useful facts.

Not a universal architecture diagram with the Target logo erased and your company name typed in.

A breach report gives you something valuable.

A path somebody actually used.

An assumption that failed.

A control that was absent or ineffective.

A consequence worth preventing.

It does not tell you which of your paths matters most, until you compare the conditions.

This isn’t subtle.

You would not read a fire investigation, notice one building lacked a sprinkler, and announce that every building’s highest fire risk is now sprinkler procurement.

You would ask what burned.

How it spread.

Which barriers existed.

Whether the next building has the same load path.

Put the word “breach” on your report and apparently those questions become optional.

They aren’t.

1. “But Real Incidents Are Better Evidence Than Hypothetical Threats.”

Yes.

A real incident is much better evidence than a threat model made entirely of mood boards and a red-team slide with a skull on it.

It is evidence of a particular path.

Target’s attackers obtained network credentials from Fazio Mechanical Services, a Pennsylvania HVAC and refrigeration vendor with remote access to your vendor billing portal, on 15 November 2013.

They then crossed inadequate segmentation between that vendor-facing system and the point-of-sale network, where they deployed a BlackPOS variant.

Card-data theft ran from 27 November to 15 December.

Excellent material for an abuse case.

It says: an external party has remote access.

That access may become network access.

The resulting trust boundary may be too broad.

A system holding valuable data may be reachable.

Monitoring may report activity without causing containment.

Now ask your local questions.

Does your vendor have remote access, or access only to a hosted support portal?

Can that identity reach a production network, an administrative API, a build system, or nothing beyond a ticket queue?

Does the path cross a boundary into payment data, customer data, industrial control, or merely a test tenant?

Is the detection signal owned by somebody with authority to act on it?

The incident supplies the question. Your local system supplies the answer.

2. “But the Breach Report Names the Failed Control.”

It often does.

That isn’t permission to read one noun and stop.

Target’s May 2017 settlement named absent two-factor authentication on vendor remote access, and inadequate segmentation between vendor systems and cardholder data.

Both concrete, defensible controls at distinct layers.

Authentication governs proof of your vendor identity.

Segmentation governs which systems that authenticated path can reach.

Neither phrase means “install the Target control.”

Your report does not say every third party should receive the same authentication method, the same network boundary, or the same operational response.

It says Target’s particular vendor access and its particular cardholder-data boundary were not adequately controlled.

Equifax is even less cooperative with the one-control story.

The 2017 intrusion used CVE-2017-5638 in an Apache Struts dispute portal.

A patch had been available since 7 March.

A 9 March internal alert went to a roughly 400-person distribution list, and the developer who knew the portal ran Struts was not on it.

That is a patch-management lesson.

It is also an asset-inventory lesson.

The later record names no asset inventory.

Patch verification on an honour system rather than an automated check.

Insufficient segmentation.

Unencrypted credentials on internal file shares.

And an expired certificate that stopped traffic-inspection tools seeing exfiltration.

That certificate had been expired for nine months when it was renewed on 29 July 2017, and detection finally occurred.

Extract only “patch faster” and you have converted your report into a bumper sticker, throwing away most of its defensive value.

3. “But Our Architecture Looks Similar.”

Similar to what?

The logo-free boxes in a slide deck?

Those aren’t the conditions that transfer risk.

Marriott inherited Starwood in September 2016.

But a web shell had been installed on Starwood’s guest reservation system on 29 July 2014.

The compromise remained until a Guardium database-monitoring alert on 8 September 2018.

Roughly four years and one month, inside a system an acquiring company had inherited.

The ICO’s October 2020 notice didn’t reduce this to “acquisitions are dangerous.”

It named insufficient monitoring of privileged accounts.

Database monitoring limited to payment-card tables while other PII tables went unwatched.

No server whitelisting or hardening.

Selective encryption limited to PCI DSS scope, leaving passport numbers unencrypted.

An organization with an acquired reservation system might have a comparable inheritance problem.

An organization with a clean-room migration, separate privileged access, full database monitoring and no stored passport data does not have the same path.

Merely because both companies have “customer data” in a box.

A similar diagram is not a similar trust boundary.

The transferable conditions are the administrative privileges, the monitored tables, your system lineage, the reachable data, the encryption treatment, and the consequences after access.

Not whether both companies have vendors and databases, which narrows it down to most of the economy.

4. “But Initial Access Is the Thing We Need to Stop.”

Of course initial access matters.

It is just not the whole incident, which is inconvenient if the desired conclusion fits on a sticker.

Target had an initial vendor-credential path.

A later segmentation failure.

Point-of-sale reach.

Card-data theft.

An unacted-on FireEye alert.

Removing any one of those conditions could have changed what happened after your credential was abused.

A threat model recording only “vendor compromise” has described the first door and ignored the rooms behind it.

OPM makes the same mistake visible differently.

The public record often says “the OPM breach.” It documents an earlier background-investigation-system compromise flagged in March 2014, and a separate intrusion beginning 7 May 2014.

The second used credentials stolen from KeyPoint Government Solutions, a contractor.

It was not discovered until 15 April 2015, during remediation work prompted by the first incident.

The June 2015 disclosure covered personnel records.

The July disclosure covered roughly 21.5 million background-investigation records, fingerprint sets included.

Those populations overlap, which is why the press totals and the agency totals never agreed.

The House report named absent multifactor authentication on remote access, and no network intrusion-detection sensors.

Einstein sensors arrived after the first incident, and a demonstration of the new tooling surfaced the second.

There is no useful local lesson called “don’t be OPM.”

There are several.

Distinguish incidents.

Map contractor identity paths.

Map your data each path reaches.

Document dwell time.

Ask which detection mechanism can actually see and escalate the next phase.

5. “But History Tells Us Which Controls Won.”

History tells you which assumptions failed hard enough to force institutions and methods to change.

More useful than a leaderboard of products.

The Morris worm used three mechanisms.

A sendmail debug hole.

A finger buffer overflow.

And unauthenticated rsh or rexec trust between hosts.

The last was a design assumption.

Hosts trusted other hosts because the people who could reach them were supposedly few and known.

Kerckhoffs’s principle had made the opposing argument a century earlier: security should depend on a secret key, not secret design or restricted knowledge.

Your incident did not establish that every later environment needs a Unix trust control from 1988.

It exposed a coordination problem.

No affected institution could see your incident across independently administered systems, compare information, coordinate a fix, and publish guidance alone.

DARPA established CERT/CC at Carnegie Mellon in November 1988 as the first standing coordination organization of its kind.

A historical lesson at the institutional layer.

A shared incident path may require a response function above any one victim.

The next threshold changed a different assumption.

Zeus, first observed in 2007, was a commercial credential-stealing kit; its author claimed to retire in 2010 and sold it to a rival’s creator.

Conficker reached an estimated ten million-plus infected machines across more than 190 countries by January 2009.

Attackers had economic incentives to maintain access, rather than merely be noticed.

Defence responded at scale.

Unique malware samples more than tripled across the late 1990s.

By 2007, signature-based products’ zero-day detection rates had fallen to 20-30%, from 40-50% the previous year.

The lesson isn’t “buy the antivirus control that won.”

It is that a control built for a changing attacker economy has limits, and those limits become a new threat-model input.

6. “But Threat Modeling Can Always Invent Another Scenario.”

Yes.

A bad threat model can invent attackers who teleport through a password reset, then write “high” in a red cell.

That is not an argument against threat modelling.

It is an argument against administrative theatre.

The discipline is to use an incident to constrain the question.

State the original access path.

The privileges it gained.

Every trust boundary crossed.

The dwell time and the detection point.

Your control that was missing, ineffective or bypassed.

Then compare each field with your local data flow.

Stuxnet is the historical version of this exercise.

It did not prove that every industrial system faced the same actor or the same payload.

It combined four Windows zero-day vulnerabilities, non-public knowledge of Siemens PLC programming, knowledge of the Natanz centrifuge cascade, and a USB-borne jump across an air gap.

It destroyed roughly a thousand centrifuges while presenting falsified sensor data to operators.

The resulting change was specific.

Physical isolation was not a categorical defence against a sufficiently resourced network-borne attacker.

Industrial control systems had to be threat-modelled as reachable rather than assumed isolated.

A bounded model correction.

Not a decree that your office printer acquired a national-security threat profile because somebody attended a Stuxnet presentation.

7. “But Leadership Needs a Simple Lesson.”

Leadership does need a simple lesson.

“Copy the famous control” is simple in the way a broken smoke alarm is simple.

It has removed the part that matters.

Give leadership a short decision record instead.

Name the source incident, and date each incident fact.

Name the original asset, entry path, privilege, trust boundary, dwell time, missing control and consequence.

Beside each, record the local comparable, or state that none exists.

Then name the candidate control, its layer, its owner, its feasibility, and the local consequence it is meant to reduce.

That is how a famous breach becomes useful in a review meeting.

Target justifies a question about external identity assurance and segmentation.

Equifax justifies questions about inventory, patch verification, inspection coverage and detection.

Marriott justifies questions about inherited systems, privileged monitoring, data classification and encryption coverage.

OPM justifies questions about contractor credentials and separate incident paths.

Not four copies of one control.

Four sets of testable questions.

8. No, This Does Not Mean Incident History Is Anecdotal Decoration.

The opposite mistake is just as foolish.

A public incident gives you an observed path, a dated record, and an account of assumptions that did not survive contact with production.

Substantially better than saying “an attacker might somehow get in,” and leaving the rest to a risk register with strong opinions about colours.

History also supplies the durable pattern.

Operation Aurora, disclosed in January 2010, led Google to build BeyondCorp around per-request identity and device verification instead of privileged VPN or perimeter access.

John Kindervag popularized “Zero Trust” in 2010.

Lockheed Martin published the Cyber Kill Chain in 2011.

Mandiant’s February 2013 APT1 report attributed years of espionage to a specific Chinese military unit, and MITRE released the first ATT&CK version that year.

NIST SP 800-207 formalized the pattern in August 2020.

Network location does not grant implicit trust.

Executive Order 14028 and OMB M-22-09 then directed federal adoption and implementation goals through fiscal year 2024.

That sequence is evidence that perimeter strength and isolation are necessary and not sufficient, once a resident attacker is plausible.

But history provides the changed assumption.

It does not decide the placement of your boundary, the data it must protect, or the operational owner who has to respond when it fails.

Evidence is not an architecture.

9. What You Should Actually Do

Use breach reports to seed abuse cases. For each report, record the initial access path, the earliest confirmed unauthorized-access date, the detection date, dwell time, later movement, exposed asset, missing or ineffective control, and source date.

Do not collapse all of that into “vendor breach” or “patching breach.”

Compare those conditions with local facts. Data flows.

Vendor and contractor privileges.

Authentication boundaries.

Network reachability.

Administrative paths.

Monitoring coverage.

Encryption treatment.

And the consequence if the path succeeds.

The comparison should say where your system matches the incident, and where it does not.

Model alternate paths. If a control blocks the reported entry path, ask what happens after a different credential, a different exposed service, or a resident privileged identity reaches the next boundary.

That is where control selection becomes local rather than commemorative.

Choose controls on local consequence and feasibility. Assign an owner to the control layer, and to the detection or response step it requires.

Date every incident fact. Re-check final reports, regulator notices and later disclosures before publication or a major decision.

Marriott’s record moved from up to 500 million guest records, to less than 383 million, to 339 million in the ICO’s October 2020 notice.

Yahoo’s 2013 count moved from roughly 1 billion accounts in its December 2016 disclosure to all 3 billion in October 2017.

Headlines are early telemetry.

They aren’t immutable evidence.

10. The Model Is Not Complicated.

A breach report tells you what happened there. A threat model decides what matters here.

Use your report.

Read the final record.

Preserve the dates.

Extract the path rather than the slogan.

Test the path against the assets, privileges, boundaries, detection and consequences.

Select controls at the layer where your path actually needs interrupting.

Famous breaches are valuable because they show that assumptions break.

Security history is valuable because it shows what changed after they broke.

Neither relieves you of the irritating responsibility to understand your own system.

That responsibility is the threat model.