What Is a Cryptographic Bill of Materials or CBOM?

Cryptography is now more intertwined with software development and DevOps processes. Therefore, best practices and policies for managing elements of the cryptographic portfolio, such as PKI and certificate lifecycle management, throughout the software development lifecycle (SDLC) are essential to ensure the confidentiality, integrity, and authenticity of the underlying data.

The challenge that organizations are facing is that software development and delivery is more complex than ever with distributed cloud and containerized environments. As DevOps teams strive for speed and agility, PKI is often a barrier and least path of resistance is doing it their own way outside of the enterprise PKI policies which can create problems that are harder to fix later in the SDLC.

If You Cannot Measure It, You Cannot Manage It

In December 2020, many departments of the United States Federal Government and large multinational corporations publicly reported that they had been the victims of a software supply chain attack due to the insertion of malware into the software update of the SolarWinds Orion platform. This attack raised concerns about the security of the software supply chain and the need for better oversight and monitoring.

In response to this massive software supply chain attack, the Biden-Harris administration released Executive Order (EO) 14028 in 2021 calling to improve the nations cybersecurity.

A key element of EO 14028 was the requirement for software vendors to provide a software bill of materials (SBOM) for their products. The SBOM is a detailed inventory of all the components, libraries, and modules that make up a software application. The SBOM also contains the supply chain relationships of the different components used to build a complete software application. Having a SBOM could help quickly identify and address zero-day security vulnerabilities by providing a clear map of all components, making it easier to locate and patch affected parts of the software and any software dependencies.

If private and public sector organizations had SBOMs from software vendors prior to the SolarWinds incident or the Log4j vulnerability, the attacks could have been rapidly mitigated to minimize the significant operational and financial losses that occurred.

With PQC now ready for the initial steps towards mainstream adoption (read more here), it is now more important than ever to begin to understand the magnitude of preparation that is required to migration to quantum-resistance cryptography.

The National Institute of Standards (NIST) is unequivocal in its messaging to adopt PQC starting now by stating in its latest announcement; “There is no need to wait for future standards. Go ahead and start using these three.”

Thankfully, NIST previously released guidance on PQC adoption in anticipation of the official release of the three FIPS PQC standards. As part of its guidance for the migration to PQC, NIST is recommending augmenting a SBOM with a Cryptography Bill of Materials (CBOM).

Elements of a Cryptography Bill of Materials (CBOM)

A Cryptographic Bill of Materials (CBOM) is an extension of the SBOM, and it goes into further detail to describe cryptographic components in the software and their dependencies. The components of a CBOM include the cryptographic algorithms and libraries used in the software products throughout your organization. It would include details such as their versions, and their dependencies on other software components and libraries. A CBOM can also contain metadata about the cryptographic algorithms and libraries, such as license information and known vulnerabilities.

An example of a CBOM component is the RSA or ECDH encryption algorithms, which are widely used in TLS. Other examples of CBOM components include the SHA2 hashing algorithm, the OpenSSL library, and the Java Cryptography Extension (JCE) framework.

For PQC readiness, creating a CBOM would be the first step to measuring and identifying the scale and scope of the changes required for PQC adoption. Having a CBOM could also greatly aid in the response to vulnerabilities targeting weak cryptography and other PKI related issues.

Table 1: Provides an example of a SBOM for a fictional load-balancer.

Table 1 provides the software components present on a fictitious load-balancer. The OpenSSL component noted in the SBOM could be a component on the CBOM for this load-balancer.

Furthermore, if a CBOM with further details were to be created for this load-balancer it may contain the following information in Table 2.

Table 2: sample components of a CBOM

This example of a CBOM helps identify where specific cryptographic algorithms are used, making it easier to plan for a Post-Quantum Cryptography (PQC) cutover by targeting components that use algorithms like RSA, ECDSA, and ECDHE

Additionally, the key lengths indicate the security strengths of each asymmetric algorithm. By understanding these strengths, it can better inform a PQC transition strategy to align with the equivalent security levels of PQC algorithms such as ML-KEM, ML-DSA, and SLH-DSA.

Finally, by having a SBOM and a CBOM, organizations can achieve a higher level of security and resilience, addressing identity management and both software and cryptographic vulnerabilities comprehensively https://appviewx.com/blogs/white-house-national-security-strategy-puts-new-focus-on-identity/.

Imagine If You Had a CBOM for the Heartbleed Vulnerability

A CISO in office during April 2014 will remember vividly the announcement of the zero-day OpenSSL Heartbleed vulnerability. Heartbleed was a vulnerability that allowed attackers to read the memory of servers and extract sensitive data such as passwords and credit card information without authorization. It impacted only certain, but widely deployed versions of OpenSSL. Furthermore, because of certain implementations of TLS being dependent on vulnerable versions of OpenSSL, the problem was widespread.

Part of the challenge of mitigating the Heartbleed vulnerability was first trying to identify where the vulnerability was present. One of the first tasks would have likely been using a scanning tool to identify vulnerable systems. This process takes time that is precious when needing to expedite response times as the organizations is under attack. Imagine in 2014 if a CISO and their security team had a comprehensive CBOM. This would have identified where OpenSSL was present, which versions were installed, and which software had dependencies on this library. The time required to address the NIST CSF Respond and Recover functions would have been expedited and the attack results minimized.

Identifying and managing your cryptographic footprint with continually generated CBOMs, would not only aid adoption of PQC, but it would also:

• Improve your Software Supply Chain Security with visibility into cryptographic assets
• Improve your time to response and recover should another zero-day vulnerability be announced impacting a cryptographic element in your organization

The cryptography and PKI experts at AppViewX can help guide you on path to better manage your cryptographic assets across your organization. I encourage you to talk to them today.

*** This is a Security Bloggers Network syndicated blog from Blogs Archive - AppViewX authored by Dr. Angelique Faye Loe. Read the original post at: https://www.appviewx.com/blogs/what-is-a-cryptographic-bill-of-materials-or-cbom/