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

Transcription

Hello, I'm still Jasson Casey, and you're still watching our series on Beyond Identity's Architecture. So, the last thing we talked about was the mechanics of policy. 

How do you tie someone's access into an identity system and into the Beyond Identity authentication service? And specifically, how does policy engage back and forth? And so, we talked about the mechanics of it, but we didn't really talk about the semantics of it or put it in another way, like what kind of policies can I write and how do I actually think about policy? 

And that's what we're going to focus on right now. So, we're going to start not with this color, but with this color. And remind ourselves of this little three-dimensional kind of model that we use to measure things by. And remember where this came from, we're looking at zero trust, specifically the NIST doc definition of zero trust. And we look at all of the problems that zero trust is trying to address. 

We boil it down with the solution to say, really, the world is an ocean of transactions. A transaction is the smallest atom. So if I can secure a transaction, then by definition when I look at the ocean, I have a much more secure architecture. So, the first thing that we think about when we think about this transaction is the operation. What is the operation type? 

Right? Because depending on the type of operation someone is trying to drive, or the thing is trying to drive, it may be a critical operation, it may be a non-critical operation. So, I am going to take a different response. I'm going to manage risk differently based on the risk that exists. So, the transaction is driven by two things. It's driven by an identity. 

Now, again, this could be, you know, our good friend Alice, a human, right? Or it could be our good friend Bob, and we've just made Bob a robot. And really all we're just saying is it could be machine identity or it could be human identity. It doesn't really matter. There's always an identity driving a transaction. 

And then, of course, our final dimension, we're kind of using the language from the NIST document, the resource. Remember, a person contact a resource. A resource can contact a resource. You may have seen this be called assets. Asset has one T, but we already know I'm terrible at spelling. We often call it an end-point here as well just for end-point compute. So, again, the way we look at this is what is the operation? 

And given what the operation is, what level of trust do we need to establish? Not just on the identity, but on the resource, right? And so, clearly, we want to build out a lot of points on these two dimensions if it's a critical operation, less so if it's a less critical operation. And you know, you can make analogies with this turning into a little bit of a box and trying to, you know, grow the box or shrink the box, but always make sure that the data points live within the box. 

So, when we talk about policy, all we're really doing is we're presenting a system to let you, the administrator, assuming you want to administer the system, really kind of navigate this model. So, for instance, when you're thinking about different operations in our system, the operations are really represented. 

And the terminology is different depending on the protocol. But for now, let's stick to kind of OIDC applications if you're working with OIDC applications. Operations really show up as different auth services. Now, it's all really one auth service as far as we're concerned, but when you start integrating into different auth services, right? So, like, let's say you're tying up app 1 and app 2 into auth service 1 and auth service 2, these are going to show up as different what's called client IDs, right? 

Remember, client ID is parameter that comes across one of the auth requests that we talked about earlier. And this is how inside a policy you can actually provide impact or different impact across different applications. Within one special application, the Beyond identity application, we actually call out the inter-application operations, right? 

So, add credential, authenticate. When you're adding a credential, you're creating a credential. And there's a couple of different types of credentials that you can create, right? So generally we're talking about X509 credentials. 

We use the X509 format for talking about all of the metadata that pertains to a private key, but there's no reason why we can't also create, you know, just regular JWTs down here. There is no reason why we can't create PGP keys. And for those of you in the know, like PGP keys, kind of more like a certificate. It's an envelope with a key inside that's sealed and signed. 

There's no reason why we can't create SSH certificates and their accompanying keys, right? So, the life cycle bringing these into existence as well as using these are all discrete events. They're all discreet operational types that actually show up in policy as discrete operations that you can select across. So you can select across the different apps and you can select across the different operations. 

So, this is how I kind of start my journey, right? If it's Op 1 or if it's Op 2, I'm going to start thinking about doing different things. So what are those things, different things I'm going to start thinking about? Well, I kind of have to put myself back in the mindset of what are the security controls that I expect for operation 1 versus operation 2? 

So for this example, we're just going to keep things at a high level. So, we're going to say this is a low criticality operation,we're going to say this is a high criticality operation. And then we're going to talk about what are the things that we can say. Well, on the identity, we can certainly ask the identity to prove that it possesses... Remember MFA, let's reintroduce MFA real quick. 

MFA, there's really only three axes here, right? Possession, and again, I can't spell, not sure if that's right. Could be a fish in French. There is possession, there is knowledge, and there is inherence. So, because our key is created inside of a secure enclave and we can see that through the certificate that's actually presented, that gives us an ability to do things like say, prove possession, right? 

