Five Security Controls That Would Have Changed 15 Breaches

Short read

This post covers five security controls that would have changed the outcome of fifteen major breaches, including Target, Equifax, MOVEit, Storm-0558 and Change Healthcare. They are MFA on every path, knowing what the internet can see, patching by exploitation rather than score, someone looking every hour, and keeping the logs you'll need.

You'll see what went wrong in each case, how urgentic BLUE investigates every alert around the clock, and a simple test for your next board conversation: could you prove each control works today, with evidence rather than a policy document?

Five security controls would have changed the outcome of fifteen of the biggest breaches of the last decade. We went back through public investigations of attacks including Target, Equifax, MOVEit, Storm-0558 and Change Healthcare, and the same short list kept coming up. None of these controls is exotic. None needs a new platform. Each one needs doing, and proving, every day.

None of the organisations below were urgentic clients. The point isn't hindsight. It's that the failures were ordinary, which means the fixes are too.

1. MFA on every path, proven daily

Most organisations can say they "have MFA". Far fewer can show a live list of every path into the business that still accepts a password alone: the old VPN profile, the remote access portal set up for a project, the test tenant nobody remembers.

Change Healthcare is the clearest example. In his testimony to the US Senate Finance Committee, UnitedHealth Group's chief executive said attackers used compromised credentials on 12 February 2024 to get into a Citrix portal that didn't have multi-factor authentication. Colonial Pipeline's attackers also came in through a legacy VPN profile that didn't require a one-time passcode, according to Mandiant's congressional testimony.

The control isn't "turn on MFA". It's checking every day that nothing has slipped through. We covered this in more depth in why so many breaches still start with a password.

2. Know what the internet can see

You can't patch, test or watch a system you don't know you expose. A US Senate subcommittee investigation into Equifax found the company didn't patch its vulnerable system for months partly because it lacked a comprehensive inventory of its IT assets, so it couldn't find what needed fixing.

MOVEit shows how little time that leaves. Progress Software announced the MOVEit Transfer vulnerability (CVE-2023-34362) on 31 May 2023, but Mandiant found the earliest evidence of exploitation on 27 May, four days before anyone outside the attackers knew there was a problem. The joint CISA and FBI advisory says internet-facing MOVEit Transfer applications were hit with a web shell and used to steal data. In some cases, Mandiant saw data stolen within minutes of the web shell going in.

When there's no patch yet, the organisations that cope best are the ones that already know exactly which of their systems are exposed, so they can isolate, restrict or watch them the moment an advisory lands.

3. Patch by exploitation, not by score

Every vulnerability scanner produces a long list sorted by severity score. Attackers don't work from that list. They work from what's known to be exploitable and what they can reach.

Equifax is the textbook case. According to the US House Oversight Committee report, the Apache Struts vulnerability was disclosed and patched on 7 March 2017, and the US Computer Emergency Readiness Team alerted Equifax the next day. Equifax's own policy said critical patches should go in within 48 hours. Attackers got in on 13 May, more than two months later, through a system that hadn't been patched, and went undetected for 76 days.

The fix is a different ordering: vulnerabilities that are being actively exploited, on systems the internet can reach, go to the top of the queue, whatever their score. Public lists such as CISA's Known Exploited Vulnerabilities catalogue make that easier to do.

4. Someone looking, every hour

This is the control that appears most often in the post-mortems, because in breach after breach the signal was there and nobody acted on it in time.

At Target in 2013, the US Senate Commerce Committee's analysis found that malware detection alerts fired as the attackers installed their tools between 30 November and 3 December. Target only learned of the breach when the US Department of Justice contacted it on 12 December. At Change Healthcare, the ransomware wasn't deployed until 21 February 2024, nine days after the attackers first got in. That's nine days of activity that could have been spotted.

Attackers know when people aren't watching. MOVEit exploitation began on the Saturday of a US holiday weekend. Alerts that wait in a queue until Monday morning give attackers a head start. We've written before about what an alert costs before anyone looks at it and how alert fatigue wears teams down.

This is the control we built urgentic BLUE for. Its AI agents investigate every alert across Microsoft 365, Entra and Defender, 24 hours a day, with a median of under three minutes from alert to investigation. You can see how it works on our platform page.

5. Keep the logs you'll need

Logs are dull until the day you need them, and then nothing else matters. If the evidence wasn't recorded, or was deleted after a few days, no amount of expertise can reconstruct what happened.

Storm-0558 is the striking example. In 2023, attackers forged authentication tokens and read Microsoft Exchange Online mailboxes across 22 organisations. According to the US Cyber Safety Review Board, the US State Department was the first victim to detect it, using a custom alert built on the MailItemsAccessed log. That log was only available because State had bought a licence with premium audit logging, which the Board said few, if any, other victims had. State then took the alert seriously, even though the same rule had produced false positives before.

Two lessons sit in that story. Make sure the logs that matter are switched on and kept long enough to investigate. And make sure someone is actually reading them.

Proving it, not just having it

Put the five side by side and a pattern appears. These organisations mostly had policies. Equifax had a 48-hour patching rule. State's peers could have bought the same logging. Target had malware detection in place. What was missing was daily proof that the controls were working.

A useful exercise for your next board or planning conversation is to take each of the five and ask a simple question: could we prove this today, with evidence, not a policy document? Where the answer is no, that's where to start.