Jasson Casey, Chief Technology Officer at Beyond Identity, discusses zero trust architecture and the future of Beyond Identity.

Transcription

Welcome to our Zero Trust Leadership event. I'm Jasson Casey, I'm the CTO here at Beyond Identity. Now, you've heard from our other executives, you've heard from some of our customers, and you've heard from our partners. 

So, now we're going to drill in and talk about Zero Trust Architecture, what it means to us, how we got here, and we're going to tell that story through the lens of the last couple of years where we were, where we are today, and where we are going in the future. So, let's begin. We got started back in 2019. So, the past, the present, and the future. 

When we got started, we were actually focused on passwordless. We were focused on how do we remove passwords from the end-user experience? How do we simplify the act of someone logging into a service, a worker logging into their work service, a contractor, etc? 

We quickly started to realize from our customers that in addition to just removing the password from the problem, we could also solve another problem and introduce unphishable MFA. So, to take a quick step back, there are many passwordless solutions on the market, and what they all have in common is they try to remove the password from the end-user experience, but that's where it ends. 

Where a lot of these offerings differ is in what they're actually doing under the hood and what their approach to the problem happens to be. Beyond Identity is a security company solving an identity and access problem. So, we looked at passwordless and when we looked at the MFA problem, which we'll describe in a little bit more detail here in a minute, we started to realize that there's a fundamental set of root problems that had not been addressed over the course of 40-some-odd years of the password being in existence to facilitate service access across a network. 

And a new problem started to emerge, really highlighting this around credential theft, around MFA bypass, around phishing, phish targets to essentially do something called signing fool attacks against end-users. But ultimately it was resulting in breach and compromise of a lot of companies, organizations, and you don't have to take my word for it. 

I think the Verizon DBIR report for the last couple of years has been fairly consistent. Eighty percent or so of all breaches reported in that report start with valid credentials being used by an adversary, obviously in a way, unintended. In addition to that, I think we had a report out of CrowdStrike at one of their recent conferences where they said 70% or more of the incidents they help their customers respond to, again, start with valid credentials use. 

An adversary is using someone's actual credential and establishing access to a system and then running reconnaissance, pivoting, getting something of interest to that adversary. So, when we got started, we were focused not just on removing the password from the end-user experience, but we had this security lens of how do we actually solve some of these root problems with a password? And what we started to realize is that the core of the problem has to do with movement of a password or a shared credential. 

When a password moves around, it leaves a shadow, if you will, on every machine it ever touches. And that shadow is an opportunity for an adversary to steal the password, to steal the credential. Obviously, it ends up in the database that I'm trying to access at a service, which is another opportunity for an adversary to compromise the credential. And you can't help but notice if part of the problem is this, the surface area is created just through password movement. 

Is it possible for the password not to move? And the answer is clearly yes, right? Through something called public key cryptography. It's possible for the public key to move, but again, the public key does not compromise anyone or anything, and the private key does not have to move. So, that was one of our initial insights. But that's not mind-blowing, right? 

Many people have thought of using public-private key cryptography as a method of reducing the surface area of passwords, but it wasn't enough. This gives me an opportunity for that private key to not move, but how do I have a guarantee that private key doesn't move? And that's where the next step comes in. The next step has to do with these things called enclaves. An enclave is a type of processor. 

An enclave exists on almost every device that you can buy today, whether that device is a desktop or that device is a mobile device or it's an AWS instance of an EC2 machine. For instance, more than half of their instance types now have some of these enclaves. So, what is an enclave? 

An enclave is like a little jail. It's a little processor with secure memory where I can keep a key with a guarantee that that key can't leave the enclave. The enclave is not in the processor, it's off to the side of the processor. So, by using public key cryptography and then also by using an enclave, I can now have a key with a guarantee that it can't move. The enclave will even go so far as to give me a receipt that I can hold up and I can use to prove after the fact that, yes, there is a credential. 

Yes, their credential is glued in type of this enclave. This enclave is specifically this make and model. And there's providence and there's provability to it. So, at this point, I'm starting to handle problems of credential theft, right? I have a guarantee the credential can't move. If it can't move, it can't be stolen, but it's still not enough. We have to do one more thing. 

