Zero Trust for Enterprise Hardware

Zero Trust for Enterprise Hardware

Once firmware has been identified, Eclypsium makes it easy to verify the security posture and integrity of firmware within enterprise devices. The platform automatically reveals devices with outdated or vulnerable firmware or misconfigurations that could put the device at risk. Next, Eclypsium can automatically verify that firmware has not been unexpectedly altered or compromised by either known or unknown threats.

InfoSec practitioners think of the “Default deny” concept as an authentication issue. In the broadest sense, it is. But we need to look past the act of “authenticating” an entity, whether user or device, using traditional authentication factors. If authentication means “corroboration of a claimed identity,” then we must corroborate all the associated parts of that claimed identity, including, if applicable, the bare metal hardware, its various components, and the underlying, embedded firmware that instructs it on how to run and ensures it has not been tampered with.

The principle of “default deny” suggests that firmware that is not correctly signed or configured or certified should not be allowed to run, and should, in turn, prevent the device it serves from booting.

The concept of “contextual authentication” has a unique application with regard to firmware. Contextual authentication suggests that “An authentication granted yesterday may not be allowed to work today if the level of detected risks or vulnerabilities has changed.” In a firmware-centric example, if a device attempts to connect to a network, a security assessment should include hardware- and firmware-level review of not only vulnerabilities, but also anomalies and misconfigurations. If the device contains a firmware version that has recently been shown to be highly vulnerable and an invitation to exploits, this authentication request should be denied.

A recent example of this sort of firmware vulnerability can be found in CVE-2019-3707 where multiple vulnerabilities were discovered in firmware supporting Dell systems and their ability to use Dell’s proprietary remote access capabilities. The practice of contextual authentication suggests that a Dell device containing one of the affected firmware versions should be denied access to the network, even if it was allowed access the previous day.

Every laptop connecting to a network contains 10-20 unique firmware components. Every server contains 30 or more. Every network device or switch has its own embedded firmware or microcode.

It’s no longer enough to simply acknowledge, “every device has firmware.” In fact, every component of every device — from the ubiquitous Unified Extensible Firmware Interface found in nearly all computers to on-board memory and from networking components to video drivers — has its own firmware. In an effective Zero Trust implementation, every one of these components should be assessed for its integrity and lack of vulnerabilities. At the very least, practitioners should have a complete inventory of the firmware components and versions their systems rely on.

Creation, deployment, maintenance, and replacement of hardware has evolved to be a continuous rather than periodic exercise. It’s now done on-demand and practically in real-time. In the virtual world, servers are spun up and down by the thousands and in a fraction of a second. This should include checks on their underlying, real-world firmware.

To support digital transformation, every device in a business network should be considered dynamic, possibly ephemeral, and we should expect it to be constantly changing. Static or infrequent inventories cannot secure and assure the integrity of these devices — including their millions of lines of firmware.