What Zero Trust Definitions Get Wrong – And How to Make It Right
Years ago, I had a car that wore a badge representing the worst of misleading marketing. The silver, 3-dimensional logo spelled out the acronym PZEV which stands for Partial Zero Emissions Vehicle.
If your initial reaction is that this sounds oxymoronic, you have good instincts. In this case, the description is surprisingly accurate.
The problem is that this advertised feature is essentially worthless. What this misleading term and prominent badge accurately describe is a vehicle that has a pollution emitting internal combustion engine as it’s only source of propulsion, but it doesn’t emit any pollutants when THE ENGINE IS TURNED OFF.
A more honest badge would be PGG to indicate that they used Pretty Good Gaskets in the fuel system to prevent emissions from the evaporation of gasoline. Still, the basic problem is that partial zero is non-existent and oxymoronic.
I hate to be the heretic here, but I can’t help noticing that zero is well defined:
0.1 is not zero.
Neither is .0001.
Even 0.0000000000000000000000000001 is non-zero.
Zero Trust and the principle of least privilege
Now let’s switch from cars and basic arithmetic to computer network security.
A key tenet of Zero Trust network security (and no it is not a “tenant”) is that it must implement the principle of least privilege which includes in its definition that there must be zero excess privilege. Least privilege, or the absolute minimum privilege required for a transaction to work correctly, is not the same as less privilege which is necessary and laudable but not sufficient to establish Zero Trust.
A simple example of the issues here involves a network resource that exposes a web page on port 80 of IP address w.x.y.z. Blocking access to all ports other than port 80 is a big step in the right direction. However, this still allows any client address to access this port when only certain users really need to be allowed. That is excess privilege which can be eliminated by only allowing certain client source IP addresses.
But this then leads to a scenario where authorized users can try to reach all resources exposed on port 80 and can do so for both GET operations that are part of the intended use case and, for example, PUT operations, which are not. Restricting access further to prevent PUT operations and only allow GET to a single specific web resource are the final restrictions that get us to minimum working privilege (MWP), the least privilege required to implement the intended use case.
MWP is the least-privilege configuration achieved for a given use case. Each of the subsequent behavioral restrictions described above reduces attack surface and moves closer to MWP, but it is only when the last of the excess privilege is removed that we can talk about having implemented Zero Trust.
Zero Trust isn’t a journey – but the work to get there is
And this leads us to the common assertion that Zero Trust is a “journey” which seems to imply a nonsensical state of partial Zero Trust. It’s common to hear discussion of “levels” of Zero Trust as if there is a spectrum of Zero Trust security postures one can travel across.
Zero Trust is not a journey, it is the destination.
When people mention the Zero Trust “journey,” what they actually mean is that the work to achieve Zero Trust is a journey. Steps toward this destination are useful and important but must be differentiated from achieving the end goal that is Zero Trust.
It is true that exaggeration and loose terminology are part of any industry, but in certain cases, they go too far and mislead in a way which can do long-term damage, especially in cybersecurity. The big risk for security is that it leads to a relationship with a vendor or solution that can move you closer to Zero Trust but has no plan or ability to take you all the way to the destination.
It is impossible to have partial zero anything.
Zero Trust is about freedom and safety. If applications consume network services that implement Zero Trust, those applications do not have to include complex, fragile logic to defend themselves against bad actors. Their Zero Trust infrastructure platform has guaranteed that those risks have been eliminated.
Zero Trust: The minimum possible attack surface
As an example, when you are in a U.S. courthouse, you can be assured of your safety because there is a single entrance with a magnetometer scanning each person who enters, ensuring that nobody has brought anything malicious inside (Zero Trust). If there is another entrance without such security measures (reduced attack surface) then the lack-of-threat guarantee cannot be supported, and everyone needs to be concerned about their safety. In this scenario of two entrances, the fact that most people (the ones without anything malicious) go through the secured interface does not mean there is no safety.
The difference between a reduced attack surface and Zero Trust (minimum possible attack surface) is whether it allows the freedom to not worry about self-defense. Only true Zero Trust can allow application developers to leave out defensive capabilities in their application, thus reducing cost, complexity, and time to market.
Many vendors will sell you a solution that can make you more secure than you are now, and that has some value. But it is important to understand how you need to get to the Zero Trust destination and whether they can take you there.
We can think of Zero Trust as a security posture that is the best we can possibly have, given that we must allow some network interaction to deliver the service benefits. It is possible to attain this definition of Zero Trust from some of the security solutions available today.
For certain network-based applications and services, the cost of deploying such solutions will be much smaller than the cost of deploying without them – the cost of a breach. A great place to start this analysis is understanding what the minimum working privilege for your applications is.
Application owners will need to understand security requirements for their application to determine how Zero Trust is cost-effective in overall business terms. But as the cybersecurity environment evolves and becomes more sophisticated, organizations will find they can’t afford not to employ Zero Trust because just implementing less trust isn’t good enough.
Illumio Zero Trust Segmentation helps you achieve Zero Trust
While Zero Trust is a security strategy – not a specific product or solution – Forrester validates Zero Trust Segmentation (ZTS), also called microsegmentation, as a foundational and strategic pillar of any Zero Trust architecture. ZTS doesn’t promise to help you reach complete Zero Trust, but it is a critical technology for Zero Trust.
ZTS assumes breaches are inevitable and prepares for them by segmenting the network and establishing least-privilege access. When breaches happen, ZTS helps contain their spread by stopping lateral movement across the network.
The Illumio ZTS Platform is the industry’s first platform for breach containment across the hybrid attack surface.
With Illumio ZTS, you can:
- See risk: Continually visualize how workloads and devices are communicating
- Set policy: Set granular policies that only allow wanted and necessary communication
- Stop breach spread: Automatically isolate breaches by restricting lateral movement proactively or during an active attack
What is ZTS? Read more here.
Contact us today if you’re ready to learn more about ZTS and how it fits into your Zero Trust strategy.