Today, virtually every business and mission-critical task depends on complex technology supply chains, and organizations need to know for certain that these assets are authentic, unaltered, and free of threats and vulnerabilities. But this can be a lot trickier than it sounds. Technology supply chains often rely on a web of highly-specialized suppliers, subsuppliers, and developers, often spread across many organizations and countries. Each step in the chain is a chance for mistakes or threats to find their way into a product, and unfortunately, a wide range of attackers and shady operators have seized on the supply chain as an ideal way to introduce threats or peddle counterfeit products.
This has made supply chain security a top national priority, and NIST has produced a variety of guidance on the subject in support of the Executive Order on Improving the Nation’s Cybersecurity. Check out our paper A NIST Blueprint for Securing Digital Supply Chains (PDF) for more details on this topic. However, NIST recently published a new special publication known as SP 1800-34, which hones in on one of the most important, yet challenging aspects of supply chain security – devices. This is a particularly important document in that it lays out a detailed model that gives both manufacturers and their customers a way to verify and document the integrity and provenance of their devices and components.
Naturally, this is a subject that is near and dear to our hearts at Eclypsium, and we are proud to be one of the industry collaborators on the project. We encourage you to review the full document, but we have highlighted some of the key takeaways for you here.
Understanding Device Integrity and Provenance
“Most organizations’ security processes consider only the visible state of computing devices. The provenance and integrity of a delivered device and its components are typically accepted without validating through technology that there were no unexpected modifications. A delivered device has integrity if it is genuine and all changes to the device were authorized and expected. Provenance is the comprehensive history of a device throughout the entire life cycle from creation to ownership, including changes made within the device or its components.”
—NIST SP 1800-34
This statement succinctly gets right to the heart of what organizations must do when it comes to verifying their devices. First, we have to go beyond the visible state of a device and actively validate the asset through technological means. It is not possible to validate technology simply by eyeballing it. And it is important to remember that even though we may think of a device as something physical (and it is), any vulnerabilities or threats will manifest in the code running within that device whether in the form of firmware, the chipset, bootcode, or other forms of machine code. We can’t verify these things just by looking at the box.
And when we do assess these assets, we have to understand device integrity and provenance. Integrity means that the device, all of its components, and all the aforementioned critical code in the device is exactly as it should be. Any deviation means that something unexpected has happened in the supply chain. It could be something nefarious such as an attacker tampering with the device in the supply chain, or it could be the sign of a mistake such as a supplier accidentally reverting to an older vulnerable version of firmware, forgetting to properly enable a security setting, or introducing a new update that hasn’t been tested or validated by the rest of the supply chain. In either case, this is something that has to be found before the device is passed further along or put into service. Provenance means that we need to know how the sausage is made from a technical perspective. Most every device has a long history involving components and systems from suppliers, subsuppliers, OEMs, and so on. That chain needs to be known, documented, and verified.
So, how do we do that? That brings us to the next very important point…shared responsibility.
“This prototype relies on device vendors storing information within each device and organizations using a combination of commercial off-the-shelf and open-source tools that work together to validate the stored information.”
—NIST SP 1800-34
SP 1800-34 makes a very important point that both vendors and buyers have responsibilities when it comes to verifying devices. The previous section noted that customers need to use technology to validate the devices they receive. But how can they do that if they don’t know what to look for? This information ideally needs to be documented and provided by the vendor typically in the form of a Software Bill of Materials that goes down to the level of firmware and other device-specific artifacts. This same process should be repeated upstream throughout the supply chain itself. For example, an OEM is effectively a customer of its suppliers and needs to be able to validate the components and code they receive.
This is precisely where a supply chain security platform such as Eclypsium comes into play. For vendors, Eclypsium can analyze devices and components in order to verify that components are free of vulnerabilities and threats and create the documentation needed to create the SBOM. The platform can likewise actively validate for vendors and customers that the products and components they receive actually conform to the SBOM. Even in cases where the upstream vendor or supplier has not provided an SBOM, a true supply chain security solution should have its own independent database of the components and code within a device, which can be used to find any unexpected changes or risks.
Supply Chain Security Begins at the Root
“Hardware roots of trust are the foundation upon which the computing system’s trust model is built, forming the basis in hardware for providing one or more security-specific functions for the system… By leveraging hardware roots of trust capabilities as a computing device traverses the supply chain, we can maintain trust in the computing device throughout its operational lifecycle”
—NIST SP 1800-34
This statement is important from a technical as well as a logical perspective. From a technical perspective hardware roots of trust provide one of the most critical artifacts available for verifying the integrity of a device. Additionally, assessments should include checking for any settings or vulnerabilities that could put the hardware root of trust at risk. For example, missing device protections can, and have, allowed attackers to subvert boot protections. Vulnerabilities in update processes can have the same result. Failing to update the DBX firmware revocation database on a device can allow attackers to run vulnerable bootloaders to subvert boot protections. Once again, Eclypsium can enable organizations to easily check for these and a myriad set of similar issues.
However, the most important statement is the logical truth that “hardware roots of trust are the foundation upon which the computing system’s trust model is built.” Many in the industry have mistakenly pigeonholed supply chain security as an open-source software problem. Open-source projects certainly do have serious supply chain risks that need to be addressed, but that is just one branch of many supply chains. An organization has to care about its use of open-source, the assets and services they use in the cloud, the software they buy, and of course, their devices. However, the common denominator is that all of that code ultimately runs on a physical device. If the underlying physical infrastructure is subverted, then good luck trying to secure the code and services running in the higher layers. A supply chain security strategy must recognize that all of these assets matter and are in scope.
Helping organizations do this easily and efficiently is our sole focus at Eclypsium, and if you would like to learn more, please reach out to the team at firstname.lastname@example.org.