This video is number one of the Zero Trust Authentication Master Class series.

Transcription

Hello, my name is Jasson Casey. I'm the CTO here at Beyond Identity, and we're going to start this discussion by talking about zero trust. 

And we're specifically going to get into some of the problems that zero trust is actually kind of organizing itself around, to get started. So, the first thing that we really want to focus on is what is our definition of zero trust? So, we're going to actually just borrow the definition that comes out of NIST. So, NIST has a document called 800-207. And it's not a long document, it's actually pretty short. 

I recommend all of you actually take a look at it. And in there, pretty early on, they actually call out a couple of motivating problems, really setting up the stage for what is zero trust trying to solve. And I'll give you a preview, and the preview really is assume you're operating in a hostile environment, and kind of establish trust as you need to with respect to what someone's actually trying to do. 

But more specifically, and I'm going to paraphrase here, one of the first problems they actually talk about is that there is no implicit trust based on any sort of special location in the network. And so, we'll just say the network does not... Whoops. 

Does not implicitly grant trust. So, what do we mean by that? In old-school networks, not even old-school networks, some of you probably have an architecture like this already. Depending on where a device, an asset, or a person happens to live in your network, you may decide to trust them already at a higher level, right? 

So, no granted implicit trust really means there's no privileged point in my network. It doesn't matter if you're on the private network or the public network. It doesn't matter if you're in the DMZ or not in the DMZ. It doesn't matter if you're in the super-secret out-of-band network that's air gapped, blah, blah, blah, you still have to prove things about yourself and what you're trying to do in order to move forward, right? 

So, another thing that people get caught up with zero trust is the word zero. If I have zero trust, then I'm trusting nothing, and if I'm trusting nothing, then clearly, I can't establish trust, but trust is in the name, so I must be trusting something, but zero is in, so I'm not trusting anything. And then steam comes out of their ears and their head explodes. Less catchy, but maybe a more apt description of zero trust should probably be what is a system where I have the minimal amount of trust that I have to assume to then bootstrap a secure architecture? 

And all of these things that we're getting into with zero trust are really kind of just codifying that, right? There's no privileged perspective in the network that gives me any sort of implied trust. I don't care if you're in the high side or the private side of the network, you still have to authenticate in a strong way, you still have to prove things about your device in a strong way. 

All right, so what is the next thing? The next problem they call out is they basically say that devices operating on the network may or may not be owned by the enterprise. So, this is kind of a wink to BYOD. 

But there's a lot more scenarios than just strictly speaking BYOD that this is covering. What it really saying is there's going to be devices on my network. I may or may not own them as the enterprise owner. Maybe they're contractors, maybe they're BYOD devices of employees. They're still on my network for some reason, and so I still am going to have to establish trust with them if they're trying to do a thing, and I still need to protect myself from them if they're doing something malicious. 

All right. The number three thing is there are no resources that are inherently trusted. So, a resource is kind of a fancy name, really, for a service or a server, something that I'm reaching out and asking for a piece of data or to kick off some transaction. No resources are inherently... 

Terrible speller. Trusted. So, what does this mean? This means just because I have a server that's in a private side of the network and does some things, and I know about it, and I manage it actively, it doesn't mean that I trust requests from it blindly. If it needs to contact another resource, say, a database to get something, that service, that resource still has to go through authentication and authorization in a strong and secure way, right? 

All right. Number four. Not all resources are on the enterprise infrastructure. I'm just going to say infra, but infra is infrastructure. 

What does that mean? Well, how many of you use cloud services? Unless your name is Amazon, Microsoft, Oracle, IBM, or Google, you don't own that infrastructure. It's on someone else's infrastructure. So, again, this is just another use case where we're actually calling out that I could be in a hostile environment, or at the worse case, I could be in an environment where insider threat of the administration, of the infrastructure I'm operating on is something I have to consider and something I have to take into account. 

All right. Now, our fifth thing, fifth assumption that we have to kind of take into account, is I now have this concept...well, not now. I've always had this concept of remote assets, assets, devices, resources, really, whatever you want to call them, that are not going to be on any sort of network or service layer that I control. 

Not on any, we'll just say, network that is controlled. So, great example of this is a hoteling environment. Your worker is working in a hoteling environment, a WeWork, a hotel, like an actual hotel, like a Marriott, etc. 

And it's another way of pointing out, is it's not just about your resources and your infrastructure having to establish trust with devices or endpoints that are sitting on that infrastructure and resources, but it's also on the devices that are using a network to realize that they cannot trust that network that they are using in anything more than just the delivery of packets, right? 