So, in any of these scenarios, I'm almost always going to, as part of my policy requirement is say, I want you to prove that you possess a key, that that key is actually in some sort of secure enclave, right? And that gives me possession. 

Now, remember we talked about how we can do inherence with the biometric or the local pen or the password on the device. So, I can also say, prove that they can use a key, right? That's in an enclave where the authorization policy of that key has a local pen, right? Or a biometric. 

If we wanted to go the inherence route and assume we have, you know, that same statement down here as well, not going to copy it all. That let's us kind of go a little bit deeper on this dimension. Now, on the resource asset dimension, what that basically looks like is imagine our classic stack, down here we have hardware, on top of the hardware sits an operating system, and on top of that operating system sits an application. 

Turns out every end-point is going to have that hierarchy because guess what? They're all computers. So, maybe there are certain pieces of hardware that I view as secure and unsecure. Maybe there are certain bits of hardware that I just view as high trusts and other bits of hardware I just don't have an opinion on, right? 

So, what would an example of that be? A great example of that would be let's say that I'm operating...I find a TPM 2 is present in the hardware, right? I know that a TPM 2 can actually do these things called measured boot. Measured boot means I can actually verify the integrity of the BIO. 

So, I can verify the integrity of the bootloader. I can verify through a cryptographic proof that no malicious adversary has actually corrupted the BIOS, the bootloader, or the operating system. So, that's an example of like a high trusts device, right? So, in the hardware bits, I might be able to say down here for this higher thing, you know, my hardware needs to be essentially in this list, right? 

And I can call it out. You know, it's hardware types A, hardware types B, and hardware types C, right? And I'm going to keep appending a bunch of other things to this. Now, let's say I want to poke at the OS, right? I can look obviously at the versions of the operating system, which, you know, we all have chased before, right? 

I can say things like no more than three versions auth top line, right? Or whatever the main release is. Or let's say there's one specific low water mark that I want to make sure that I'm actually tracking. I can also talk about some of the configuration of the operating system. 

So, for instance, for a high trust device, let's say that I want to prove that the screen lock is not just enabled, but that it has a timeout value of at least 180 seconds or less, right? Let's say that we also wanted to talk about remember an operating system is kind of managing a network stack and a hierarchy of disks, right? 

So, let's say I also want a high trust system to show that essentially, you know, all of my discs are encrypted. And we could write some proofs around firewall rules, show the existence of a certain rule type in the firewall, but for now, I'll just say the firewall is on. But we can get into the details of that. 

Now, let's talk about the apps. I'm a corporate, I'm an enterprise. I deploy EDR end-point, detection, and response. I have this EDR specifically looking for inherent threat, right? And so, I'm only going to consider this device high trust, this end-point, this resource high trust, if I can verify that the end-point thinks it's running the EDR and the EDR cloud instance agrees with what the end-point says that there's a consistent view between the two. 

So we could be specific, right? We can go in and we can say EDR, CrowdStrike is on and some sort of the configuration properties actually that are present on the inside are exactly what we expect, right? It turns out it's even more general than that. 

I'm talking about CrowdStrike. We have specific CrowdStrike integrations, but let's say there is a piece of software that we do not have an integration for, but you still use that software as part of your definition of a high-trust model. You can still write policy to actually poke at that software, right? Whether it's a running process, right? You can look at running processes by name. 

You can actually look for files and directories by name. You can examine the registry by key and look for the existence, not just of certain keys, but specific values on keys or if we're in the world of Mac P list, right? So we have a lot of integrations, right? Go to our website to check them out. 

But whenever they're an integration that does not exist, you can probably still write policy, maybe a little bit more involved, but you can still write policy to poke at your definition of what's necessary to prove trust relative to the operation that someone's trying to drive. So again, just to recap, policy was kind of our idea of a Swiss Army Knife to the enterprise administrator. 

Every enterprise defines risk differently. Every enterprise will accept transfer or mitigate risk in a slightly different strategy. We would be chasing our tails if we tried to build a product to satisfy everyone. And so, we took a step back and realized the best way of satisfying everyone is to build a product where you can actually define your risk in our product and your acceptance in our product and your mitigation strategies in our product. 

And that's really why we focused on this layer, right? How do you, relative to what someone's trying to do, essentially assert or prove the level of trust is present on the resource and in the identity driving the operation?