The security and integrity of technology supply chains is an issue that directly affects virtually every modern organization. Every organization naturally relies on technology, and vulnerabilities or threats within technology supply chains can allow adversaries to compromise that technology before it is ever delivered to the customer.
Over the past year, the White House has taken repeated measures to make supply chain security a top priority for federal agencies, most notably with the release of Executive Order 14028, Improving the Nation’s Cybersecurity, in May of 2021. The order called for NIST to issue guidance regarding secure software development as well as supply chain security, and for the Office of Management and Budget (OMB to comply with those guidelines. NIST provided this guidance via SP 800-218, Secure Software Development Framework (SSDF) and the NIST Software Supply Chain Security Guidance. On September 14, 2022, the White House closed the loop by issuing memo M-22-18, which directs federal agencies to comply with the NIST guidance.
What Is Required
This is a very important and far-reaching development. Specifically, the memo defines responsibilities in two important areas.
- Self-attestation from software producers – Before an agency can use a given software, the producer of that software must provide a document saying that they conform to the NIST guidance. It is important to note that this self-attestation is the minimum level required. Agencies may also require a third-party assessment of a vendor’s code based on the criticality or risk of the system.
- Obtain artifacts to demonstrate the software producer is using secure development practices – Based on the criticality of the system, an agency may require the software producer to produce a Software Bill of Materials (SBOM). Once again, based on the risk of the system, agencies may require a more proactive approach such as the “use of automated tools and processes which validate the integrity of the source code and check for known or potential vulnerabilities.”
The Role of Firmware
The memorandum includes a comprehensive definition of software which explicitly includes firmware and operating systems in addition to applications, as follows.
The term “software” for purposes of this memorandum includes firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.
This is an important development. Firmware is critical software shipped with and operating ICT equipment. Examples include network OS operating network appliances, Linux-based OS inside remote management subsystems in each server, BIOS or EFI code inside PC and Mac motherboards, software code running inside SSDs, and ultimately any code operating mission critical equipment. It is the most privileged software code on each device, and often the most persistent, all making it a natural target for adversaries in the supply chain. The challenge for agencies is that a single device may have firmware from dozens of different suppliers from different countries of origin. This can make self-attestation not only cumbersome but also inherently less reliable. For example, it is possible for an application vendor to self-attest to their own development practices. Other than open source projects, the vendor is the main source of code.
The software code within physical equipment such as laptops, servers, networking or other specialized equipment, is a much different proposition. Every component may have its own supplier and its own firmware. Each component may have sub-suppliers and open source components that make the full lineage of the code even murkier. Supply chain shortages and pressures may force a vendor to replace one supplier with another. This makes it very hard for a vendor to provide a reliable attestation for all the code within a product.
Getting Proactive
Taken together, firmware and software embedded in devices is both highly critical and hard to attest to. This can easily increase the need for agencies to take more proactive measures, such as getting third-party assessments of code or using automated tools to verify its integrity.
Eclypsium provides a highly automated platform to meet these needs and ensure the integrity and posture of an agency’s supply chain. Agencies or their certified FedRAMP Third Party Assessor Organization (3PAO) can use simple Eclypsium scans in the following ways:
- Inventory firmware SBOM. Generate software bill-of-materials for all firmware and software embedded within devices and physical equipment or validate vendor-supplied SBOM.
- Identify firmware supply chain vulnerabilities. Scan firmware for the presence of known vulnerabilities or configuration mistakes that could put the device at risk.
- Ensure firmware supply chain integrity. Verify the integrity of all firmware to ensure it matches valid firmware published by the vendor or supplier, and that the firmware has not been tampered with in the supply chain.
- Detect firmware supply chain compromise. Detect the presence of malicious firmware such as implants or backdoors. Monitor the behavior of firmware to identify the presence of new threats introduced into vendor code.
- Manage firmware supply chain risks. Discover, prioritize, validate and deploy critical firmware updates to mitigate supply chain vulnerabilities in a broad range of devices.
This gives agencies a far more direct and reliable way of verifying the security of their supply chain. Instead of trusting suppliers and a cascading network of attestations, security teams can easily verify what software and firmware is actually on each device and piece of equipment. This is not only a simpler approach but also more reliable and puts control in the hands of security teams.
To learn more, please reach out to the Eclypsium team at [email protected].
