At the highest level, Zero Trust seems pretty straightforward—never trust, always verify. The hard part comes when security leaders and practitioners have to apply that concept to an incredibly complex technology stack. From the lowest levels of device hardware to the most abstracted levels of virtualization, there are countless opportunities for blind trust to creep into an organization. To make things manageable, the U.S. Federal government breaks Zero Trust into core pillars that include User, Device, Application and Workload, Data, Network, Automation and Orchestration, and Visibility and Analytics.
The U.S. National Security Agency (NSA) recently published a cybersecurity information sheet (CSI) that provides a deeper dive into the Device pillar. This is timely guidance because the device level is where attackers are increasingly active yet also where Zero Trust programs are typically the weakest. This is because most organizations lack deep technical insight into their actual devices. Most endpoint security products work at the application/OS level yet lack insight into the supply chain elements such as hardware, physical components, firmware, boot processes, and the other low-level systems and configurations that govern how an asset actually does its job. And of course, many devices such as network and IoT devices can’t support an endpoint agent at all.
With this in mind, let’s briefly take a look at some of the lessons from the recent NSA doc titled, Advancing Zero Trust Maturity Throughout the Device Pillar.
Trust Below the OS
First and foremost, the NSA doc defines what the device pillar entails, specifically calling out the critical components and code that sit below the operating system.
This ZT device pillar CSI prescribes mechanisms to shield devices from low-level, persistent threats over their entire lifecycle. Adoption of a ZT mindset enables organizations to never assume devices within an established environment are secure or that actors cannot hide from defenses in the OS or applications by delving into hardware and firmware.
This focus on hardware and firmware is consistent across the entire document. Threat examples focus on firmware implants, malicious bootloaders, and exploits against device components. Vulnerability and device management calls out firmware, server BMC configurations, TPM certificates, and similar low-level resources below the operating system. This is important because these are precisely the areas where many organizations place the most blind trust.
Device Inventory and the Supply Chain
The NSA doc says that Zero Trust for devices needs to go beyond just listing out the assets in inventory. Organizations need to dig deeper to audit the low-level components within those devices and across the complete technology lifecycle. This specifically calls out the need for processes and tools to proactively verify the integrity of the supply chain. The document calls out the following phases of maintaining a device inventory.
- Procurement: Identify criteria governing device purchases…may involve the need for specific Trusted Platform Module (TPM) certificates, firmware configuration, or component part revisions. Vendors may list multiple variants or configurations of the same device, but only some may have the necessary components and capabilities.
- Acceptance Testing: NIST SP 800-161 calls for enterprises to adopt acceptance testing as a mechanism to audit supply chain integrity. Software Bill of Materials (SBOM), Reference Integrity Manifest (RIM), and TPM Platform Certificate provide artifacts that establish an auditable chain of custody from the production factory to the receiving organization.
- Deprovisioning: Devices may store protected data within components other than the storage drive. Plan to securely erase storage media, factory reset firmware, securely erase TPM NVRAM memory, reset Baseboard Management Controller (BMC) configurations, remove UEFI Secure Boot modifications, and clean up other organization-specific customizations before retiring a device. Inventory should support status records necessary to ensure safe and secure deprovisioning.
This guidance reveals how device-level security and supply chain security are intertwined. An organization simply can’t understand the security of its assets if they don’t know precisely what should be inside those assets, what actually is inside them, and where they come from.
Controlling Access Based on Measured Risk
A core tenet of Zero Trust is that access should never be granted by default, but based on active evaluation of an asset’s risk. In the context of the device pillar, this means that organizations must have the prerequisite ability to determine device-level risk in the first place. This could be ensuring that all critical code is properly updated or that the integrity of that code has not been altered. Naturally, risk will also need to incorporate any signs of known threats or abnormal behavior. Furthermore, Zero Trust recognizes that security is not a static state and that a device that was verified in the past can’t be blindly trusted in the present. This means that assessing the risk of a device can’t be a one-time event, but must be a continuous process that can identify new risks as they develop.
Ultimately, organizations will need to put this risk context into action. Security teams will need to establish the criteria for what should and should not be allowed on an organization’s network. It could be an overall risk score for a device or based on the presence of a critical hardware or firmware vulnerability. The appropriate policies and responses will naturally vary based on the risk tolerance of each enterprise or agency.
Automated Vulnerability and Patch Management
Most every organization spends considerable effort scanning for vulnerabilities and applying patches. However, the CSI calls out the importance of the system and component vulnerabilities that vulnerability management teams often miss. The document calls out the following:
Organizations must maintain awareness of firmware patches below the software layer. These patches may not be delivered via OS patch managers or other automated patching solutions. Some patches may come from the system vendor, while others may be specific to an individual component manufacturer (e.g., SSD firmware provided by the storage vendor – not the system vendor). There are two general realms of device-specific patches:
1. Fixed System firmware: System vendors collaborate with soldered component vendors to deliver patches to customers. CPU microcode and NIC (network interface card) firmware is usually shared by the device’s manufacturer.
2. Component firmware: Most frequently applies to components with standardized connectors such as storage drives or graphics processors. Individual component vendors provide firmware updates for their specific products.
This highlights multiple important points. First, the complex nature of technology supply chains can make it hard to know exactly where important firmware updates will come from, if at all. For example, from one laptop vendor or model to another, an update may be handled by the OS, be delivered as firmware updates from the OEM, from the chipset vendor, or may need to be downloaded and applied individually by the customer. This makes it very easy for organizations to overlook critical updates unless they have a consistent way of auditing the supply chain security and posture across all their vendors and models.
Secondly, these same issues extend down to the individual hardware and software components within a system. In addition to keeping the system BIOS or UEFI firmware up to date, teams must be able to find and address weaknesses in a device’s SSD, network controller, PCIe controller, or dozens of other components. This is again an area that will almost certainly be missed by traditional scans and will need to be handled by a supply chain security platform.
Threat Detection and Response
With all this focus on securing the device layer, it is important to remember why it has become such a priority. In short, attackers have recognized the device layer as the weak link in many organizations. Adversaries have targeted network devices as initial access vectors that can then be used to spread within an organization. On laptops and servers, low-level implants and backdoors can be used to maintain long-term persistence while evading more traditional protections. The device pillar CSI calls out the following:
In addition to the more common high-level threats to operating systems and application software, ZT capabilities must defend systems from persistent and hard-to-detect threats against devices. Past examples of low-level, persistent threats include:
- LoJax boot rootkit
- MosaicRegressor firmware implant
- UEFI Secure Boot bypasses BootHole and BlackLotus
- Side channel vulnerabilities such as Spectre, Meltdown, Fallout, ZombieLoad, NetSpectre, Downfall, and Inception
- SSD over-provisioning malware
This is yet another area where organizations can have gaps. Most security teams lack any visibility into threats on non-traditional devices such as network devices, security appliances, or server BMCs. And while traditional EDR/XDR tools can look for threats, they often rely on the host operating system for information. A threat residing below the OS can easily provide false information up to the OS or disable protections entirely. Yet another area where firmware and supply chain security tools can close a critical gap.
These are some of the key ways that Zero Trust intentions turn into Zero Trust practices at the device level. And as the NSA doc calls out, the device pillar of Zero Trust requires organizations to dig deeper into their devices than they may have in the past. The good news is that new security tools are available that can make this a simple, highly automated process. That is our mission at Eclypsium, and if you would like to learn more, please contact the team at [email protected].
For further reading please check out the following assets:
