Equifax: A Case Study in Vulnerability Management

Justin Hall

By now you’ve surely heard about the Equifax breach. (Of course I have, Justin, and don’t call me Shirley.)

I was actually quite surprised when the details of this breach were announced; specifically, that the initial point of entry into the Equifax network was not phishing. Instead, the attackers found and exploited a vulnerability in a public-facing web application framework. This allowed them to take control of the server on which this software was running, and use it as an entry point to the internal network and, eventually, to 143 million PII records.

This certainly calls to mind the old adage “the attackers only have to be lucky once – you have to be lucky every time.”

Equifax used Apache Struts – the web application framework in question – as a part of its online disputes application. US-CERT, a division of the federal government charged with helping Americans protect their data from security threats, notified Equifax about a serious vulnerability in Struts. The Equifax information security team passed this notification to the IT operations teams responsible for patching, as described in the Congressional testimony from Equifax CEO Richard Smith:

“On March 9, Equifax disseminated the U.S. CERT notification internally by e-mail requesting that applicable personnel responsible for an Apache Struts installation upgrade their software. Consistent with Equifax’s patching policy, the Equifax security department required that patching occur within a 48 hour time period. We now know that the vulnerable version of Apache Struts within Equifax was not identified or patched in response to the internal March 9 notification to information technology personnel.”

In addition, he notes:

“On March 15, Equifax’s information security department also ran scans that should have identified any systems that were vulnerable to the Apache Struts issue identified by U.S. CERT. Unfortunately, however, the scans did not identify the Apache Struts vulnerability.”

So here we have two breakdowns in the system: a failure to patch, and a failure to identify the application as vulnerable.

It’s a great reminder of why we consider the discipline of vulnerability management to involve much more than simple vulnerability scanning or patching. We see it as a checks-and-balances, in a way, to the IT operations teams that manage the computing environment. A complete practice would include:
 
  • An authorized software list, defining which applications are permitted for use in the organization’s computing environment
  • An effort to remove unauthorized software not present on this list from the environment on a regular basis
  • Notifications from vendors responsible for software on this list concerning new vulnerabilities
  • Self-guided research from internal security staff to find undiscovered or undocumented vulnerabilities
  • Ongoing vulnerability scans to find missing patches, configuration flaws, and design weaknesses  in all network nodes – servers, workstations, network devices, mobile devices, peripherals (such as cameras, networked printers, card readers, etc.)
  • Manual identification of serious vulnerabilities that may not be picked up by vulnerability scans, researchers, penetration testers, or a red team
  • Regular reports of vulnerabilities and remediation guidance to those responsible for system administration
This kind of formal practice is not trivial to build, but it can be done over time in a series of phases. And there’s still no guarantee you won’t miss something, as Equifax did. And even if your hygiene is perfect, the attackers could still try to phish you.

It’s not hopeless – our ultimate goal is to make attacking our organization so taxing and costly for the attacker that they give up and move on to another target; and if they are successful, identifying the breach and responding effectively. Equifax may not have been lucky this time; here’s hoping we can learn from their mistakes.
comments powered by Disqus