Beyond the SBOM: What CISOs should about CBOMs and HBOMs
SBOMs, CBOMs and HBOMS -- oh my! Learn how these bills of materials help manage supply chain risk and assess which of the three your organization needs.
Heartbleed, SolarWinds and Log4j -- the stuff of CISOs' nightmares. As cybersecurity leaders know all too well, these historic, high-profile security breaches revealed massive weaknesses in supply-chain security.
Rising awareness of third-party risk has led to a surge of interest in the SBOM. Often compared to ingredient lists on packaged food, SBOMs provide security teams with information about the components in their software, helping them identify supply-chain vulnerabilities and risks.
But the SBOM isn't the only bill of materials that CISOs should consider for third-party risk management. This article introduces two important, adjacent concepts -- the cryptographic bill of materials (CBOM) and the hardware bill of materials (HBOM) -- as well as the types of organizations that need them, their key components and best practices for creating them.
What CISOs should know about CBOMs
A CBOM is an extension of an SBOM, providing an easy-to-understand inventory of cryptographic assets across infrastructure, services and software. A CBOM helps cybersecurity engineers and technicians understand their cryptographic ecosystems, manage cryptographic risk and ensure compliance.
CBOMs also support crypto-agility and post-quantum computing migrations -- establishing where classical cryptography is in use and providing mechanisms for scoping and tracking post-quantum transitions.
Who needs CBOMs
Any organization with systems that use cryptography can benefit from the use of CBOMs in supply chain risk management. In other words, it's the rare company that should not consider using CBOMs.
Key components of a CBOM
In its most basic form, a CBOM is a table that notes the components of an organization's cryptographic assets. Fields might, for example, include the following:
- Cryptographic algorithms. Describes the mathematical formulas that underpin cryptographic security measures. These are often set up in libraries and might include:
- Symmetric algorithms such as AES, DES and Triple DES.
- Asymmetric algorithms such as RSA and Elliptical Curve Cryptography.
- Hashing algorithms such as SHA-256.
- Cryptographic keys. Describes cryptographic keys, essential components of security algorithms that are used to access, lock and unlock specific algorithms. Key lengths can range from 64 to 256 bits, depending on the algorithm; keys can be public and private.
- Protocols. Indicates protocols, such as TLS, that use cryptography.
- Certificates. Specifies digital certificates, such as TLS and SSL, working with encryption to ensure the security of internet and other data connections.
- Identification of dependencies. Describes how cryptographic components interface with relevant software and the cryptographic structure.
- Component configurations. Specifies how cryptographic components are configured and administered.
- Policy definitions and configurations. Establishes security, compliance and configuration requirements, as well as policies for meeting them.
CBOM benefits and challenges
CBOMs offer a variety of benefits, including the following:
- Organization, efficiency and visibility. Provides an inventory of cryptographic assets, organized in an easy-to-understand and user-friendly format.
- Compliance. Helps organizations achieve compliance with cybersecurity standards and regulations such as NIST SP 800-53, PCI-DSS and GDPR.
- Risk identification. Lets users analyze CBOM data to identify potential risks, vulnerabilities and single points of failure.
- Security assessment. Helps the CISO determine if existing crypto systems are adequate or whether it's time to upgrade the technology to a more secure level. Provides data that could help the organization improve its overall security posture.
- Quantum-safe cryptography. Supports the transition to quantum-safe cryptography.
For all their advantages, however, CBOMs also present the following challenges:
- Resource-intensive. Preparing and maintaining these records can be time-consuming and costly, especially for complex and legacy systems.
- High-value targets. CBOM data could be compromised and used by hackers if not properly protected.
- Limited tool availability. Relatively few tools currently exist to support teams in defining and managing CBOMs.
How to create a CBOM
A cost-effective starting point for building a CBOM table is Word or Excel. Teams can also use automated tools to scan source code, networking data, security data and other artifacts to identify application configurations, software dependencies and hardware for the CBOM. Such tools include the following:
1. CBOMkit
- Creates CBOMs that are machine-readable and allows companies to assess compliance.
- Scans and analyzes source code to identify cryptographic resources such as algorithms, protocols, certificates and keys. Based on an open source tool by IBM and maintained by the Post-Quantum Cryptography Alliance.
2. IBM Quantum Safe Explorer
- Uses .json files to define cryptographic assets and highlight relationships across elements such as libraries and protocols.
- Identifies vulnerabilities as part of cryptographic asset lifecycle management.
3. CycloneDX CBOM Support
- Provides a standardized format for creating inventories of algorithms, keys, certificates and protocols.
- The CycloneDX standard, developed by OWASP, includes support for CBOM development.
4. SandboxAQ AQtive Guard
- Includes a discovery feature that finds cryptography across the IT environment, gathering and analyzing data from sources such as cryptographic algorithms, libraries and protocols.
- Catalogs cryptographic artifacts and their dependencies and formats them into a CBOM. Identifies cryptographic vulnerabilities and compliance issues and monitors performance.
5. Black Duck
- Analyzes cryptographic elements and creates both SBOMs and CBOMs.
- Uses standardized, machine-readable formats such as SPDX and CycloneDX.
Once they have created and approved a CBOM, team members should regularly review and update it to ensure it continues to align with the organization's cybersecurity requirements and standards.
What CISOs should know about HBOMs
Moving from the abstract to the physical -- from cryptography to hardware -- an HBOM describes the physical components of a system, whether a server, switch, desktop computer or other corporate device.
According to CISA, which developed an HBOM framework, primary use cases include the following:
- Compliance. Assess how products could affect an organization's ability to meet standards, regulations and requirements.
- Security. Assess how a product would affect supply chain risk levels, due to known vulnerabilities and exposure to certain groups and geolocations -- e.g., a hardware provider based in China and subject to Chinese governmental oversight and intervention.
- Availability. Assess the relative difficulty of securing necessary components.
From a CISO's perspective, HBOMs and SBOMs complement each other by providing a thorough inventory of hardware and software components, which can in turn inform cyber risk and compliance strategies. Together, SBOMs and HBOMs create a framework that enables comprehensive supply chain visibility and more effective mitigation of third-party risk.
Who needs HBOMs
Any organization that relies heavily on hardware and prioritizes data security and supply chain transparency needs HBOMs, including automotive manufacturers, aerospace manufacturers, medical device manufacturers, critical infrastructure operators and healthcare providers.
Companies with IoT deployments and organizations working directly or indirectly with federal agencies should also consider HBOMs. Governmental organizations, for example, might not be able to legally use hardware components produced in certain countries -- e.g., China.
Key components of an HBOM
A bill of materials (BOM) contains, at minimum, the core elements used to construct a system, including part numbers, ordering codes, part descriptions, number ordered, unit costs, extended costs and any other relevant information.
BOMs are categorized as either single-level or multilevel. Single-level BOMs are the most widely deployed. They typically list components -- e.g., assemblies -- that comprise a finished product. For example, a single-level BOM for a server might look like this:
Server HBOM
- Cabinet assembly.
- Motherboard assembly.
- CPU/memory assembly.
- Power supply assembly.
BOMs that provide additional detail across all subassemblies are known as multilevel BOMs. For example:
Server HBOM
- Cabinet assembly.
- Top.
- Base.
- Fasteners.
- Motherboard assembly.
- Board.
- Device jacks.
- CPU/memory assembly.
- CPU.
- Memory.
- Power supply assembly.
- Power supply.
- Power cord.
Again, IT and security practitioners can use both automated tools and simple spreadsheets to generate BOMs. Some ERP or manufacturing resource planning (MRP) systems also include BOM modules. The ERP or MRP systems can then use the BOM data for planning, change management and other functions.