Zero-Trust is an Adjective Without a Noun

People love to talk about zero-trust right now, for a number of reasons. It has the word “zero” in there, which has some history in the information security world (e.g., zero-day vulnerabilities). It’s also a simple and eye-catching phrase, so it fits well into product marketing exercises. Selling “zero-trust” as a solution suggests that all of your problems will just go away—your world is going to be super easy as soon as you don’t have to worry about trust anymore.

And that’s really the reason the term zero-trust bothers me. Because when it’s used by itself as its own noun—instead of as a modifying adjective to describe something else—then it’s essentially a false promise. Realistically, you can never have an environment without trust. In the most literal sense, achieving zero-trust would give you zero interactions—and nobody really wants that. Any networked organization needs to have some trust to function.

So what most people mean when they say “zero-trust” today is really the removal of implicit trust—because that’s what typically gets exploited. The classic example of this is a virtual private network (VPN). Let’s say I’m a remote employee. I connect to a VPN, it gives me an IP address on that other network, and I can then go everywhere that network allows me to go. That’s a lot of implicit trust, and attackers love to abuse that kind of freedom.

So, we need to start having conversations about new ways to reduce the risks that currently exist as a result of too much implicit trust—without a knee-jerk reaction in the opposite direction of a “no-trust-at-all” lockdown.

Context is the New Perimeter: Continuous and Adaptive Trust

When thinking about zero-trust networks, if we take away all of the implicit trust that comes with having an IP address and instead apply principles of continuous and adaptive trust, then we can start giving people access to only what they need, only when they need it and nothing else.

To get anything done, we need people to interact with resources and data. But that interaction doesn’t have to be all or nothing. Modern security should be able to give us the ability to continuously evaluate how much trust a user should get for each interaction based on a variety of contextual information. Not just who the user is, but also variables such as the quality of their device, where they are in the world and the sensitivity level of the data being requested. For some time, it’s been fashionable for folks to say, “Identity is the new perimeter.” Any project that aims to reduce implicit trust starts with a solid identity and access management (IAM) foundation. But in reality, identity is just one point in an array of contextual elements needed to effectively assess and grant trust.

Identity is pervasive. We can easily know who the human user is. We almost always know what the device is—if it possesses its own identity that we can verify. We can always know which applications and services are involved because they also possess identities. But it’s not enough for me to just authenticate to an app. The app also needs to authenticate to me, too, so I know I’m not interacting with something attempting to spoof my corporate secrets. (This is the idea behind identification and mutual authentication.)

So really, context is the new perimeter. If we can look at all of the contextual information surrounding an interaction, then we can make an intelligent decision about how much trust to extend under specific, confirmed circumstances. At the same time, we need to be able to continuously evaluate those conditions. If something within the context changes, then the trust level of these interactions may also need to change.

For example, if an administrator is performing an administrative function within a fairly normal set of circumstances (e.g., time, location, device), then they are allowed to perform a not-so-common admin function. But we don’t implicitly give them admin rights all the time—we elevate their privileges only when they’re performing admin functions in low-risk contexts. Another example would be an employee traveling in an area of the world that may be risky for certain types of data. If the user’s interaction begins with relatively innocuous data, that’s fine. But if they then move to interact with data that is confidential intellectual property, then, based on their physical location, we’re going to reduce their access to read-only in a browser—or maybe even restrict their access entirely.

People-Centric Security

The old ways of thinking about perimeters are no longer useful. In a modern, hyper-connected world there’s no longer a single data center, but instead, many centers of data. We need to implement mechanisms that can automatically assign just enough trust for the specific situation. Policy should follow the data no matter where it goes—and it should aim to offer the maximum access possible within the context of the business requirements. As part of this, the infosec team needs a modern makeover—from the “Department of No” to the “Department of Yes.”

While the simplicity of absolute zero-trust is enticing, the concept needs to be applied to something that’s a bit more complex—and ultimately more useful—for reducing risk in the real world. If it’s implemented correctly, a continuous adaptive trust model offers a truly people-centric approach to security—giving the right people the right level of access to the right information at the right time.

Avatar photo

Steve Riley

Steve Riley is a Field CTO at Netskope. Having worked at the intersection of cloud and security for pretty much as long as that’s been an actual topic, Steve offers that perspective to field and executive engagements and also supports long-term technology strategy and works with key industry influencers. A widely-renowned expert speaker, author, researcher, and analyst, Steve came to Netskope from Gartner, where for five years he maintained a collection of cloud security research that included the Magic Quadrant for Cloud Access Security Brokers and the Market Guide for Zero Trust Network Access. Before Gartner, Steve spent four years as Deputy CTO of Riverbed Technology and held various security strategy and technical program management roles at Amazon Web Services for two years and at Microsoft for eleven years. Steve's interest in security began all the way back in 1995, when he convinced his then-employer that it would be a good idea to install a firewall on their brand new internet connection.

steve-riley has 1 posts and counting.See all posts by steve-riley

Secure Guardrails