One Point the Equifax Breach Drives Home

Today's developers use more third-party and open-source components, libraries and frameworks than ever to deliver and update products in ever-shrinking delivery cycles. In the race to get to market, it's easy to overlook or ignore details that can lead to a security breach.

For example, Equifax blamed its recent security breach on an Apache Struts vulnerability (CVE-2017-9805) and later admitted it failed to install a patch. That patch had been available for six months, according to The Apache Foundation.

"The Equifax hack is so interesting, mostly because their response to the hack has been so poor. Blaming a hack on any sort of software issue – open source or proprietary – is simply part of their inadequate response. It’s a 'the dog ate my paper' excuse," said James Stanger, chief technology evangelist at CompTIA. "That’s not much of an explanation, especially considering that Equifax disclosed this problem on September 7 after knowing about it since July 29. "

What if the software you built was compromised and you discovered that the root cause was a third-party building block you used? You didn't build that piece of software, after all, so perhaps that party should be liable for any damages that piece of software caused.

Practically speaking, good luck with that argument.

Little or No Third-Party Liability

If you're using third-party building blocks in your software, which you likely are, the buck stops with you. Sure, someone else's code may have caused a catastrophic failure, but did you read the fine print in the license agreement?  Third-party developers have several ways of dealing with the matter contractually.

"There may be disclaimers, especially in the open source community, that say, 'This component is [provided] as-is' and you as the licensee are responsible for its testing and usage in another system," said Roy Hadley, Jr., co-chair of the Privacy & Cybersecurity team at law firm Thompson Hine "If you choose to use it in a nuclear facility or the space shuttle, that's on you." 

Those who use third-party software in their products are ultimately responsible because the provider can't foresee how its software will be used or configured by others. So, the licensor protects itself using an "as-is" clause or a limitation of liability. Alternatively, the licensor may require indemnity from the licensee, which means if you use third-party software, something goes wrong and the provider of the component you use gets sued, you're liable.

What Software Developers Should Do

Test, test, test. Ideally, developers should take the time to understand every piece of third-party software they're using to make sure it does what it's supposed to do and that it's been tested for security vulnerabilities. They should also have a mechanism to ensure that the associated updates and patches are up-to-date.

"I think you have an absolute responsibility to make sure that third-party components work, work together and work the way they're supposed to," said Jason Wacha, an attorney and founder of  WS Law Offices which specializes in software licensing. "One of the things about the open source community is you hear [about a software vulnerability], they announce it and everybody jumps on it and tries to fix it. Certainly this was true for the Struts project. One of the things about proprietary software is if someone discovers a vulnerability, it's not going to get out there and people aren't going to talk about it."

The obvious constraint is time. There just isn't enough time to test everything.

"The issues we keep confronting or not confronting in the IT industry are ignoring or omitting key steps of the Software Development Lifecycle (SDLC) and then mismanaging how that resulting software is deployed," said CompTIA's Stanger. "One of the primary reasons why software issues get missed by the good guys and exploited by the bad guys is because companies, individuals and groups that develop software tend to rush software to market."

There are also challenges with the way software is configured and deployed.

"Many IT pros and even security pros still tend to think, 'If I obtain the code from a secure source and run the hash tag, I’ll be fine. I’ll just update the code as necessary.' Plus, relatively few companies actually test the software properly in a production environment by “throwing rocks” at the code and doing proper threat hunting," said CompTIA's Stanger. "Fewer still are able to update software adequately, because updates often break custom code. Imagine how security issues can propagate when you combine installed and cloud solutions."

While developers should verify that the third-party software they use has been adequately tested by whomever built it, they need to retest it in the context of their own product.

“The reality of the current world we live in is that any business must undertake extreme caution and implement a thorough due diligence process when vetting any vendor that impacts their supply chain or is processing or storing any information on its behalf," said Rob Rosenzweig, vice president and national cyber practice leader for insurance brokerage Risk Strategies Company. "While there is significant upside to the utilization of outsourced vendors in managing expense, obtaining a higher level of security and realizing operational efficiencies; the flipside is that organizations lose control and still retain all of the risk."

Lesson Learned

The Equifax breach underscores the need for vigilance because hackers are constantly experimenting to find and exploit vulnerabilities, particularly when sensitive information is involved. When a vulnerability is found, it needs to be addressed in a timely fashion, unlike the Equifax breach. Due to the confluence of events, the Federal Trade Commission (FTC) is now investigating Equifax.

As is evident, the failure to implement one patch can have devastating consequences.