Skip to main content
Exploring what’s next in tech – Insights, information, and ideas for today’s IT and business leaders

Constant scrutiny is the key to making zero trust happen

Zero trust is probably impossible to implement on most current hardware, and new software systems are necessary for it.

How do you actually make zero trust a real thing? When you think through how you would make it happen today, the tools at your disposal fall short of the task. But new systems with new capabilities are being designed and built.

Even if zero trust is a tall order, the need for it has reached consensus among even the highest authorities. President Joe Biden, in his May 12, 2021, Executive Order on Improving the Nation's Cybersecurity, ordered that the U.S. government "advance toward zero trust architecture," among other measures for adopting security best practices.

What is zero trust?

That same executive order contains an excellent definition of zero trust architecture, in section 10(k). It's worth reading in full, but relevant portions start at the beginning: "The term zero trust architecture means a security model, a set of system design principles, and a coordinated cybersecurity and system management strategy based on an acknowledgment that threats exist both inside and outside traditional network boundaries." There is a good chance that systems on your own network trust systems inside the virtual private network (VPN) or in the data center. Zero trust is an admission that this is a mistake. There can be and almost certainly are malicious software and actors working inside the VPN and data center. How then do you decide whether to allow another user or program access to a resource?

Please read: Application and data security start in the supply chain

The answer is that it has to be able to demonstrate its bona fides. Nigel Edwards, a Hewlett Packard Enterprise Fellow and vice president, puts it this way: "If you're going to do security properly, you have to know that when you power something on, it starts in a good state." The most fundamental demonstration of this type is for the computers themselves, and so for zero trust to be a credible posture, the computers must demonstrate they boot in a known good state. The way you do this is with a hardware root of trust, such as Hewlett Packard Enterprise's iLO 5 silicon root of trust. Standards from NIST detail how to implement hardware roots of trust.

Once you can demonstrate that the system powers on in a known good state and that it has not been modified in an unauthorized way, it can begin to load software, such as the BIOS, and there are standards to allow the system to see that the BIOS is unmodified and for the BIOS to see that the system is unmodified. The BIOS performs the same kind of check when loading the operating system, and the OS when loading applications.

But with zero trust, these checks are performed continuously and not just for the big decisions, like whether to load the operating system, but for any operation in which a program attempts to access a resource, such as making an API call within the same network. The monitoring process must verify and attest to the fact that the system is still in a good state.

Critically, to be reliable, these checks of system integrity must be performed by a process outside of the systems they are checking. For instance, a process running on the same CPU as the system being monitored cannot reliably determine whether the operating system kernel on that system has been compromised.

Automation is mandatory

As the executive order puts it, "Zero trust architecture embeds comprehensive security monitoring; granular risk-based access controls; and system security automation in a coordinated manner throughout all aspects of the infrastructure in order to focus on protecting data in real time within a dynamic threat environment." Such a continuous flood of verifications for anything to access anything else could only be practical if it is built into the network and automated.

Please read: Why healthcare is such a juicy ransomware target

The process of determining whether a server system is in its proper state must be automated, and the complexity of many of today's mass-malware and more sophisticated Linux malware toolsets like Drovorub are dictating to enterprises that this needs to include automating security at every layer from the silicon to the firmware, hardware, OS, platform software, and up to the application workloads. The delivery of error information to the appropriate authority, human or software, must be automated. Eventually, even much of the error handling will need to be automated.

By the same token, the system must allow administrators to designate changes in system state as valid. They must be able to say that they are upgrading a storage controller or applying patches to the operating system and applications, and that the changes are legit and not to be flagged as problems. The imperative for such solutions only gets more urgent as data moves between the edge and the cloud, potentially to systems that are less physically secure than those in the data center. Consider a digital kiosk in a store or an intelligent seatback display on an airplane, where someone manages to insert a USB key. The detection of that event and its flagging for remediation must happen automatically and reliably.

It's the dawn of the era

The hardware necessary to implement a true system of zero trust is with us and has been for years: roots of trust, Trusted Platform Module (TPM), and intelligent onboard controllers that can perform the security evaluations and attest to their findings.

The software necessary to build such protection is now being developed. Today's software stacks are complex and deep, and applications often run at a level that is completely portable and abstracted from the hardware. But for zero trust to work optimally, information on the hardware state will need to be available to controlling software to, for example, halt a workload running in a container on a Kubernetes cluster because the hardware it is running on is now suspect. Kubernetes can then move the workload elsewhere.

One way to do this could be SPIFFE (Secure Production Identity Framework For Everyone), a set of specifications that, among other things, defines an API to easily establish trust among workloads and system actions. Because it's API-based, unlike manual key generation and distribution processes, SPIFFE attestation and authentication can be fully automated. "SPIFFE puts in place the underpinnings for enterprises to utilize existing on-premises service authentication protocols [such as Kerberos and OAuth] with workloads running upon increasingly dynamic computing platforms, including cloud and containers," says Sunil James, senior director of security engineering at HPE.

Please read: Enterprise security moves to the edge

A related effort is SPIRE, the first software implementation of SPIFFE. SPIRE's components can be integrated with call providers, middleware layers, and hardware trust mechanisms such as the Trusted Platform Module and hardware security modules. SPIRE can be used by workloads in any environment, such as within Azure, Kubernetes, or an application running in the data center.

It's possible to see how the problem of enforcing zero trust in complex, modern software systems will be conquered, but obviously a lot of work needs to be done for that to happen. It does need to happen, because only then will we have a framework for stopping the attacks that plague us with a better degree of success.

Enterprises are spreading their data from the edge to the cloud and must protect it, wherever the data was generated and wherever it may go. The only workable model to implement zero trust is a distributed one. To quote the executive order once more, "This data-centric security model allows the concept of least-privileged access to be applied for every access decision, where the answers to the questions of who, what, when, where, and how are critical for appropriately allowing or denying access to resources."

Lessons for leaders

  • Without full trust in the hardware and system software, zero trust is not possible. New approaches will be necessary for it.
  • So many decisions are required that only a fully automated system is practical for implementing zero trust.
  • Security experts generally understand zero trust to be the goal toward which IT must strive, and even the federal government is officially committed to it.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.