The Equifax breach: lessons for any company holding customer data
A breakdown of the Equifax incident and practical takeaways for executives whose companies collect and store personal data.
In early September 2017 one of the largest personal data breaches in history became public. The US credit bureau Equifax disclosed that attackers had accessed data on roughly 143 million people - names, social security numbers, dates of birth, addresses, and in some cases driving licence and credit card numbers. The attack vector was a vulnerability in a web application for which a patch had been available since March, several months before the breach.
I am writing about this not because it is an American story. I am writing about it because the pattern is fully reproducible in any company that accumulates personal data and has not built basic vulnerability management processes.
What happened technically
The attack exploited a vulnerability in Apache Struts - a widely used Java web application framework. The vulnerability was publicly disclosed and patched in March 2017. Equifax did not apply the patch. In May, attackers used this vulnerability to gain access to the systems. The breach continued for roughly 76 days before it was detected.
Three elements made this possible: an unpatched vulnerability in a well-known component, no sufficiently rapid detection of anomalous activity, and insufficient data segmentation that would have limited the breach volume.
This was not an exotic zero-day attack that is difficult to defend against. This was exploitation of a known vulnerability for which a patch had existed for months.
Why this is relevant regardless of geography
Companies accumulate more and more personal data - that is the reality of any business that deals with individual customers. Data protection legislation establishes liability for protecting it, but formal compliance with a regulator does not by itself mean genuine security.
There are a few recurring patterns I see:
An outdated stack without regular updates. Web application components, libraries and frameworks are rarely updated because "everything works". That means an accumulated backlog of vulnerabilities.
No anomalous activity monitoring. Logging is set up, but nobody looks at anomalies in real time. A breach is discovered after the fact.
Insufficient segmentation. The database containing customer personal data is accessible to a wide range of internal systems. Compromising one entry point gives the attacker access to everything.
What this means practically
Equifax was not a company with a small IT budget and incompetent staff. It is a large company with serious infrastructure. And an unpatched vulnerability over several months became the cause of the largest breach in credit bureau history.
This means it is not only about resources - it is about processes. Specifically: a vulnerability management process that includes tracking public CVEs for components in use, prioritising and applying patches in a timely way, and verifying that patches have actually been applied.
Questions for any executive
If your company stores personal data on customers:
- Do we have a process for tracking vulnerabilities in the components we use - not a one-off audit, but ongoing monitoring?
- What is our average time between a critical vulnerability being published and it being patched in our systems?
- Do we have anomalous activity monitoring for systems containing personal data?
- How well is access segmented - if one service is compromised, what exactly becomes accessible?
- Do we have an incident response plan for a data breach - including mandatory notification of data subjects and the regulator?
The Equifax breach will end up in textbooks as a case study in the cost of process negligence. For any executive responsible for customer data, it is a prompt for an honest audit of your own processes.