On March 8, 2017, the U.S. Department of Homeland Security, Computer Emergency Readiness Team (“U.S. CERT”) sent Equifax and many others a notice of the need to patch a particular vulnerability in certain versions of software…. Equifax used that software, which is called “Apache Struts,” in its online disputes portal, a website where consumers can dispute items on their credit report.
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.
~ Excerpts from “Prepared Testimony of Richard F. Smith before the U.S. House Committee on Energy and Commerce Subcommittee on Digital Commerce and Consumer Protection”
Reading between the lines of ex-CEO Smith’s prepared statement, it appears that the chain of events leading to the Equifax breach was a combination of human error and technological failures.
“There was a protocol in place to fix the software flaw that led to Equifax being breached. It wasn't followed,” Smith said in testimony on October 3rd. "The human error was, the individual who was responsible for communicating the patch in the organization, did not," he said. “A few days later, there was a scan of the system, which also didn't reveal the vulnerability.”
Smith hasn’t elaborated so far on what was used to “scan” the Equifax systems, but given its failure to identify a known open source vulnerability, one could assume that it wasn’t a dedicated open source vulnerability management solution (or if it was, Equifax should seriously consider asking for its money back). It’s more likely that Equifax was using some combination of traditional SAST and DAST tools to protect itself.
SAST, DAST, and Open Source Vulnerability Management
The vast majority of security attacks target software applications. Not surprisingly, there is an array of application security tools on the market to help companies address security risks, varying in both approach and coverage. Traditional application security tools — Dynamic Analysis Security Testing (DAST) and Static Analysis Security Testing (SAST) – are very effective in finding bugs in the application code internal developers write. However, they aren’t as effective in identifying open source software vulnerabilities. Given that open source is an essential component in application development worldwide, effective open source vulnerability management is imperative.
Last year, Black Duck’s Center for Open Source Research & Innovation (COSRI) analyzed more than 1,000 applications that were audited as part of Merger & Acquisition transactions. The COSRI audit analysis found that 96% of the applications contained open source software and more than 60% of those applications contained known open source security vulnerabilities.
Are Vulnerabilities Found By SAST and DAST Tools?
Since 2004, more than 74,000 vulnerabilities have been disclosed by NVD, but only a handful of those were found by SAST and DAST tools. SAST is effective at finding many common vulnerabilities such as cross-site scripting, SQL injections, and buffer overflow vulnerabilities, but according to the National Security Agency (NSA) the average SAST tool can only find 14% of the problems in an application. Similarly, while a valuable tool for web application testing, especially for custom-built applications, DAST is weak at finding vulnerabilities entering code via open source.
The most effective way for companies to gain visibility into and control over open source in the applications and websites is to use automated processes to scan their applications for open source, create an inventory of their open source components and then map that open source to open source vulnerability databases. This enables them to identify any known vulnerabilities and then monitor the inventory for any newly reported open source vulnerabilities.
Where Are Your Vulnerability Identification Gaps
Traditional approaches to application security, involving only static and dynamic testing, can leave significant vulnerability identification gaps. Open source vulnerability management (OSVM) completes the picture, providing automatic identification and inventorying of open source software, mapping components to known vulnerabilities, and streamlining and securing CI/CD activities. A three-pronged approach, incorporating SAST, DAST and OSVM, ensures a comprehensive and in-depth assessment of security across the entire application landscape.
Nothing can fully protect against human error, and the Equifax employee’s failure isn’t the first instance of human error leaving an organization exposed to an open source vulnerability, and won’t be the last. But if Equifax’s March scans had been effective in identifying the Apache Struts vulnerability in its affected systems, they might have been able to stop — or at least, limit — the attack and close the backdoors the intruders had set up to protect the financial data — Social Security numbers, birth dates, addresses and more — of at least 143 million Americans.