Zero Trust Series Part 1: Why Data Protection is the Keystone for ZT

Zero Trust has a nice ring to it, in a firm and sort of non-compromising way. Not only does it sound serious, it sounds pretty final too. I mean, if you’re chastising somebody (like a wayward teenager) and say, “After this, I have zero trust in you, son!” Well, that sounds pretty firm and really definite. Sorry, son, you’re simply not getting the keys to the car, and that’s final.

This blog post is the first in a series of pieces focused on the increasingly popular Zero Trust cybersecurity framework and data-centric security.

If you’re in cybersecurity (or perhaps more generally in IT), then you’ve at least heard the phrase Zero Trust (or ZT). If you don’t delve into the specifics of it (reading the many white papers and position pieces on ZT), you might wonder whether the concept is more of an obstacle to the free flow of data within the enterprise, akin to the IT overseer in Scott Adams’ Dilbert comic strip, whose negative proclamations and mandates do more to stop productivity than encourage it. If we have zero trust across the network, doesn’t that mean we don’t share any data or services with anybody or anything? So much for the free flow of information…

Sponsorships Available

Sponsorships Available

Sponsorships Available

Of course, that would be a ridiculous framework to implement, so you have to dig a little deeper than just the name to understand what Zero Trust is and why it might be a valuable framework to adopt, at least in part. Oh yeah, that’s what ZT is, by the way—it’s a suggested framework for a generic IT architecture that takes a different spin on the extension of privilege to entities trying to access data or services within your IT environment. But I think I’m getting ahead of myself, so let’s try to define it using the simplest concepts possible.

Zero Trust is at its heart a collection of IT security design principles attempting to reduce or eliminate the chances of the wrong entity (we’ll use the term “user” or “device” from now on) getting a hold of vital information or resources possessed by your organization. NIST, which is the National Institute of Standards and Technology in the US, has some great resources about ZT and provides some equally helpful definitions. According to NIST, ZT at its core removes any implicit trust or privilege which might be granted to users or devices based on where those people/things are physically or on the network (NIST Special Publication 800-207).

In most IT architectures in the past (and present, actually), a user or a device, once validated or authenticated, receives a set of privileges allowing for unchallenged access to a subset of data or resources. This is actually a dangerous posture to take, because it forces a single decision point, which if successfully accomplished enables more unfettered access on the network. You might be thinking, so what’s wrong with that? Well, it means rather than surmounting any number of challenges with increasing chances that authentication fails, all a person or device has to do is overcome one. I think of Sir Lancelot in Monty Python’s Holy Grail movie, whose single decision-point challenge in order to cross the Bridge of Death comes down to giving his name, what he wants, and what his favorite color is. Shockingly easy, and then he’s off and traversing the bridge to do whatever he wants on the other side, with no more challenges concerning what he’s really up to. That’s all fine and good, if we’re talking about the brave Sir Lancelot, but not everybody accessing your enterprise information has such noble intentions, sorry to say.

The principles of Zero Trust acknowledge this flaw inherent in a single decision point followed by a set of privileges granted (if successful) by providing a better way of doing this, one that takes the opposite approach: always assume that the user or device (or entity) is up to no good (have zero trust in the stated intentions), continually challenge requests for data or services, and continually assess the behavior both before and after any request.

So what does this mean in practice? Well, that goes beyond the scope of this single piece (and is the reason I am creating a series of blog entries incrementally trying to uncover Zero Trust as it applies specifically to data security, or rather data-centric security). To whet your appetite, though, let’s conclude with NIST’s very practical advice on the high-level implications of ZT in the same special publication.

1. Move away from a focus on guarding perimeters and environments around or leading to data or services.
2. Never trust any user or device implicitly.
3. Do not grant privileges solely based on the location of users or devices.
4. Constantly challenge and verify the need of any request.
5. If successful, grant the least amount of privilege to the authorized user or device.
6. Keep in mind that what you’re guarding is actually information (data) and services (resources), not parts of an environment.
7. Make access rules that are as granular as possible.

Before I close, I ask that you go back and re-read #6 above. It’s a really important point, one that the NIST special publication calls “the crux of the issue.” This principle brings up the critical question, if the crux is to protect data, how best can you protect data? It’s a great question — I will address that in my next post.