The Equifax breach has dominated headlines since it was announced earlier this month — and for good reason. The personal data of well over half the U.S. population, when adjusted for children and others who do not have a need for credit reports, was affected. Though not the largest breach in recent memory, the nature and extent of the personal data that was compromised make it among the most significant, and, as Equifax itself has recently revealed, the breach was preventable.
Recent reports have identified Apache Struts 2, an open-source web application framework, as the source of the vulnerability, but the Apache Software Foundation rightfully refuses to accept the blame for the Equifax breach. The Apache Struts 2 vulnerability was detected in March, and a patch was available soon after. U.S.- and U.K.-based publications reported the vulnerability and warned about attacks, and the United States Computer Readiness Team included the Apache Struts 2 vulnerability as a “High Vulnerability” on its March 13 Bulletin (SB17-079).
Assuming that the vulnerability itself has been properly identified, it is well-established that the vulnerability was known and patchable months before Equifax took steps to mitigate the risk. Security researchers and the general public alike are describing Equifax’s acts and omissions as negligence. Equifax has drawn an abundance of detractors, but few defenders. The only question is: Why didn’t Equifax act sooner?
It is easy to imagine C-suites across the globe taking a sudden, and perhaps panicked, interest in their company’s use of open-source software.
For one, Equifax has not been particularly forthcoming. Though its chief information officer and chief security officer both “retired” last week, Equifax has been slow to offer explanations for its inaction. It is easy to condemn Equifax as if its acts and omissions were completely outside the fold. However, it is also easy to imagine C-suites across the globe taking a sudden, and perhaps panicked, interest in their company’s use of open-source software.
The popularity of OSS has grown rapidly over the past decade. According to a Gartner study, 10 percent of IT companies surveyed in 2006 used OSS. In 2011, Gartner reported that more than half the IT companies surveyed used OSS. In a 2015 study, Gartner predicted that by 2016, 99% of Global 2000 companies would use OSS in mission-critical software.
OSS offers a number of advantages. It is flexible, low cost and transparent. It can lead to better quality and security, where an entire community has the ability to detect vulnerabilities and create patches. It can be used to create and promulgate standards and increase interoperability, decreasing the need to be locked into any particular vendor. Today, technology giants and other Fortune 500 companies not only use but also actively contribute to open-source projects.
Though traditionally free, the use of OSS is not unfettered. Companies and individuals using OSS should take care to meet their attribution obligations and abide by the license terms — use of OSS as a part of a project may require that the entire work become OSS.
Generally, OSS users are well aware of these obligations. However, few companies have, let alone follow, open-source management and security policies and procedures, and fewer still extend those policies and procedures to their third-party risk management practice.
Though it is certainly important for companies to gain and maintain visibility into their internal software development, most companies obtain the software that runs their core operations from third parties. Those third parties are likely using OSS, but unless its customers specifically demand disclosure of such OSS, the vendor is unlikely to offer that information. As the Apache Software Foundation advised in its Sept. 9 statement, businesses using any OSS should “[u]nderstand which supporting frameworks and libraries are used in your software products and in which versions. Keep track of security announcements affecting [the] products and versions.”
In light of a breach on the scale of Equifax, this is not a responsibility a company should trust to its vendors without visibility or accountability.
Before on boarding a software vendor, even before finalizing an agreement, the vendor should provide a list of all OSS, including the version in use. If the customer discovers a vulnerable or unsupported version is listed, the vendor should be held accountable to remediate. Not all patches are a simple download and reboot. As in the case of Apache Struts 2, patches can be labor intensive, requiring web applications to be rebuilt with an updated version of the code.
Who should bear responsibility for rebuilding the applications is fact dependent, but vendors are unlikely to offer if their customers do not ask.
Who should bear responsibility for rebuilding the applications is fact dependent, but vendors are unlikely to offer if their customers do not ask.
In fact, before Equifax, many vendors would argue that their use of vulnerable or unsupported OSS, and/or their failure to patch it in a timely manner, was a reasonable operational risk. Now that the issue is under the microscope of regulators, such practices by vendors, and the failure of the customers to be aware of vendor OSS usage and monitoring, are unlikely to continue to be considered reasonable.
photo credit: Skley Lethargie 240/366 via photopin (license)