Third Party Code: Should CIO's FREAK Out About a Broken HeartBleed?
CIOREVIEW >> BlockChain Europe >>

Third Party Code: Should CIO's FREAK Out About a Broken HeartBleed?

Jake Kouns, CISO, Risk Based Security

No matter the industry, all companies are under increasing pressure to bring better products to market. Many companies require IT, specifically developers to deliver and they need to release fast, and difficult deadlines are being pushed down from the C level. Even with numerous high-profile data breaches, security is still often an afterthought for many organizations. The massive amount of vulnerabilities announced daily, makes it clear that software companies continue to focus on new features as a priority, not producing secure code.

While it was once understood that any project had to make decisions and tradeoffs, the proverbial “Better, Faster, Cheaper” was always understood that you can only pick any two. Now customers are demanding all three; doing more with less is the new normal for every part of a company not just software development. In order to meet demand, many develop­ers are increasingly turning to established third-party libraries to speed the develop­ment process over creating an in-house solution from the ground up. Commercial and open source libraries are often used to help achieve the idealistic balance be­tween the three proverbial options.

The days of a vendor ship­ping only their own code are also largely over. To save time, adopt open stand­ards, and deliver feature-rich applica­tions, companies rely on third-party soft­ware libraries that essentially plug-in to their own. In some cases, that one piece of software can have upward of 100 librar­ies bundled within. Tens of thousands of lines of code, written by someone outside of the organization, is likely part of that solution you purchased last week.

While this approach increases the speed of development, the belief that li­braries are well tested and securely writ­ten is in question. Even companies that employ a security development lifecycle (SDL) may not apply those standards to third-party code. It’s important that a CIO understands there is burden to evalu­ate the security of the wide selection of libraries available, and also that security rarely factors into decisions for inclusion. Software development is focused on in­tegrating the libraries and delivering a working product, not tracking the vulner­abilities associated with each one used within their products.

Prior to Heartbleed, perhaps the most well publicized vulnerability, many or­ganizations were not aware of third-par­ty libraries. Many CIO’s had their eyes opened when they realized the vulner­ability potentially impacted thousands of vendors and countless servers on the Internet were vulnerable. Further, many thought that the only companies impacted were ones that were trying to cut corners, and that a mature organization wouldn’t ever use something like OpenSSL, where the vulnerability originated from. But that’s not reality, as many major vendors rely on OpenSSL and were impacted.

As software becomes more inter­connected, the potential systemic risk becomes more apparent. One vulnerabil­ity can impact many organizations (think Hurricane; one event that causes issues for thou­sands). When doing fur­ther analysis, the very real result is that third-party libraries have the abil­ity to spread a single vulner­ability across multiple products, exposing enterprises and requiring vendors and IT organizations to patch the same vulnerabil­ity repeatedly.

A CIO needs to ensure that all third party code usage is first identified, and then make sure that their security depart­ment is tasked with conducting evalua­tions and specifically tracking issues in those libraries.

Understanding which products use third-party libraries is required before development or security teams can focus on securing them. Unfortunately, gener­ating the list of libraries used cannot be reliably done with a vulnerability scan. While some libraries can be identified as part of a normal network or application discovery process, in most cases libraries are embedded in a codebase and will not be externally visible. Organizations can either decide to collect this information manually or to make an investment into purchasing a software product that assists with this task. There are several solutions on the market that focus on inventorying all third-party libraries in your applica­tions. While it’s not required to purchase software, it’s important to know that if you request developers to report library usage, it may be prone to omissions and outdated information. Finally, it’s impor­tant to remember that usage of third party code can have serious legal consequences if not managed properly for an organiza­tion in terms of licensing. Your legal de­partment has the same goals as the secu­rity department in terms of identifying all libraries in use and should be involved in this process.

While the exact number is unknown, there are believed to be many thousands of libraries currently being used in enter­prises around the world. It’s important for organizations to have the ability to evalu­ate libraries prior to being implemented in a product. While there are a lot of ad­vantages, there’s a clear cost of ownership associated when an organization decides to use a library. Organizations must make sure it’s clearly known the number of his­toric and current vulnerabilities in their libraries, along with the time the vendors take to solve issues, which allows you to make the best decision on which libraries pose the most risk. Furthermore, it can be a huge security risk if the library has been declared End-of-Life, with public yet un­fixed vulnerabilities present.

For companies already integrating third-party libraries, it’s critical to moni­tor each library to ensure that newly dis­closed vulnerabilities are addressed, either by the library vendor or your own development team that may have to pro­vide a one-off patched version in your products. Companies that want to moni­tor libraries must understand and prepare for the overhead associated with this task, given the sheer number of vendors, prod­ucts, and information sources that must be tracked.

The importance of understanding third-party library usage and the potential security issues can’t be overstated. There have been numerous examples where vulnerabilities identified in one product ended up being the result of a bundled li­brary. Having knowledge of these issues not only lets your company be more pro­active with security, it allows you to be in a place to have a robust incident response plan for critical vulnerability disclosures that impact your organization.

Read Also

Every Changing Labor Force

Rizwaan Sahib, US Chief Information Technology Officer, Brookfield Renewable

Great Expectations: Balancing the diverse needs of a city in a...

Murray Heke, Chief Information Officer, Hamilton City Council

Community Banks And Digital Banking

Michael Bryan, SEVP, Chief Information Officer, Veritex Community Bank

"Discovery and Delivery" - An Approach to IT Workload Balance

Charles Bartel, Vice President for Information Technology and Chief Information Officer, Duquesne University