The Equifax Series: Part 1-How the Equifax Breach Happened

By: Jason A. Greene, CISO

The Equifax breach was so significant that I wanted to dedicate a short series to exploring its different facets. In the first part of the series, we’ll take a look at how the breach happened.

Part 1: How the Equifax Breach Happened

This is a horrible, no good, very bad breach. Any compromise of personal information should be taken seriously, but there is special cause for alarm right now. Here’s why:

The sheer size of the affected population. Nearly half of all Americans, plus many Brits and Canadians, had their sensitive financial data exposed to cyber criminals.

The length of time before the breach notification. According to Equifax, hackers had access to a treasure trove of personal data since mid-May, but even after discovering the breach on July 29, the company took another 40 days to notify the public.

The highly sensitive nature of the exposed data. The exposed data wasn’t just credit card numbers, which are easy to replace. It contained sensitive information, such as names, social security numbers, birth dates, addresses, and driver’s license numbers, which can’t be easily replaced. This is basically everything a hacker would need to steal your identity.

The few remedies consumers have for protection. The credit monitoring services aren’t really designed to prevent identity theft, but there are some steps you can take now to mitigate potential damage.

Equifax is one of the world’s three largest consumer credit reporting bureaus, and its business model centers on maintaining extensive consumer records that businesses can then use to determine how risky it is to loan an individual money or to extend a line of credit. Unlike with lenders, consumers don’t usually elect to send their personal and financial information to credit monitoring companies such as Equifax. Instead, lenders often report consumer information from loan applications and loan activity to these companies, which they in turn profit from. This means that you, the consumer, are actually the commodity.

According to Equifax, the breach occurred in mid-May 2017 and continued until the company discovered it on July 29. Equifax Chairman and CEO Rick Smith stated in a video released by the company that Equifax “acted immediately to stop the intrusion” and that it is cooperating with authorities.

The breach affected 143 million American consumers (including mine), as well as many British and Canadian citizens. This list may continue to grow in the coming weeks.

So how does the Equifax hack stack up to other major data breaches? Just for comparison, 77 million Sony customers were affected by a breach in 2011 that resulted in the loss of credit card numbers, customer names, and home addresses. 38 million Adobe accounts and credit card information were compromised in 2013. JP Morgan Chase was hacked in 2014 resulting in a breach that affected 76 million individuals and 7 million businesses. By late 2014, the health insurance company Anthem was compromised in a breach that resulted in the loss of 78 million customer and employee social security numbers and addresses.

What is inexplicable at the moment is how the company took an additional forty days after discovery of the breach to notify the public. Most state and federal data breach notification statutes do not provide a set time after incident discovery for notification; rather, they require that a company notify affected persons as expediently as possible, without unreasonable delay, or both.

I’m not about to defend Equifax here, but the CEO’s statements on the company’s current cooperation with law enforcement authorities may shed some insight on the reason for the substantial delay. Many statutes require companies to notify law enforcement before or at the time of public notification. And cooperation with law enforcement is widely interpreted under most statutes, if not explicitly stated, to be reasonable if notification would impede an official investigation.

There are also some technical reasons a company may want to delay notification after discovery of an incident. Chief among them is that if the unauthorized access is not terminated immediately, a public notification could tip off the hackers that their activities are being monitored and they could become destructive and exacerbate the harm before their access is terminated.

It’s not uncommon for hackers to establish additional backdoors to a computer network once they have gained a foothold. They do this just in case a network change or some other event causes them to lose the initial access. So, if a company like Equifax discovers a breach, they may have to employ a forensic investigation team to determine if the hackers have additional accesses into the network.

I heard earlier this week that Equifax called in the cybersecurity firm, Mandiant, to help with the incident response. Mandiant tends to be the company called upon when advanced persistent threat actors are involved. An advanced persistent threat actor, or APT, is a well-resourced foreign government or their proxy. Russia, China, North Korea, and Iran are among the usual suspects. This is pure speculation and Mandiant may have been hired through a pre-existing retainer agreement or due to the sheer severity of the breach.

However, based on early reports, there is ample reason to believe it didn’t take the skills and resources of an APT to breach Equifax. Though an article published on Quartz.com first suggested the hackers used a zero-day (a previously undiscovered or undisclosed vulnerability) to exploit the Apache Struts Web Framework used by Equifax, this claim was quickly disputed by Apache in a blog post that revealed the breach was likely the result of hackers exploiting an unpatched Equifax server.

So, there you have it—the breach may have been the result of poor Equifax security practices. More and more reporting on security practices at Equifax is likely to come out over the following days and weeks, so stay tuned!

In Part 2 of The Equifax Series I’ll use Equifax as a case study in what not to do during incident response.