8 October 2017
On October 3rd, 2017 a hearing titled “Oversight of the Equifax Data Breach: Answers for Consumers.” was conducted by the Subcommittee on Digital Commerce and Consumer Protection of Committee on Energy and Commerce of the 115 U.S. congress.
Sarah Buhr’s report “Former Equifax CEO says breach boiled down to one person not doing their job” posted on October 3rd, 2017 on TechCrunch gives a good summary of the hearing results.
And a surprisingly plain cause for the data breach:
‘“The human error was that the individual who’s responsible for communicating in the organization to apply the patch, did not,” Smith, who did not name this individual, told the committee.’
To be honest, this sounds somewhat too easy.
In the witness statement of Mr. Smith one reads:
 “On March 9, Equifax disseminated the U.S. CERT notification internally by email 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.”
 “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. Equifax’s efforts undertaken in March 2017 did not identify any versions of Apache Struts that were subject to this vulnerability, and the vulnerability remained in an Equifax web application much longer than it should have.”
 “The company knows, however, that it was this unpatched vulnerability that allowed hackers to access personal identifying information.”
From  we learn that Equifax has a good vulnerability management process in place.
From  and  we learn that Equifax’s vulnerability scanner did not find the systems with the vulnerable version installed, although the company knew that the vulnerable Apache Struts framework was installed on some systems.
There are many reasons for this. Just two examples:
- Vulnerability scanners must be updated regularly to keep pace with the threat market. But there is often a gap between the release of a scanner update and the disclosure of a vulnerability.
- Even up-to-date vulnerability scanners provide no 100% detection. In addition, the results are often somewhat puzzling.
From my point of view, the trust in the results of the vulnerability scanners is the cause for the data breach. Because of the gap between the release of a scanner update and the disclosure of a vulnerability an up-to-date asset repository, at least for the systems facing the internet, is of desperate need for fast identification of vulnerable systems.
The reduction to a human error is just too plain. This sounds more like a systematic error. And provides some interesting food for thought for the next week.
Have a great week.