Waratek director of client security solutions, Prateep Bandharangshi, explains how to minimize the risk of another Heartbleed.
Third party software libraries represent one of biggest, and possibly most overlooked, threats to enterprise security. That’s because open source components are regularly used by enterprise application developers to speed development and avoid “re-inventing the wheel.” Third party code makes up between 30 percent and 90% of typical applications, according to industry estimates. While using third-party or open source libraries is a great time saver, it also exposes organizations to many thousands of lines of software that was not authored internally and may contain vulnerabilities.
The risks associated with open source software (OSS) are plain to see. In the absence of a vendor responsible for the code, there is no assurance that security was properly addressed in the development of the library. If a security vulnerability is discovered, no entity is “on the hook” to provide a patch. Furthermore, if a patch is provided, there is little assurance that the fix was properly tested, or doesn’t create a different set of problems.
Heartbleed Lessons
Perhaps the most egregious recent example of a vulnerability in a third-party library was the “Heartbleed” incident in early 2014. A very widely used, open-source web security, library called OpenSSL was found to have a catastrophic vulnerability that allowed hackers to obtain encryption keys used for secure web communications. It left everything from passwords to patient health records exposed to compromise. The OpenSSL library is used in countless web servers, effectively creating a huge security hole which app developers were completely unaware of.
Implementing security controls on third-party code is also difficult due to organizational issues. Security teams in most companies have only a tenuous connection to the application development team and their processes. Furthermore, the priorities of these two functions are unlikely to be closely aligned. As a result, security teams tend to have minimal influence on the software development lifecycle (SDL) and struggle to ensure that adequate attention is paid to security best practices during the coding process.
Minimizing Risk
What can be done to minimize the risks of using third party libraries? The answer really depends on the current state of the organization. If an application security team is in place, addressing the problem will be more straightforward. If not, the first step is to find an executive sponsor and establish an organizational nexus to create such a team, even if it is informal and cross-functional. Based on empirical evidence, it is much less likely to happen if there’s no security team in place to drive the process.
Perhaps the most egregious recent example of a vulnerability in a third-party library was the “Heartbleed” incident in early 2014
If a company has the political and organizational will to seriously tackle application security, the approaches to securing third party open source code roughly fall into two categories.
The first category consists of policies, procedures and technologies implemented early in the SDL. While there are a wide variety of options, frequent choices include developer awareness training related to the risks of OSS, and audits of any open source software in use, especially in high priority apps. Another option is to create and maintain approved internal repositories of OSS and restrict downloading of non-approved software. Finally, some firms like to apply hosted or on-premise static analysis (SAST) of source code.
It’s worth mentioning that there are a wide variety of controls that have general applicability – that is, securing software in general – which can also help with the OSS problem, but are beyond the scope of this article.
App Deployment
The second category of solutions to the open source problem focuses on the application deployment phase. This approach recognizes the difficulties in detecting all potential issues early in the development lifecycle for every application and is consistent with the best practice of defense in depth. Examples of controls at this stage tend to be more about technology and less about process. For example, penetration testing to focus on high priority apps with heavy OSS content; and dynamic and interactive analysis (DAST and IAST), which amounts to automated vulnerability testing on running apps. Another option is Runtime Application Self-Protection (RASP) – an emerging technology which implements security protection and detection within the execution environment. Because RASP combines intimate knowledge of application logic and data flows with mitigation, it is particularly useful to guard against zero day attacks.
Substantial use of open-source software is a fact of life in today’s enterprise application environments. However, it also creates significant security and compliance exposures. To maintain these risks at acceptable levels, organizations should consider both technical and procedural, as well as application security, controls.
Prateep Bandharangshi is director of client security solutions for Waratek. For the past 15 years, he has been involved in the design, deployment and operation of scalable and secure Java based systems across mobile carrier networks as well as the banking and online industries. He has held senior technical positions with Vodafone, Electronic Arts, IBM Australia and the Australian Department of Defense.