Equifax’s breach in 2017 was all the information security community could talk about, and it was a household name. This was because of how many US citizens it impacted. It really was a catastrophe for the company’s reputation and put them in the hot seat with consumers. It wasn’t just the scope of the data, it was also because people had no control – a lot of people simply felt powerless. If Equifax can’t get it right, what hope does anyone else have? And why didn’t they do more to protect people’s data?
Well, the sad truth is – they did! Equifax actually cared quite a lot about information security and spent a lot of money focused on protecting their sites. Sure, perhaps they could have done more. And I’m sure gaps existed, but one gap that they didn’t have knowledge of was the vulnerability in question. Equifax did know of the vulnerability in Apache Struts that eventually lead to their downfall. “So, what the heck?” you may be asking yourself.
Equifax did have a scanner that was set to scan all of their known infrastructure looking for the Apache Struts vulnerability in question. When they found a vulnerable machine they would immediately patch it. Sounds like this should have been a slam dunk then. Or, maybe too close for comfort and maybe more controls should have been in place at first to limit the damage potential. But at least they had their act together with scanning and patching.
The trick here is that only scanned their KNOWN infrastructure. If a machine was vulnerable and not on the list of machines that they knew about, it wouldn’t get scanned. One box that was likely used just for testing purposes was left, unpatched and vulnerable. That’s all it took.
The details are laid out in the FTC’s document FEDERAL TRADE COMMISSION, Plaintiff, v. EQUIFAX INC., Defendant. case findings and the two important sections can be seen below:
“B. Defendant’s reliance on an automated vulnerability scanner – without any other compensating controls to ensure that the vulnerability had been fully addressed – further contributed to Defendant’s failure to patch the vulnerability. Although many companies use automated vulnerability scanners, Defendant (1) did not maintain an accurate inventory of public facing technology assets running Apache Struts (and therefore did not know where the scanner needed to run) and (2) relied on a scanner that was not configured to search through all potentially vulnerable public facing websites.“
“17. On or about March 15, 2017, Defendant performed an automated vulnerability scan intended to search for vulnerable instances of Apache Struts that remained on Defendant’s network. But Defendant used a scanner that was not configured to correctly search all of Defendant’s potentially vulnerable assets. As a result, the automated scanner did not identify any systems vulnerable to 2017-CVE5638 and the ACIS Dispute Portal remained unpatched.”
Without a complete asset inventory – the intrusion led to millions of dollars in losses. In addition to countless hours of lost human resource time, and who knows what other downstream effects it had for Equifax and their customers. It tarnished the reputation of credit monitoring services and has led to a rash of public hearings.
It all came down to not knowing their assets.
With that in mind, it’s easy to see how asset management is the root of a good scanning and patching program. Without it, you cannot scan the complete list of hosts in your environment to know that you should patch them. At that point, it’s just a matter of time before someone finds said asset and what they can get out of exploiting said asset. In the case of Equifax, it gave them everything they wanted. Your mileage may vary.
It’s hard to blame Equifax entirely because they were just the canary in the coal mine in a lot of ways. They showed us how important this problem really is. But now that the community knows this is the cause of one of the most historic breaches in history, we can no longer rely on ignorance. You cannot secure assets that you do not know.