We actually have to introduce this concept of a platform authenticator. A platform authenticator. It's a piece of software that lives on the machine you're actually trying to access data from. It manages the enclave. Whenever a challenge comes down from a server, it asks the enclave to sign that challenge so that you can then get in. 

Now, there's a couple of interesting things the platform authenticator will do with the enclave to actually solve the next set of compromises that we have to worry about, right? Enclaves and private keys give us protections against credential theft, but there's another class of attacks called signing fools that I also have to worry about in a signing fool attack. If I can't steal the credential, maybe I can trick the victim, or the fool, into signing something for me, the adversary, that I then represent as the victim to the legitimate service and then gain access as the victim. 

In order to solve that problem we need a little bit more. The enclave is not enough. The public key cryptography is not enough. I need one more thing, and that one more thing has to do with credentials in context. So, what is credentials in context? So, I have this credential, right? This little key. 

When that key is constructed, when that key is issued, it can be issued in a certificate or really any sort of sealed envelope where there's a copy of the public key and some information about that key. More specifically, some information about how that key can be used under what circumstances? The platform authenticator fills the role of guaranteeing that this key will only be used under the circumstances that are actually inscribed in this context, if you will. 

Or more specifically back to that scenario, what we talked about earlier, the signing fool attack. If the adversary is able to man-in-the-middle of my connection, if they're able to try and trick me into signing something, making me think they are legitimate, my platform authenticator will evaluate the challenge. It will look at the context of the key that the challenge is actually asking for, and it can very quickly identify that the origin where that challenge is coming from is not one of the listed origins in this key's context or in this key's certificate. 

And it can break the authentication right then and there, preventing the man-in-the-middle exploit. What I just described, these three core steps, are the foundations of establishing trusted identity. You must do all three of these steps to actually have unphishable MFA. If your MFA is push-based, if your MFA is TOTP-based, if your MFA is based on magic links, it does not provide these levels of protection, and it is vulnerable to man-in-the-middle attacks to credential theft if it's still using a password. 

Even if it's using a public key cryptography system, even if it's using an enclave, if it's not using a proper platform authenticator, it can still be exploited in some of these MFA bypass attacks. And just to point a picture of how important and how risky these scenarios are, the U.S. federal government put out an order last year, in 2022, compelling all federal agencies to move to unphishable MFA by the end of this year, 2023, specifically because of evidence that they were seeing of adversaries running these MFA bypass and exploit attacks against TOTP, against Magic link, against Microsoft number match, against essentially all of these easily-defeatable MFA technologies. 

So, this was kind of the core of what we established around trusted identity. If I use public-private key cryptography, I have a possibility of the key doesn't have to move. If I do it in an enclave, I have a guarantee the key doesn't have to move. If the key doesn't move, I'm no longer susceptible to credential theft. If I use a platform authenticator with credentials in context, I can actually eliminate the scenarios of signing fools. 

And at this point, I have a trusted identity that will actually stand up to network threats where adversaries are phishing my end users, my end users are clicking links. Unfortunately, you're never going to get them to stop clicking links. You can reduce the rate, but you're never going to make that rate go to zero. So, if you do these three things, when your end users click through to those phishing links, you're not going to have to suffer a bad result. And this is really kind of where we started. 

We started really focused on this problem, but then we started hearing back from customers. Turns out they'll tell you if your product's useful, but also, they'll also give you directions of how to improve your product over time as well as are there adjacent areas that you're maybe actually be able to help them with? And so, one of the adjacent areas that we were immediately getting asked for, and this really kind of started from the beginning, but I would argue it's more of a current approach and this has much more to do with device trust or more specifically now that I understand who is trying to authenticate and I understand what they're trying to do, and that's usually always carried in the protocol, are the security controls that I expect on their device, the thing they're trying to work from, are they actually present right now? 

Not yesterday, not last week, not an hour ago, but right now. Are they present right now? And this is where we started to build the solution out. So, the first extension was really about the local device. So, for instance, I may want to know what firewall rules are actually present on the device. Do I have RDP brute force mitigation in place? 

Do I have an idle screen lock in place? Do I have antivirus in place? Is it running the appropriate policies at the appropriate time? So, gathering signals about the local device is important. It's necessary, but we learned it wasn't enough. In most enterprise architecture, you have this rich fabric of information being collected from VPN services and ZTNA services, from EDR services, from MDM devices, vulnerability management, right? 

