Learning points from the "entirely preventable" Equifax data breach
On Monday, the US Federal Trade Commission (FTC) agreed a settlement of up to $700m for a class action brought against Equifax. This is in addition to the £500k fine levied by the UK Information Commissioner's Office, which was the pre-GDPR maximum. Under GDPR, the fine might be closer to $120m, or 4% of Equifax's $3bn revenue in 2017.
The firm's CEO, CIO and Chief Security Officer also resigned or retired following the breach, and the CIO was convicted in March 2019 of insider trading for exercising options prior to it's public disclosure.
How did it happen?
In July 2017, Equifax discovered that attackers had been extracting information for about 76 days using a vulnerability in the Equifax Automated Consumer Interview System (ACIS), an internet-facing web application. It was a Remote Code Execution vulnerability in the Apache Struts framework used by the application (formally CVE-2017-5638), which enabled attackers to run arbitrary commands with the authority of the ACIS application.
Ultimately this allowed the attackers to access 47 separate databases and exfiltrate personal records of 147 million consumers, many of whom had no direct relationship with Equifax at all.
What can we learn?
1. You need a working patch & release procedure for every system
You need a joined-up process for addressing security vulnerabities in every interface you expose. A major failing in Equifax's case was that their security team highlighted the vulnerability but it was not acted upon, and the security team did not follow up to check that it had happened. This means you need reliable processes to identify vulnerabilities, patch systems and dependencies, re-test the application, deploy it, and confirm that the vulnerability has been closed. And, those processes need to be fast, to minimise the window of opportunity available to attackers.
This is easier said than done. ACIS was originally built in the 1980s, and internal Equifax documents referred to it as "archaic" and "antiquated technology". Legacy applications are more likely to have extensive technical debt than automated regression tests, fast automated release processes, or the top-notch engineers that would implement them.
Equifax's patch management policy specified that fixes should be applied within 48 hours, but the responsible person didn't do it (Equifax blamed and fired a single person), and the subsequent automated scan that would identify this didn't work. To give an idea of the timeline, the vulnerability was identified in March 2019 and exploited between May and July.
Maintaining legacy applications is expensive but not optional. Large, long-established companies tend to accumulate interfaces and legacy application code, running on old servers and operating systems; newer firms tend to buy or subscribe rather than build, shifting the maintenance obligation to vendors.
How do we do it at Safelink? We have a fully automated test and release process, reducing our patch and release cycle to under an hour for all of our global deployments (assuming no functional change is anticipated).
2. Encrypt your data
The attackers were able to access more than 47 databases containing unencrypted consumer credit data and found administrative passwords in plain text files, enabling them to expand their trawl even more widely.
It's unsurprising that a decades-old system, whose origins pre-dated modern norms and regulations around data security, would not have effective encryption in place. But even if the budget and intent existed at Equifax, it would have been very difficult to do correctly. The standard approach to encrypting data before it's stored is to use a single key or family of keys that are known to or available to the application software, or to apply disk-level encryption also with a single key. This stands to reason, as the application itself needs to be able to encrypt and decrypt data on demand. But, how does the application obtain the keys it needs? Whether these are stored on disk, or in an HSM, or in a separate key management facility, they are still available to the application in some form or other, and an attacker exploiting a Remote Code Execution vulnerability will be able to gain access to those keys in the same way as the application would. As such, this pattern of application level encryption would not have helped at all.
How do we do it at Safelink? We take a unique (and justifiably paranoid) approach of using different keys for each room (or workspace) created within Safelink, we encrypt pretty much everything, and we don't store the keys ourselves. Authorised users provide the keys needed to access their data on-demand (as a push from the user rather than a pull from the application), and we go to great lengths to not retain the keys at all. Our application code simply can't access whatever it wants whenever it wants, and nor could an attacker who bypassed our other defences.
3. Segment your network and monitor for intruders
Once the attackers had access to ACIS servers, they were able to gain access to other parts of the network, including unrelated databases. They were ultimately able to exfiltrate the personal information of over one hundred million people. But, if someone does make it through, make sure you're running a properly configured intrusion detection system so that you detect it quickly, rather than after 76 days of unfettered access.
How do we do it at Safelink? It's not too complicated, we segment our networks and each individual application component, and run IDS within each segment.
The FTC and others describe Equifax's the breach as "entirely preventable", and it certainly involved a sequence of rookie mistakes. But for a business as large and established as Equifax, upgrading decades-old applications to use modern security and deployment practices is far from straightforward, technically at least. Perhaps the economic argument is now clear.