In the wake of the Equifax data breach having exposed the sensitive information of over 140,000,000 Americans, many individuals are waking up to the dangers that come with our personal financial information being stored on computers owned by third parties such as credit bureaus. But the facts of the Equifax breach should raise alarm for other businesses, as well, about the security of their own systems and data. Fundamentally, the hack resulted from Equifax’s reliance on open-source software as a component of its software solutions, and any company whose systems rely on open-source or customized software should take heed.
Equifax says that its computer experts now understand how hackers were able to enter the company’s system. They say that hackers exploited a vulnerability in an open-source software program called Apache Struts. That vulnerability, called “CVE-2017-5638,” was discovered as early as March 2017, months before the Equifax breach. Equifax has stated publicly that it took efforts to patch any vulnerable systems after learning of the risk, although there is ongoing debate about whether Equifax took all necessary and appropriate steps to mitigate the risk.
The Equifax breach was massive, and will be the subject of legislative, regulatory, and litigation activity into the foreseeable future. Equifax is a large, sophisticated corporation, with teams of software engineers and other technical specialists, and still it could not manage its code sufficiently to avoid this disastrous hack. Other companies with far more limited resources face the same challenges, however, if their systems use open source or other customized software.
Anyone who’s used a computer or a smartphone has been prompted with messages about updates to software or apps. Typically, either on your phone or with off-the-shelf software, these updates are installed automatically, or perhaps after prompting the user for permission. Updates are generally accompanied by some sort of explanation such as addressing security issues or enhancing stability or adding some new functionality. Consistently applying available upgrades is not just a best practice, it is critical to maintaining the safety and security of a company’s information systems.
The process is more complicated with open source software. To be clear, open source does not necessarily mean less secure or stable. Both open source and off-the-shelf software have vulnerabilities, and there are processes to address those in both cases. In fact, open-source software, particularly types that are routinely used in software developer communities as components of broader systems, maybe just as closely monitored for vulnerabilities as off-the-shelf software, and the fixes might be just as effective and just as timely as they would be from a name-brand software company. However, at least generally speaking there is not the same organized rollout of fixes or advisories for an open source product that there would be for, for example, products from Microsoft or Oracle.
Complicating matters, very frequently open source modules are included as components of larger systems, and patching a vulnerability might not be as simple as deploying a “fix” on each instance of the module. Addressing the vulnerability as it affects a given system may require skilled attention by one or more software engineers, as well as testing for effectiveness and against unintended side effects. To maintain security and stability, companies must be diligent in discovering identified vulnerabilities in their software components as well as implementing appropriate remedial measures. Both require time and effort.
Of course, no list of “known vulnerabilities” is of any use if the company does not know what components are actually contained in its software. It is vital for a company to have a complete understanding of its software system so that it can search publicly-available databases for new information about its components, including potential vulnerabilities, patches, and fixes.
In the case of software systems developed internally, companies should develop procedures to document and maintain information about the various components of its software systems and to memorialize developments as software and/or components are changed, retired, or added. Complete understanding of the current status of a company’s overall systems is essential. As systems even at small- and medium-sized companies grow in complexity, simply maintaining a list of software on a spreadsheet may no longer be sufficient.
Software that is developed by third parties can have similar problems. Companies should require providers to inventory the exact composition of the included code, ideally even before implementing the software in their systems. Without that information, the company cannot be confident that all components are safe, or that they can be maintained in the future.