Typically, when we hear “zero trust” these days, folks generally hear the common example of remote employees not having to VPN (Virtual Private Network) back to their enterprise network to access the cloud resource. The example has struck a chord with many, as the term zero trust quickly spiraled into a fancy buzzword. Like any good buzzword/phrase, zero trust has had much of the original technical meaning removed through fashionable use and is seemingly sometimes used simply to impress others. The VPN example is most likely the most referenced example of zero trust and, also, I believe, the most important but also the most misunderstood. I’ll expand on why I believe this to be the case, but before we do, some context is required.
Don’t get me wrong, the concept of trusting the perimeter is fairly old-school/outdated and does come into conflict with more modern “cloud native” approaches. Remote users will also have issues with latency, especially if you require the users to VPN to your on-premises network and finally establish connectivity with the cloud. The theoretical modern approach is to not trust that perimeter. This doesn’t mean you have to get rid of it, but rather it’s not the default, since increasingly the perimeter is becoming more porous and ill-defined. This is as opposed to when moving to a “zero-trust” model, where everything needs to be proven for both the user identity and device prior to any data, application, assets and/or services (DAAS) being permitted to communicate to any services.
Going further down memory lane, back in the day the perimeter used to mean that everything was located within your “castle” and perimeter-based system access was “all or nothing” by default. Once users were in, they were in, which also applies to any other type of actor, including malicious actors. Once the perimeter was breached, the malicious actor effectively had unlimited access to everything within the perimeter.
Zero trust is all about layers, vectors and, most importantly, levels of risk. As most folks can related to the “Castle/Kingdom/King” analogy, we’ll continue the analogy a little more. In zero trust, we not only protect the kingdom (larger/greater network) with an army (firewalls, client protections, policy), we protect the castle (data center/stores) with fortifications and specialized guards, and we protect the king by limiting access to him from untrusted actors. In a nutshell, the army prevents the rush of the castle. The castle itself is fortified and inherently robust, and those you do let in the castle are vetted and limited in their abilities to roam the castle (segmentation).
Zero trust significantly reduces the likelihood of a malicious actor attempting to do any type of harm to the king, as he could not simply climb the perimeter/fence or swim across the moat, walk right through the front gates and confront the king himself. The malicious actor would have to get access to the kingdom, avoid the finite army, the castle, and finally, get to the king. Not to mention, at every step of the way, the malicious actor would be required to have his tools (or whatever he’s using to traverse the network) and himself be authenticated and authorized. All authentication and authorization would be risk-based/justified, just in time and just once. So, if the malicious actor and his tools fail authentication and authorization, he will either be denied access, highly restricted in access to other areas of the kingdom or sent to a honeypot.
Let’s say our malicious actor has somehow managed to steal some credentials – in a ZTA model, lateral movement is much harder as each service must be authenticated and the perimeter/internal network is not inherently permissive. Stolen credentials are now less valuable due to strong authentication requirements that increase the cost of credential theft and man-in-the-middle attacks.
In the case of a known vulnerability, exploitation of the vulnerability will be rarer due to the increased hygiene of the entire ecosystem. Subsequently, this makes non-targeted attacks have much less value to the attacker. Focused targeted attacks result in higher costs to the attacker. Effectively translating to every endpoint essentially having its perimeter or “deperimeterization”.
As described within ISACA’s recent white paper, How to Beat Adversaries at Their Own Game with Zero Trust, “Deperimeterization is a concept/strategy used to describe protecting an organization’s systems and data on multiple levels by using a mixture of encryption, inherently secure computer protocols, inherently-secure computer systems and data-level authentication rather than the reliance of an organization on its (network) boundary/perimeter to the Internet.”
Ultimately, the zero-trust model is a repackaged and evolved form of a least privilege model, only this time, the model is incorporating intelligent micro-segmentation using multiple layers and technologies organization-wide. This doesn’t mean the VPN is dead nor “zero-perimeter,” it just means data is secured end to end through a multilayered authorization process. Multiple tools and technologies are required to meet all aspects of zero trust. A zero-trust model is ultimately meant to protect your data and assets from compromise internally and externally, or wherever it resides. Or, in the words of John Kindervag, who coined the term “zero trust,” “never trust, always verify.”
With all the context and history provided, as promised, let’s circle back around to my earlier statement of why the VPN example is the most important but also the most misunderstood. If the reasoning is not yet clear, simply put, the VPN example illustrates the false dichotomy of the implied statements “You cannot have a VPN with Zero Trust,” and “Either you implement ZTA without VPN, or you don’t.”
Let me be clear – I’m not advocating for VPNs. I’m simply underscoring the importance of why knowing the nuances is critical to having a complete understanding of what ZTA is and is not. Firewalls and VPNs gave people a false sense of security, leading to poorly designed apps, hosting systems and networks. In other words, it created trust when there really wasn’t any. If you take zero trust as assuming that nothing is trustworthy unless proven otherwise, then you just need to consider how to build trust in every component and every step of the process. Arguably, how you do that is not the definition of zero trust – it’s the outcome that is the definition.
