Equifax Autopsy: What Have We Learned?

On September 7th 2017 Equifax, one of the largest credit agencies in the world, announced that they had become the victim of a major breach resulting in over 150 million records being stolen. So, what have we learned? Check out this blog, and our complimentary podcast for our insights.

The day after Equifax’s announcement, their share price plummeted 13.7% and after two weeks it had fallen from 142.72 to 92.98 (34.58%).Equifax confirmed that the breach was a result of the Apache Struts vulnerability, assigned CVE-2017-5638 , which was disclosed on March 6th 2017. They also discovered on 29th July that they had been breached on  said they were breached on 14th May. A patch for CVE-2017-5638, which would have prevented the breach, was made available by the Apache Struts Project early March.

On 3rd October 2017, in testimony before a United States House Subcommittee on Consumer Protection, recently retired Equifax CEO Rick Smith blamed a single employee for the company’s failure to deploy the critical software patch. It was announced in the House Committee report that the device simply had an expired certificate, which had expired 19 months earlier.

Equifax have been widely criticised for their handling of the breach, particularly the time taken to identify the breach and failings in communicating with affected consumers. Equifax call centers were unable to deal with the volume of calls received after the breach notification and social media teams repeatedly tweeted a link to a spoofed website, rather than the official breach notification site.

To add insult to injury, customers who accepted the identity protection product Equifax offered in response waved any right to pursue litigation against the company. However New York Attorney General Eric Schneiderman stated “This language is unacceptable and unenforceable” and demanded Equifax remove the clause.

What went wrong?

Applying security patches quickly and effectively is critical when defending systems from attackers. Cyber criminals will often scan large portions of the Internet looking for unpatched systems, exploiting any that are found.

In the case of Equifax, a single employee was blamed for the missing patch. However, relying on a single, potentially fallible human to deploy patches, especially in an organisation responsible for millions of consumers’ data, is reckless.

As Equifax have shown, mistakes can and will happen. The security of your organisation should not rest with one individual. Patches should be applied quickly and their deployment checked and verified by security staff.

Automated scanning tools can help identify missing patches and other security holes. Unfortunately, they are not a silver bullet: they can and do produce false-positive results; they can also produce false-negative results.

The output of automated scanning tools should always be manually verified to ensure that false-positives are avoided. False-negatives are harder to detect, however careful review of applied patches would have identified the false-negative in this scenario.

Equifax chose to deploy a new website to host their breach notification. By not hosting the breach notification on the trusted Equifax domain, they opened themselves up to impersonation and phishing attacks. This is exactly what happened when a fake domain, which was incredibly similar to the legitimate domain, was registered.

The fake domain was so convincing that the Equifax-verified Twitter account began tweeting links to it to concerned customers. Luckily, this fake domain was a parody of the Equifax official site, rather than a malicious phishing site.

Should the worst happen, it’s important to have a detailed data breach plan in place before a major incident is discovered. This will dramatically reduce the risk of mistakes being made during the first few days after a breach is discovered. This plan should include details of organisations and individuals who must be notified, plans to secure customer and company data, and plans for notifying customers.

What have we learned

• The time from vulnerability disclosure to patch being applied is critical. Had patches been applied in a timely fashion, the risk of a breach would have been reduced.
• The output from vulnerability scanners must be verified. False-positives are common, but missing a false-negative can be catastrophic. Automated scanning tools are not fallible.
• In the event of a breach, information should be communicated via established, trusted, channels. Creating a new domain to host your notification site increases the risk of impersonation and phishing attacks. Employees, especially those communicating with the public, should have information about the breach clearly communicated to them, this includes all website links and telephone numbers to be provided to the public. A good incident response plan should include all these details.

(This blog was originally published on 9th October 2017 and has been updated to reflect information that has come out post publication)

For more information about securing your business and avoiding a data breach, contact us here.