alerts & publications

Data Security and Open Source, 2017 Update

Security breaches are big news, but is open source software to blame?

The Equifax security breach has been big news, since it was disclosed to the public in September 2017. The outcry is not surprising, given the hacking incident involved credit bureau information for an unprecedented 143 million consumers. Data security breaches now crop up regularly in all sectors -- including government, such as the hack disclosed recently by the US Securities and Exchange Commission.  As a result of its security breach, Equifax experienced a severe decline in its stock price, a crisis of consumer confidence, congressional hearings, regulatory investigation and potential class action lawsuits, as well as the need to make disclosures of the breach as required by US law.   

The Equifax breach has revived a controversy about the security of open source software that has been simmering for many years.  According to Equifax, the perpetrators of the breach may have exploited a security vulnerability in Apache Struts, an open source framework used to build web applications.  Open source software is software that is developed in a collaborative community, and made freely available to anyone who wishes to use it.  Since the early 2000s, the use of open source software, particularly in e-commerce, has burgeoned to the point that almost every technology company now relies heavily upon it.  Apache Struts is just one example of software included in the ubiquitous “LAMP stack” (Linux, Apache, MySQL, and Perl/Python/PHP). 

Prior to the announcement of the incident, Equifax had been made aware of the vulnerability and had undertaken efforts to patch it.  According to Equifax CEO Richard Smith’s written congressional testimony regarding the breach, Equifax’ efforts were ineffective, in part because the company failed to discover or repair the vulnerability for months after being notified of it.  Moreover, financial index provider, MSCI Inc., reported over a year ago that Equifax may have also failed to engage in data security best practices such as periodic cybersecurity audits, employee training, and processes to respond to intrusions.  Overall, this suggests an alarming state of affairs for a company whose businesses is predicated upon the processing of sensitive consumer financial data.

The Apache Software Foundation, the nonprofit organization that hosts the Apache Struts project, responded to Equifax publicly, pointing out that the incident was a so-called Zero Day vulnerability, or a vulnerability that may have existed for some time in a code base, but was not previously known to the developers.  The ASF commented: “[T]here is a huge difference between detecting a flaw after nine years and knowing about a flaw for several years.  If the latter was the case, the team would have had a hard time to provide a good answer why they did not fix this earlier.  But this was actually not the case here — we were notified just recently on how a certain piece of code can be misused, and we fixed this ASAP. ”  The Apache Software Foundation, in its response to the US House Committee on Energy and Commerce’s investigation of the Equifax breach, confirms that the Struts vulnerability was patched almost as soon as it was reported.

It may seem, after wide reporting over the last few years of several notable open source vulnerabilities such as Heartbleed, that open source is being publicly linked with security problems with increasing frequency. There is a long-running debate over whether open source or proprietary software is more secure, and the Equifax breach has fanned the flames of that fire.  Open source advocates point out that publicly available source code is more secure because, as they say, with enough eyeballs all bugs are shallow.  The alternative, they point out, is “security by obscurity” of software whose source code is reserved as a trade secret by its developers.  In such a case, all users must rely on the vendor for security patches, whereas anyone can patch an open source vulnerability.  Advocates of proprietary software point out that proprietary vendors have more resources and commercial incentive to maintain their products.  They also point out that because anyone can contribute to an open source code base, hackers can try to proactively introduce vulnerabilities into the code -- as opposed to merely exploiting existing loopholes.

But this debate is too facile; the security of software lies in the quality of its development and maintenance, and not in its licensing model.  More open source security incidents have been reported lately because more and more businesses are using open source software.  Hackers have therefore shifted their focus; hackers get the most return for their efforts when they hack popular software.  The targets of choice have changed over the years, because the technology landscape has changed. 

After the Heartbleed incident, the open source community responded to address the lack of maintenance resources for popular projects like OpenSSL.  In that case, most of the industry was free-riding on this popular secure socket layer software, without contributing to its development.  In contrast, many larger open source projects, like the Linux kernel, enjoy wide support by industry, including corporate engineering resources to maintain security.

Legacy software is always a potential security problem, whether it is open source software or not. Tech security is, in part, a process of continual updating to keep ahead of the villains, and some companies are better than others at pro-actively implementing data security protocols and updated features.  The large and engaged community nature of open source projects can be an asset to those that heed community alerts and devote proper resources to addressing identified vulnerabilities.  Pointing fingers at open source may make for interesting news articles, but it should not deflect our attention from the real issues.  Maintaining security of IT systems in today’s business environment is challenging, and needs to be a priority of every business.

This memorandum is a summary for general information and discussion only and may be considered an advertisement for certain purposes. It is not a full analysis of the matters presented, may not be relied upon as legal advice, and does not purport to represent the views of our clients or the Firm. Heather Meeker, an O'Melveny partner licensed to practice law in California, and Katie Tague, an O’Melveny associate licensed to practice law in California, contributed to the content of this newsletter. The views expressed in this newsletter are the views of the authors except as otherwise noted.

Portions of this communication may contain attorney advertising. Prior results do not guarantee a similar outcome. Please direct all inquiries regarding New York's Rules of Professional Conduct to O’Melveny & Myers LLP, Times Square Tower, 7 Times Square, New York, NY, 10036, Phone:+1-212-326-2000. © 2017 O'Melveny & Myers LLP. All Rights Reserved.