Demystifying Zero Trust

There are two truths about Zero Trust, it’s a fundamental architectural approach to securing an environment, and no one really understands it. I absolutely share the blame here because in my time at Forrester we tried to map everything to Zero Trust to the point we even had to create a certification course to explain it. But let’s be honest, it doesn’t need to be that hard.

Let’s start to understand Zero Trust conceptually

The first step in understanding Zero Trust is to start thinking about it conceptually. A good reference is the OSI Model, a conceptual model which outlines the construction of network traffic into a stack based approach. One way to think about how Zero Trust is implemented would be to validate every level of the OSI Model for every connection while terminating any connections that failed any level of validation. Network operations will likely tell you the OSI Model is just a reference and you really only need the TCP Model to understand encapsulation, and I’d hardly disagree, but now that we’ve established what a stack based approach to security architecture looks like conceptually, let’s build one for Zero Trust.

What are the building blocks of a Zero Trust architecture?

One of the foundations of application security is that you can never trust a client. As infrastructure hosts, it’s helpful to think of Zero Trust in terms of monitoring connections from the perspective of a hostile client, but you must do so inductively. This means that any time a connection is being established it must be validated, whether it’s someone connecting to your web server, your web server connecting to your database server, or any other connection that happens in the course of business. A good way of understanding the data you need to validate connections involves answering the questions who, what, where, why, and how:

• (What) Is there a business need or context for this connection to exist? The simplest way to look at this is, to ask if this connection has existed in the past and if it has any reason to exist today. Behavioral modeling and role based access control are critical components to validate this level.
• (Who) What is the identity of the user requesting access? Identity is a necessary, but not sufficient control for Zero Trust. Keep in mind that identity is an assertion and does not preclude compromised credentials and/or an insider threat. The way you implement identity checks can be as important as *that* you implement identity checks. There’s a lot of discussion about passwordless and stepping up authentication that can fit into this section, but for the purposes of this blog, let’s assume you’ve validated the identity of the user/process that’s requesting access to resources.
• (Where) Can we establish the integrity of the host initiating the connection? While this context could have come in second or third in this list, I’ve decided to prioritize it after identity because in a lot of ways it’s contingent on identity and you can’t always satisfy this control. Many VPN solutions, and even endpoint protection solutions, provide the capability to satisfy this requirement for your corporate users, but Zero Trust also very much applies to web users who may have application credentials they are supplying without domain credentials. In this particular case you’re unlikely to be able to establish they are connecting from an uncompromised host… but you can’t drop the connection based on this failed context for obvious reasons.
• (Why) Is the content of the connection sane? A classic example for why this is important is to monitor for exploitation such as SQL Injection, but insider threat is something that should always be top of mind. There’s a saying that after initial compromise, every adversary is an insider threat… even if everything else checks, does the user behavior align with things we think they should be doing?
• (How) Do the applications on both sides of the connection make sense? Is this a web browser connecting to a web application? Is this a web service connecting to a database? Aside from validating that a particular system should be able to interact with another, it’s important to validate the method of interaction as well.

The trick is, Zero Trust doesn’t really start becoming “zero” trust until you can establish the validity of each of the above contexts pertaining to a connection. This is why it’s craven for an identity provider, or an endpoint security company, to sell you a ”Zero Trust solution” that only satisfies one part of this (meanwhile continuing to contribute to confusion about what exactly Zero Trust requires). Hopefully, this blog has helped to illustrate what a Zero Trust solution is and you can evaluate your own ability to validate connections based on these contexts.