The concept of zero trust has been around since 2010, when Forrester Research analyst John Kindervag created the zero trust security model. Yet two years after the devastating Colonial Pipeline attack and strong advocacy from the U.S. government and others, we are still no closer to seeing zero trust architecture widely adopted.
The only exception, it seems, has been cloud service providers, who boast an enviable record when it comes to cybersecurity, thanks to rigorous security practices like Google’s continuous patching.
As security breaches continue to happen hourly, sooner or later zero trust requirements are going to be forced upon all organizations, given the impact and cost to society. The Biden Administration is already pushing ambitious cybersecurity legislation, but it’s unlikely to get very far in the current Congress. I am very surprised that the cyber insurance industry has not required zero trust architecture already, but perhaps the $1.4 billion Merck judgment that went against the industry last week will begin to change that.
The central question is, can any organization implement a full zero trust stack, buy hardware and software from various vendors and put it together, or will we all have to move to cloud service providers (CSPs) to get zero trust security?
Old arguments that cloud profit margins will eventually make on-premises IT infrastructure seem like the cheaper alternative failed to anticipate an era when security became so difficult that only cloud service providers could get it right. That has enormous implications for the future of IT, which we’ll explore.
The 7 Tenets of Zero Trust
Both NIST and the U.S. Department of Defense (DoD) have published guidelines on zero trust requirements. The NIST guidance can be found here.
NIST has 7 tenets of zero trust. We’ll go over them briefly here but the details can be found on page 16 of the document.
- All data sources and computing services are considered resources.
- All communication is secured regardless of network location. Network location alone does not imply trust.
- Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before the access is granted.
- Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.
- The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted.
- All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
- The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications, and uses it to improve its security posture.
Below is a picture of the NIST stack from DoD:
The DoD document is very good, as it defines specific requirements and implementation. The document can be found here. A good example of workflow can be found on page 28:
The U.S. government has done a great job leading in this area up to this point, similar to the 1980s when the government helped lead the POSIX standards for common application interfaces.
Zero Trust is ‘Very Complex’
Needless to say, zero trust is very complex. Everything needs to be tracked and authenticated, starting with users, both standard and higher-privileged users. Networks need to be segmented and authenticated. Supply chains need to be validated. Encryption needs to be done for the environment, and that means that key management is another very complex process.
All of this has to be tracked, and policies need to be dynamically implemented for networks and systems. What if a new job runs and uses resources in a different way and takes your whole system down, as the policy manager thinks the new job is an intruder? This could easily happen. Add to that the complexity of third-party reliance, like what if one of the software packages you use for say multi-factor authentication was hacked (think Okta) and someone was able to enter your system, circumventing the zero trust border.
All of this is incredibly complex and requires a large IT staff and a test environment for any big organization. Maybe big banks and healthcare systems can afford to do this because they can’t afford not to, but smaller companies and those with less critical IT needs often cannot financially afford to do this.
Examples of those that needed zero trust include critical infrastructure like Colonial Pipeline, various school systems, and state and local governments around the world that have been hacked and have impacted all of us. Even the local public schools near where I live have been hacked. Given the complexity of the systems needed to accomplish the workloads in our complex world, how can any small organization afford the IT staff and hardware resources to implement a zero trust stack?
Of course many, if not most, of the hacks done today are simply someone going to an email link that they should not have clicked on, but that too is part of zero trust, and hackers are upping their game and getting more sophisticated daily. If a school system, for example, was going to build a zero trust stack, they would need to integrate all the tenets of the zero trust stack for all hardware and software and implement multi-factor authentication across the environment. I have a cousin that is the IT administrator for a school system and he does not have the budget or resources to even consider this, and luckily his systems have not been hacked as of yet.
Also read: Zero Trust: Hype vs. Reality
What About the Cloud Service Providers?
Cloud service providers (CSPs) have a huge advantage over traditional hardware (server and network) and software vendors for a number or reasons:
- There is a single software stack that they control and, for the most part, they write themselves that can be integrated for monitoring. They do not have to have network monitoring, multi-factor monitoring, OS monitoring, etc., and they integrate, coordinate and correlate things themselves.
- The hardware stack is controlled by the cloud service providers. For the most part the CSPs build their own hardware and they’ve even been building their own CPUs. They build their own network devices, NVMe SSDs and motherboards. They control the firmware, the signing, and the supply chain. Everything is integrated by the CSPs.
- The entry points are monitored closely. When you connect to a CSP, everything is monitored by the cloud service provider. If you have a breach, they might know it before you do because if there was anomalistic behavior, they would see it first.
Yes, cloud service providers likely cost more than owning your own IT infrastructure, but with that cost comes much greater security than most organizations can afford or ever hope to achieve, so the cost difference may no longer be as great as it once was. Have the CSPs been hacked? Yes, but the last major breach was the 2009 Chinese hack of Google. There have been no publicized large hacks of CSPs since then, other than hacks that started by getting into customer sites then into the CSP or databases left open by a CSP customer. Of course there could be things we don’t know about, but Colonial Pipeline-like breaches have not happened in CSP environments as far as we know.
Also read: Building a Ransomware Resilient Architecture
What All This Means
From my vantage point (semi-retired and with lots of time to think, I might add) all this means that one of two things needs to happen.
- The current group of hardware and software vendors needs to get together and create a zero trust environment that is integrated and secure and that can be implemented by anyone and everyone, from each of our home PCs to SMBs to large corporations. There must be testing environments for businesses and organizations, and budgets must be defined to ensure that testing can be done for upgrades and new workloads. Some of the most difficult things to do will be the development of a test suite for workloads that will emulate the customer’s current and future workloads and ensure that automatic policy generation does not needlessly shut things down.
- Or every one should move to the big cloud vendors who have zero trust stacks and have all kinds of workload generators and likely have policy management systems that have seen current and future customer workloads.
There is no middle way, with apologies to the Buddha. The current state of affairs cannot continue; something will give.
If zero trust is a future requirement, and I think it is, the traditional commercial off-the-shelf (COT) on-premises vendors are all going to have to get together to develop a zero trust stack. That means — and is not limited to — hardware vendors (network, server, storage, firewall, etc.), OS vendors (both Linux and Windows), software vendors (multi-factor, metrics, policy, etc.). This is a huge integration task, and on top of that a workload emulation system must be created.
Some big on-premises organizations such as financial services, healthcare and others have the requirements and resources to do this on their own, but smaller organizations do not, and many of them have been and will be attacked. To me the alternative is clear, that if zero trust is a requirement, the CSPs are far ahead of the COTs vendors, and the COTs vendors need to work together to develop standards and a framework that works across all platforms. This is a large investment that the CSP vendors seemingly have made.
Security Ain’t Free
Security does not come for free and you get what you pay for. I am somewhat surprised that cloud service providers don’t tout their security advantages more than they do, and I am equally surprised that the COTs vendors do not band together faster than they have been to work on zero trust. But what surprises me the most is the lack of pressure on everyone to move to zero trust and get a leg or two up on the current attack techniques and make the attack plane much smaller than it is. I am waiting for the insurance companies to mandate zero trust for the organizations they insure. Perhaps with the Merck ruling, the cyber insurers finally got the financial incentive to do so.
