Third party libraries represent a potential attack vector and present security risks to the ecosystem where they are integrated because a majority of the code in numerous applications today comes from third party libraries but the risk of vulnerabilities in these libraries is widely ignored and under-appreciated. In a previous article, the author illustrated the third party library threat landscape, the challenges associated with developing a comprehensive library specific threat model and explained the common attack patterns that leverage common vulnerabilities in libraries. In this article the author discusses techniques and challenges to mitigate threats and vulnerabilities in third party libraries via Security Development Lifecycle (SDL).
Security Development Lifecycle (SDL) is a set of activities and milestones which can drive high-quality security outcomes in product and services development. SDL makes security an integral part of product definition, design, development and validation. SDL integrates with the corporate Product Life Cycle (PLC) process in order to ensure that products meet security requirements. SDL usually comprises of 5 different stages.
SDL S0 phase ensures that appropriate SDL activities are recommended and incorporated to address expected security risks with the project. The SDL plan is tailored to each project's specific security risks. In order to correctly assess the security risks of software libraries, we need to be aware of the specific use cases for these libraries, which in many instances are not known upfront.
SDL S1 phase enables the project team to develop a suitable threat model that drives appropriate security requirements and security objectives. These objectives and requirements will enable designers, developers and validators to take the project's security concerns into consideration while executing their security responsibilities. In case of libraries, as explained previously, often times, application specific threats are unknown. If application security threats are known with security objectives identified, choosing an appropriate library becomes easier. For example, if the security properties of an existing library are not aligned with the application security objectives, developing a new library could be an alternative that requires time and resource commitment.
SDL S2 phase ensures that all security objectives and security requirements are successfully translated to lower-level design artifacts, preserving the security assurances in the development of the project. In practice, this phase may or may not be applicable depending on application security objectives.
SDL S3 phase enables developers and validators to evaluate a partial set of their security accomplishments with sufficient time to address any gaps in their security processes or coverage. This phase involves the examination of early implementation such as alpha code, to ensure implementation is on track for delivery of a trustworthy product. SDL S3 is critical to ensuring security of software such as libraries and usually comprises of verifying secure code development practices, static and dynamic analysis, manual code review, fuzz testing and verifying and enabling compiler defenses. Identified security flaws are fixed during this phase.
On the other hand, when using third party libraries for application development, misuse of libraries is a strong concern. There have been instances in which standard libraries were used, but the developers using the libraries made incorrect assumptions about how to use the library routines. For instance, developers may choose the right crypto algorithm, but use it incorrectly by choosing the wrong initialization vector, entropy sources, key lengths or hardcoded credentials. Understanding the nuances of algorithm and library usage is a core skill for applied cryptographers. In general, the common misuses of libraries as documented by IEEE Center for Secure Design include:
· Using a library with known vulnerabilities.
· Using a library with extra features, such as debug interfaces, introducing security risks.
· Reusing a library that no longer meets current software security standards.
· Using a third-party library and thereby offloading responsibility of security to the third party.
· Making configuration mistakes in the security of a library, for example, using a crypto library without understanding default values.
SDL S4 enables management to understand and disposition significant security risks that have not been sufficiently addressed prior to release of the product. SDL S4 ensures the product is ready to ship from a security perspective.
While S0, S1 and S2 stages are generally part of the SDL, S3 stage followed by S4 is critical to ensuring the security assurance during development of libraries. The 8 major categories of vulnerabilities identified in table 1 can be detected and fixed via S3 activities that include static code analysis, reviewing source code manually for secure code development practices, fuzz testing, dynamic analysis and enabling compiler defenses. Moreover, the success of SDL largely depends on the efficacy of role based security training and awareness made available to product architects, developers, validators and managers. In this context, security assessment of third party libraries is important. When binaries of libraries are obtained from third party vendors or from opensource communities whose SDL practices are unknown, it is recommended that application developers and validators ensure these libraries have the latest security fixes and proper compiler defenses and configurations enabled before integration with the application. In cases where the library source code is available, depending on the licensing model, deeper security validation can be performed. Performance optimizations or side channel mitigations for crypto libraries generally warrant additional security scrutiny.
TABLE I. Vulnerability Categories
An important principle of the Defense in Depth strategy is that achieving information assurance requires a balanced focus on three primary elements: People, Technology and Operations. In case of libraries, a balanced focus on the three primary elements is encumbered with complexities. Software libraries are increasingly providing reusable building blocks to a large number of applications today. Raising awareness on the potential security risks associated with vulnerable libraries, ensuring appropriate security validation is in place, developing formal procurement or governance policies to understand, manage and mitigate opensource or third party software adoption risks along with establishing formal incident response practices will raise the bar on security assurance for software libraries.
by Ovidiu Mățan
by Mihai Câsu