The list can go on. All of this information is traditionally integrated in a SIM. And then maybe, or maybe not you do some sort of analysis on that information after the fact. What we started to realize is there's this information nexus that we want to make decisions on, not just with the information that we can collect locally, but also with what we can actually gather out of this partner ecosystem. But we didn't want to gather it from the SIM. 

We wanted to be able to get real-time data to make real-time decisions. And that's where the final part of the product started to come into place. And this is where our partner integrations show up. So, once we had the partner integrations and the local device visibility, that enabled us to actually start talking about the trust level of the device itself. 

So, is this a trusted device? I'm sure many of you have heard the phrase, "device trust." But when you really start to peel back the onion of what does that mean? The answer should be, "Are the security controls I expect present on the device at the time in which they are needed?" 

That's really what device trust means. It should not mean is there an MDM on the device? It should mean, did the MDM establish the controls I expected it to on the device? And that may sound trivially the same, but they're actually very, very different questions. And in fact, one of our customers introduced us to the difference those questions actually make in a real deployment. But just to be very concrete, what we're talking about here is, "I want to understand the view of the device from the MDM." 

"I want to understand the view of the device from the EDR." "I want to understand the view of the device from the VPN or the ZTNA service, if there is one, from the Vulnerability Management Service, if there is one." "I'd like to incorporate threat intelligence data if it's available." And over all of this rich information about the trustability or the trusted level of the identity and the trust level of the device, only then do I actually start to approach a zero-trust authentication architecture. 

So, now that we've established trusted identity, trusted device, and we know we can run this architecture in a continuous monitoring mode, right? We'll call that continuous auth... number 3. We've started to establish some of the core tenets of zero-trust authentication. 

So, I'll even go ahead and call that out really as its own thing, right? Its trusted identity, trusted device, continuous authentication, continuous monitoring for improvement, right? This is all producing a log stream, right? That I can actually send out to my SIM, to a data lake or whatnot and do analysis on. And where we're looking to push to the future is in the development of analytics over this information to help make better decisions about the entire zero-trust authentication architecture, or instance. 

The first, most obvious, analytics have to do with IT operations. So, IT operations. We're running big deployments with customers right now, a customer with 90,000 employees or workers, I should say, deployed 30,000 workers over the course of 3 to 4 weeks. They're trying to close the balance out over the next 60 days. 

We learned a lot through working with them on what effective deployment analytics might look like to help understand, "What is the experience the user is actually gaining." "How is the deployment running?" "Am I being efficient?" "Are there things as an IT operations person that I can do to actually improve the onboarding experience to reduce the onboarding time?" The next set of analytics that we're looking at is around security operations. Again, this was another thing fed back to us from an existing customer. 

In fact, I think you heard from him earlier today, Marcus. Marcus was using our system. He was specifically writing policy rules saying, "I want to continuously off this environment, but I want to do it without an action." So, we have these things in policy called monitor rules, which basically just says, "Every time something changes in the environment, send out a log." And Marcus did most of the hard work of doing the analysis, but he is trying to answer the question around security assurance. 

Are the controls he expects-- is the security intent, the design that he came up with and his staff came up with actually what's going on in the field? And if it's not, show the delta and help understand the delta, so he and his staff can decide where to spend time, where to dig in, where to focus. And then finally, we have this class of... we'll call it C-level analytics, which is really around the efficacy of the security program itself. 

How are we doing? Where should we be investing our time next quarter, next half of the year, next year? What is the actual risk that my organization is experiencing right now through all of the access attempts that I see, right? Which is really where all of my risk is created. What is that telling me about the organization and the organization's health as a whole? So, now that we've covered this, the core of what we've defined is a zero-trust architecture. 

And the reason we're so excited here at Beyond Identity is we've established a platform that we can help answer access, authentication, and authorization questions from a zero-trust perspective, not just for today, but into the future with answers to a large group of critical players in your organization that ultimately apply not just to worker access, but to code development, to intellectual property development, to logging into cloud-based infrastructure. 

Really, anywhere access exists, we can provide a zero-trust authentication experience, visibility point, and set of security controls for that use case. Thanks for coming and appreciate you being at the Zero Trust Leadership event.