There may be eavesdroppers in the network. There may be people in the network with an ability to copy transmissions and replay them, right? So, again, all of these assumptions coming out of this document, they really kind of say a couple of things. And what those things are is you are operating in a hostile environment. You have to assume that the adversary has compromised the network layer that your applications reside on. 

When you're operating in third-party infrastructure environments, you have to assume that there's some sort of or could be compromise in the infrastructure layer. And so how do you operate accordingly? How do you...in bringing it back to the words of zero trust, how do you establish trust, right? So, zero trust doesn't mean there's no trust, zero trust means in the beginning, the initial conditions is you don't trust anything. 

There may be a couple of assumptions that you trust, right? But other than those assumptions, you really don't trust anything. So, just using those assumptions and logic and protocols that you're actually architected around, how do you bootstrap a level of trust that you can confer upon endpoints using your infrastructure or services trying to use resources to make your products work, to make your services work, etc.? 

That's really kind of what zero trust is and what the problem it sets up. So, let's take one kind of visual look at this, right? In the old world, and I think you can kind of see that through these problems, there's kind of, like, these three axes that we generally concern ourselves with. 

So, the first thing that we talked about, you'll notice we talked about the network, right? So, let's add the network. So, this axis is really how do I establish trust based on network location? I mean, we're being told that's bad, but in the old world, you can kind of divide this up, right? 

So, above, here, you have the public side, and below, you have the private side. And, you know, in a perimeter-based security model, the idea is, is if I'm in this region, I'm to be trusted, right? If you look at some of these other questions, we talk about almost an asset ownership relationship, right? So, we'll say owned. 

And, again, the idea being is let's say that it's not owned, right? And it is owned. And, again, the idea is, is if I'm over here, somehow, I have a higher level of trust. And, again, I'm not saying this is right, it's just kind of more traditional thinking. And then a third thing that actually kind of falls out of here is this concept of managed, right? All right. 

Because, again, I'm operating on a network that I don't manage, I don't control. And so, again, there's this idea that...you know, there's this part of the equation where the answer is no, part of the equation where the answer is yes. And the idea is, is if I'm talking about a device that's managed that's on a private network and that is owned by me, then somehow, I've actually conferred this level of trust. 

And we can kind of represent that as a box, right? And so the old world of thinking is if I'm in this box, I'm good, and if I'm outside of this box, I'm bad, right? So, we can actually use this framework, which isn't necessarily awful in terms of having a framework to conceptualize decision-making, but apply it in a more zero-trust fashion. So, as we described a minute ago, right, we're going to keep our three axes. 

We have...every transaction is driven by an identity. So, it doesn't matter if someone's logging into their bank account, right? The human identity. Or if a web server is contacting a database server, right? One resource contacting another resource, asking for what is the account balance of this person so I can then display it? 

That's a machine identity on the web server driving that transaction. Again, both are transactions, both being driven by an identity. So, clearly, an identity plays a role in it. Also, there is...we can call it an endpoint, we can call it an asset, we can call it a resource, we can call it a device. And I'm just kind of reusing some of the language that we talked about earlier. 

But an identity on a machine is driving a transaction. And then, finally, every transaction has some sort of kind, or class, or operation, right? Is the transaction an authentication transaction? Is the transaction a payment transaction? 

Like, it turns out the type of transaction or the class, or kind, or operation of the transaction is really going to clue me in to how I establish trust of the identity on the machine. And, again, we can kind of get back to this bounding box idea, where, essentially, I know I want to try and find things that are in the box that are good, and I'm going to define to where out of the box is bad, right? 

So, again, zero trust, as we've already said, it's not a question of there's no trust, it's really just a question of, I have this minimal set of assumptions at the beginning. And the whole point of a zero-trust architecture is on a per-transaction level, how do I establish trust? And so this is the framework that we use and how we kind of reinterpret the beyond...or the NIST zero-trust problems in a Beyond Identity framework, right? 

So, if everything's composed of transactions, a transaction is always driven by a resource and identity, and it has a type of operation, then the solution to the problem of how do we establish trust is really, given an operation, how do I determine or how do I establish trust in the identity and in the machine that the identity is operating from? And the reason why that's interesting, the reason why that's important is when we look at this framework right here, right, this old framework, does an adversary really care if you're in the box or out of the box? 

"Oh, you're on a private network, I'm not going to attack you. I'm not going to run an exploit because you're not on a BYOD machine, you're on a corporately managed machine or owned machine." Adversaries don't care about that. They're going to exploit things based on security controls not being present. So, a way of rebuilding a framework using the zero-trust principles is more on how do I establish trust? 

Or how do I establish trust that these security controls are, in fact, present before I allow the identity on the machine to either retrieve the data or fiddle the damn controls? That's really the basis of how we're going to talk about our architectural solution to the zero-trust problem.