With the proliferation of attack surfaces in IoT, the increase in firmware-based attacks on hardware, and growing threats to systems throughout their lifecycle, companies are beginning to embrace the new model of zero trust for systems.
Compute lifecycle assurance
For the last decade, it’s been common practice for IT to require end users to authenticate themselves before they are granted access to the system or network. But in a zero-trust world, this requirement extends beyond the user. Neither the system itself nor its components are assumed secure at any given time. This has driven companies to verify not just the identity of system users but also the integrity of the systems themselves—in every phase of the lifecycle.
To help facilitate this zero-trust model, compute lifecycle assurance (CLA) is playing an increasingly pivotal role. CLA is a framework that helps analyze and address the security and integrity of a system and its components across its entire lifecycle.
The lifecycle is broken down into four distinct stages – Build, Operate, Transfer, and Retire. These systems (such as CPUs or other compute elements) are at risk because of counterfeit or tampering or even out-of-date firmware versions. And in many of these cases, IT has no visibility into the problem. Attacks can occur in manufacturing during the Build Stage, or during day-to-day use of the system in the Operation Stage.
Given the average time taken in 2020 to identify a breach was 228 days (according to IBM), CLA offers another important layer in security.
But how does each stage of the CLA framework help with zero trust? Let’s dive into each one in more detail.
Zero Trust Build
During manufacture and assembly there is some risk that systems receive counterfeit or replacement parts, which may either be malicious themselves or unintentionally vulnerable to future attacks. For example, there’s currently renewed concern about counterfeit chips due to supply chain shortages.
Compute lifecycle assurance recommends companies have a way to verify that what they ordered is what they received – not just at the system level, but at the component level as well if the component runs active firmware. Active firmware can be a path into the hardware, so it is important that it hasn’t been tampered with and that it’s up to date.
How can companies verify technology in the build stage? One approach is to use solutions that capture information on the components hardware as they are built directly from a shop floor control unit, then stores it securely and uniquely on each device and provide customers the ability to retrieve the data themselves and view the full bill of materials and traceability report of their systems.
These approaches sometimes use the ledger or database model approach. Take a laptop manufacturer for example: this would allow them to verify the authenticity of components (for example in a motherboard or server), installed firmware, and the configuration of the system by capturing all the production information and sending it securely to a remote server for verification later.
Zero Trust Transfer
Highway robbery looks different in the digital age. Today systems can be tampered with or compromised while they are physically in transit from their site of manufacture to their final location (Microsoft explores this topic in more detail here.) For example, a solid-state drive shipped to an original design manufacturer for integration into a computing system could be tampered with by having the firmware within the drive replaced with a malicious version.
Organizations work hard to eliminate these types of problems through a variety of methods including facility security requirements such as closed-circuit cameras, access controls and more, but also with layers of transport security such as tamper-evident packaging, security reviews of shipping lanes, locks, container integrity, GPS tracking and much more.
Look at Dell’s use of the Transported Asset Protection Association (TAPA) requirements or HP’s Supplier Management System. Furthermore, compute lifecycle assurance recommends verifying that the system is still exactly what was ordered when received on site at the company after the Build and Transfer Stages.
Zero Trust Operation
There are several subphases within Operation, each with its own risks, such as provisioning (this can be on-site or remote), daily use, and updating. CLA recommends at minimum verifying system integrity prior to provisioning a system to the network or assigning it to an end user. For even higher levels of security, companies can require systems to self-authenticate every time they attempt to access the network to ensure they are in a known good state. This means verifying between uses that the system firmware is up to date and hasn’t been tampered with, and that the physical components on the system such as the solid-state drive haven’t been swapped out for an unknown replacement.
How can this be done? One approach goes back to the ledger and database models. For example, with a ledger model once a computing system is delivered to the customer, the initial build records can be verified, and a continuous record of changes maintained. Another approach is self-reporting.
Once the device is in the hands of the end customer, the device can provide a cryptographic report of the current configuration of all the smart components in the device (or a comprehensive system-level report).
Zero Trust Retire
Often systems or their components are re-used in a second life scenario. Data needs to be completely wiped, especially before being re-provisioning to a different user or for a different purpose. CLA also recommends verifying the system has been returned to IT in the same state in which it was loaned out. There should be a record of any physical component or firmware changes, including upgrades, made to the system while it was in operation, and each of these should be accounted for.
How can this be done? Assets need to be uniquely identified and tracked as they are disposed of. However, there are many cases of companies disposing of hardware without verifying data has been wiped. Certificates of destruction can be faked, which is why it is important to secure proof and chain of custody information.
Hardware vendors should be investing in practices, tools and technology across their ecosystems to help customers and partners verify system integrity at every phase of a lifecycle. The compute lifecycle assurance framework is designed to help organizations meet that goal.