As the sheer volume of the press coverage and its implied urgency suggests, Heartbleed is a significant vulnerability with serious implications for businesses. Not only does it expose private encryption keys, allowing encrypted SSL sessions to be revealed, but it also appears to leave user sessions subject to hijacking. Encrypted search queries and passwords used to access major online services are exposed and, due to the fact that this vulnerable version of OpenSSL has been around for more than two years, many services and their related data have been vulnerable to snooping.
Why has the discovery of the Heartbleed vulnerability had such a large impact on enterprise security? The OpenSSL vulnerability underscores two truths the security industry has been discussing for some time: that the use of third-party software components – such as open source libraries and frameworks — in internally developed software creates a potential security hole in organisations, and that companies typically don’t have visibility into the full breadth of their web application perimeter, making it impossible for them to make it truly secure.
It is common practice for developers to integrate third-party components into their applications – in fact it is not uncommon for 70 to 90 percent of an application to be composed of third-party commercial or open source components. This practice accelerates software development and allows enterprises to deliver innovations to market faster. However, the downside of component usage is that they often contain critical vulnerabilities — in fact, 90% of third-party code uploaded to Veracode’s cloud-based platform does not comply with enterprise security standards such as the OWASP Top 10.
As companies scrambled to address the Heartbleed vulnerability in their systems, it also became apparent that patching efforts would be inhibited by a lack of visibility into their entire web application perimeters. When patching, businesses focus first on their main publicly-facing applications, with patching initiatives often not extending beyond these initial applications, as the business may not be aware of all the applications in its infrastructure.
This leaves thousands of applications vulnerable and creates a long-term security threat. By way of example, Veracode leveraged its cloud-based infrastructure to analyse more than 26,000 websites in less than two minutes for one client, and found multiple sites still containing the Heartbleed vulnerability.
So, what can organisations do to address the Heartbleed vulnerability effectively, and to ensure future vulnerabilities have a lesser impact on their businesses? First, it is crucial that companies gain complete visibility into their entire web application perimeter and understand where OpenSSL libraries were used. This can be accomplished using next-generation discovery technologies that look for public-facing websites that are outside the usual corporate IP range, such as external cloud-hosted sites, sites obtained via mergers and acquisitions, and temporary sites created for specific marketing campaigns. These discovery technologies go beyond traditional network IP scanners by using a combination of advanced search techniques – such as DNS keyword searches, production-safe crawling, analyzing page redirects and machine learning – to quickly identify unknown sites that traditional network IP scanners miss.
The next step businesses can take is to inspect their existing application portfolios for all applications incorporating the vulnerable component. This is important because not all vulnerable applications are public-facing websites – many organisations have incorporated the OpenSSL library in mission-critical applications, to provide secure machine-to-machine communications. Software component analysis (SCA) is a new technology that inspects code statically, during the software development lifecycle (SDLC), for software components such as OpenSSL or frameworks such as Apache Struts. This ensures that developers are using the most up-to-date versions of components and that they are not using versions with known vulnerabilities.
Finally, now more than ever, a heightened awareness of application-layer vulnerabilities is crucial. The Open Web Application Security Project (OWASP) Top 10, for example, now includes “known vulnerable components” in its list of security issues that most hamper web applications. Elsewhere, the FS-ISAC recently added binary static analysis as a key control for reducing third-party software risk. Applying these standards to the software development process will go a long way toward avoiding similar issues in the future.
Clearing up the mess made by Heartbleed will take time, and it’s highly likely that we’ll see more high-profile victims over the coming weeks and months. However, every cloud has a silver lining and in Heartbleed’s case this may be that senior management will now be more educated about third-party software risk – and will allocate more attention and resources to assessing vulnerabilities in all of the third-party apps and components within their application infrastructures.
By John Smith, Security Architect, Veracode
At Veracode, we help you go further faster — with a fundamentally different, cloud-based service that won’t slow innovation. With our centralized, best practices approach, you can finally scale your governance program across disparate business units and development teams — and systematically reduce application-layer risk across your entire global infastructure.
About the Author
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.
