Transcription

Hello, I am Jasson Casey. I'm the CTO of Beyond Identity, and I'm here to talk to you today about Beyond Identity and a little bit about the history of passwords. And more specifically, we're going to get into kind of our view of the world of what strong access and strong authentication look like. 

So a little bit about me, I'm the CTO here at Beyond Identity. I've been here for about two years. Before Beyond Identity, I was at a company called the SecurityScorecard, before that, at IronNet Cybersecurity, and a lot of my focus up until Beyond Identity was about detection. 

Here at Beyond Identity, we're more focused on prevention. And the way we see it, the largest opening or the weakest link in the chain in most organizations' security is really around access, right? Most people don't break in, most people log in. And we think we have a pretty compelling simple solution around how to tie up access. So if you couldn't guess, from the name of the talk or the name of the company, a lot of this starts with passwords. 

So passwords are the historic form of how people authenticate who they are and it is the historic form of access, right? And if we look a little bit over the history of passwords, we realize that first, it was small, simple password, and then we were told that we need this to be longer to not be susceptible to things like guessing attacks. 

Then we were told we need to make these things higher entropy to make sure they're less vulnerable to cracking. Then we need to make them unique to make sure that every service that I use has a unique password to make sure that we're not vulnerable to stuffing. And at this point, we can't really manage this anymore so we're told we now need to use a password manager. And then even then, people don't actually comply all the time.

So we try and introduce things like MFA or 2FA and then we start learning about bypass attacks and pass the cookie. And it's kind of a world of whack a mole and we wanted to kind of take a look at this and see if there was something that we could do that was better. 

So as I mentioned before, when you actually start studying incidents, right, how do incidents evolve into actual breaches and attacks, almost all of them start with or have a major component that doesn't really involve breaking in. It actually involves logging in, right? People aren't good at remembering passwords, right? 

A good password is a high entropy string, right? We tell people to use password managers and sometimes, that works but sometimes, they end up just reusing either a single passphrase or password or reusing combinations. Those combinations eventually get stolen and can lead to things like credential stuffing, right, or phishing the password or just really the core idea here is at the end of the day, services certainly do get exploited but most of the time, the key vulnerability is valid credential use.

And just to put some names to specifics, right, all we have to do is just look at things that have occurred in the last year or so. And valid credential use, right, or, I'm sorry, valid credential misuse is really at the key of a lot of these incidents. 

So it pays to take a step back and actually consider the world that we're actually operating in, right? So the modern network, and this is a phrase that we kind of borrow pretty liberally from one of our friends and customers, Jarrod Benson, is the cloud is the data center, the internet is our network, and any device is a work device. 

So what does that actually mean? It's a really simple way of kind of painting the problem that any security architect or IT organization has to solve today, right? Your modern worker is nomadic, right, certainly for the last year, but even before COVID, it was a growing trend. They're going to work from anywhere. 

Your services are constantly being moved from premise infrastructure and self-managed cloud to public cloud and SaaS-based services. And more and more people want to work from their own devices or BYOD devices. And in certain circumstances, you may need them too, right? So in this world where you can't count on what someone's working on and you can't count on where they are and you can't count on actually controlling the application, how in the world do you actually assert a security framework? 

And that's something that we'll kind of get a little bit into, right? So we see identity as really the center and I know it says identity is the new perimeter but the reality is, is perimeter itself is bad, right? A perimeter security model is this basic concept that I have this shell, things on the outside, I don't trust, things on the inside, I do trust. 

But really, we all kind of know that not only is that not a good model now, it was really never a good model because almost every incident, regardless of the decade that it actually comes from, you can see that essentially once certain controls are bypassed, then this implicit trust that's kind of built into a perimeter-based security model is completely used to…well, it's not used to slow anything down or prevent anything, right? 

It is one of the fundamental flaws in how we actually design security architecture. So in that world where I can't count on where someone is, I can't count on what device they're using, and I can't count on what service they're trying to access, the obvious question that pops up is, "Well, what can I count on," right? And the reality is, is the only system that's naturally in the middle of every transaction that someone tries to drive is actually the identity system, right? 

The identity system is naturally going to be in the middle of everything. It doesn't matter who you are, it doesn't matter where you are, and it doesn't matter what you're doing or what device you're using, you are going to have to go through an identity system to authenticate yourself and to authorize the action that you're trying to take. So if we take a moment to take stock of what we just said, right, the identity platform, it's kind of this natural tollbooth, it's high ground, it's this island that we can naturally kind of try and build security functions from, right? 

So if a perimeter security model is bad and we need something stronger and we don't want to go through these unnecessary actions of constructing kind of artificial toll bridges, let's force everyone through a singular VPN, let's use that VPN to do device checks, let's scrutinize all the traffic, right? 

And I'm not saying that's not possible but that's a lot of work. And it turns out the identity system, it's this natural system. So is there a way that we could evolve the identity system to not just be an identity system but to be a security system? Is there a way for the identity architecture to offer up security scaffolding for the common functions that we want to try and build into our architecture around things like identification, protection, detection, and response? 

So now that we've set that problem up, there's this phrase, term of art, that's been going around for a while, oftentimes, you'll see companies and organizations talk about it. I want to make it concrete before we really start using it. Zero trust, right? So zero trust in the world of access. 

And what we're actually concerned about here is, how do I know? How do I establish trust for any sort of transaction that someone is trying to drive, right? So if someone can be anywhere in the world, if they can access any service, if they can use any device, clearly, I'm in a hostile environment, right? And so like zero trust always starts with this premise of consider your environment compromised or at least hostile and slowly try and build up security primitives that you can trust and then only rely on those primitives that you've established to further do things, right? 

So in this particular scenario, what that really means is it means how do we understand something about the risk of the device that the person is using regardless of whether we own it or not? How do we understand something about the risk of the identity claimed, right, for the transaction they're trying to drive? 

How do we understand the criticality of whatever the transaction that they're trying to drive? Are they trying to move money? Are they trying to actuate some sort of cyber physical system? How do we pull all those things together? And then how do we ask questions about, is this usual or is this unusual? Has this person done this before? Are they part of a cohort that regularly does this before, right? 

And not only the direct transaction but consider the context, right? So taking all of these things into account is really what zero trust access is about, is every time someone wants to drive some sort of transaction, how do I understand the risk of the claimed identity, the risk of the device that's trying to drive the transaction or receive the data that the transaction is trying to obtain? 

How do I understand the criticality of the data or the action the person is trying to drive and how do I adjudicate that? How do I know that the risk is low enough for the criticality, right? And into more advanced scenarios that we'll talk about in a little bit, is there any way for me to adjust the risk in real time up or down? 

So maybe the identity risk is high and there's some sort of activities that I can ask the end user to engage in to bring that risk down or maybe something about the risk increases during a transaction, how do I break the session? So this is really what we mean when we talk about kind of zero trust fundamentals and zero trust access. 

And we see this set of zero trust tools as being kind of necessary at solving that problem of if my workers can truly be anywhere, if they can truly be using any devices, if identity is really in the middle of everything naturally, then how do I use my identity system to establish some of these zero trust tools to provide this kind of continuous authentication and authorization function? 

So this is one more slide just on, you know, the typical pitfalls that we've kind of gone through as an industry, right? Access has always been a weak link and we've always tried to put things in front of access to make things more difficult for adversaries. 

And an interesting observation here is the burden on the user is almost constantly increased with every action we've taken. And as a consequence, the end user just expects to get good security, I'm going to have a terrible user experience. And that, we think, is actually one of the driving criteria around why some of these tools aren't actually getting adopted, right? 

At the end of the day, the interesting thing about relationship between, you know, whether it's a security group and the workforce or even just management and the workforce, is you can kind of lay out dictums and frameworks and policies all day long but at the end of the day, you're outnumbered, right? And so you're only as successful as your ability to actually get your workforce to follow policy, right? And, you know, the interesting thing that we've learned over the last 10 to 15 years in just general software design is if you want a better…if you want better usage of your product, that goes hand in hand with having a better user experience of your product. 

And by focusing on UX or user experience as like a first-order impact or as a first-class citizen of the process, you can actually get more complaints. You can actually get better outcomes and experiences for the workforce at large. And so this is also something that we think has to actually be tackled when you want to address access as the primary entry point for incidents escalating into breaches. 

How do you actually get your workforce solutions and tools that are usable, right? Clearly what we have today is just generally not usable and I think you can see that through both adoption numbers of some of these technologies as well as the success rate of things as simple as credential stuffing. 

So just to kind of put a bow on it, right, like, what does an ideal solution look like? An ideal solution doesn't require IT or security engineering to build new infrastructure, to build a new experience for the end user, to kind of construct these artificial pathways, right? 

It should re-leverage existing systems that someone is always going to go through, right? Latency is a prime usability metric and how, not just the workforce, but customers experience your business services or your product. So how do I have minimal latency? 

How do I give them things as fast as possible? Well, I only go through the minimal number of services, right, and identity and access is certainly going to be in the middle, so let's not add anything else. How do we take the identity system and how do we build on it? How do we continuously authenticate the user? How do we understand the risk of the claimed identity? How do we understand the risk of the device? How do we track those two things as they change? 

And as they change, how do we lower or raise or even break the authorization for whatever session or transaction the end user is driving? An ideal solution has to have answers for all of these questions. So now we kind of get into a little bit of what we do, right? 

So at Beyond Identity, we're an identity company but unlike other identity companies, we are a security-first organization. We built an identity stack with security primitives built into it with the understanding that we will be at the center point of every transaction and every session for an organization's workers and an organization's customers. 

So knowing that and knowing the security organization has a standard framework they want to assert, right, whether it's the NIST framework, how do I know what I have, i.e, identification? How do I know it's protected? Configuration, hardening, patching, how do I know I can detect bad things, right? Think behavioral analytics, how do I know I can respond? If I'm raising and lowering risk of identity and device state, like I can change authorization levels or even break them.

How do I build an identity system that has those primitives in them? So we've done that with our Cloud Identity service but that wasn't enough. Because, again, we want to understand what's the risk of the identity claimed as well as understanding the risk of the device itself. So we introduced something called a platform authenticator. So a platform authenticator, it's actually terminology you may have come across for anyone that has read into things like WebAuthn, or CTAP in the FIDO world. 

And what a platform authenticator is, it's an authenticator that actually resides on the device that someone is using to drive a session or drive some sort of transaction. And that's a really key concept, by being on the device, certain things now become possible. 

Number one, the most obvious thing is I can actually interact with the device directly and understand what is its security hardening state? If it's MacOS, has system integrity protection been disabled? Like simple things like that. Is the firewall enabled? Is disk encrypted? Was the screen lock enabled? What's the idle timeout on the screen lock? 

Are there security controls I expect to be present? CrowdStrike or SentinelOne, are they actually running? Are they running the policies I expect them to be? So a platform authenticator, by being on the device, can actually speak to the security of the device. 

Now, the next thing that you can take advantage of by being on the platform is most devices, whether we're talking about mobile devices or laptops or even desktops, over the last three years have started to ship with technology called Ts and it's slightly different across the different vendors, whether we're talking about TPM2s or we're talking about Secure Enclaves or we're talking about facilities established by some of the processor itself. 

In almost all these cases, you now have an ability to construct a key pair and anchor it in hardware. So what that means is the private key physically cannot leave the hardware, it cannot leave the Trusted Platform Module (TPM), it cannot leave the Enclave. And this is something else that's really important in this model. By anchoring a key in hardware, it eliminates the mobility of that key as a credential, right? 

And so when we talk about disrupting lateral movement or disrupting valid credential use, if a key physically can't get moved, that completely disrupts the whole concept of credential stuffing, right? Now, clearly, password portability or the idea that the password lives in my brain and I can move between devices still has to get solved from a usability perspective but the immobility of the key itself is a prime security property that really eliminates a lot of attack vectors. 

And then finally, the third benefit of actually being on this device, anchored in this device, of course, is we can give the user a much better user experience and we can report on almost an infinite number of security signals around the identity and the device without ever having to ask the end user to engage in interacting with a password manager or to go find their mobile phone, maybe a mobile phone is not even allowed in the environment, and respond to a push notification. 

It's just a much cleaner user experience. So just a quick picture of what the world looked like before, right, we use passwords to access machines but machines use certificates to access other machines, right? Technically, they use private keys verified through certificates but all established through a chain of trust. Well, in our system, we actually do away with passwords and re-leverage that same technology. 

And this is kind of a key idea that we'll hit a couple times. We're not reinventing any cryptographic protocols or algorithms, we're reusing things that have been time-tested in a new way to eliminate passwords as the primary method of authentication for the end user while improving usability for them on how they access services while providing a proper set of controls to security around, again, that framework that I mentioned before that is enabling to their workforce, right? Work from wherever you want, use whatever device you want, try and access any service. 

Now, I'm still going to imply that critical services have to come from high trust devices and maybe a high-trust device is only a device that's locked down with very specific things on it but I'll be permissive for low criticality things. So earlier, we talked about any acceptable solution has to be continuous, right?

So what does that mean? Well, device statuses change. How a device checked in yesterday is not really the status of the device today or even how it checked in 10 minutes ago is not its current classification. And the other thing that we all need to remember is generally, we're dealing with the law of large numbers.

A big enterprise is going to have 1,000 users, 10,000 users, 100,000 users, a big company with a big customer base might have tens of millions of users or even hundreds of millions of users. So a small percent, right, like 0.1% of devices being outside of compliance turns out to actually be a fairly large number whether we're talking about our workforce or our customer. And so without some sort of continuous-based approach, you're not really handling that large number. 

And just kind of to reiterate that point we talked about before, you know, here at Beyond, we're not really inventing new algorithms or cryptographic protocols. Our focus is really on taking things that have been tried and true and integrating them in new and novel ways and unifying them with things like unified policy in leveraging these advanced capabilities like TPMs on devices to make sure that keys are anchored and really putting the control back in, you know, the administrators and so security architects in terms of you are allowed to decide what level of risk is acceptable for what sort of critical applications, sessions, or transactions, however, give the customer the end user back, a great user experience on how they don't have to, you know, remember a large number of unique strings. 

They don't have to carry additional devices around with them. They can access low criticality things from personal devices in a very simple and seamless way. And of course, all of it gets wrapped up in simple…all of it gets wrapped up in kind of a simple administrative model. 

So and just to be a little bit more clear, our system today, we can integrate with any device or any application that speaks SAML or OIDC or OAUTH. Under the hood, we're relying on X.509s to kind of anchor our trust. We have integrations with SIEMs for data export. We have integrations with existing SSOs. 

So if you're already running an SSO, it doesn't take very long for you to actually get a trial set up with us and immediately start to see what we're talking about. And of course, we also have integrations with existing MDMs and EDRs. So if you don't have an MDM or an EDR in place, we can give you a large amount of that read capability directly in our console and the ability to write policy over. 

If you do have MDM and EDR in place, we'll give you the ability to actually write policy that's even more fine-grained and takes advantage of signals coming from those platforms. So just to kind of the last slide, you know, we've talked about the history of passwords and how or the history of access really in authentication and how it's really focused on I have a password, I need a longer password, I need a high entropy password, I need a high entropy password that's unique with every service, I need a high entropy password that's unique with every service and a 2FA or MFA with every service to how do we simplify things with platform authenticators and just leveraging more modern techniques. 

But that's not enough either, right? We also then need to move into leveraging these zero trust primitives. So with the zero trust primitives, it's again about continuous risk assessment. So how do we know when things change about the identity of the device and how do we upgrade or downgrade the authorizations in response? And of course, the minute you get into kind of policy-based rule systems, you very quickly realize that I can, you know, 20% of the population can probably write the complex rules but 80% can't.

And so then you need to get into things like rule synthesis based on kind of behavioral observation, and that's where kind of modeling comes in and whatnot. But anyway, that is the end of my talk. I see a couple of questions came in. It looks like we just have a few minutes left so let me go through this. S

So we have a question from Thomas, "Is that only designated to sanction new devices? What about incorporating it into legacy Linux and Unix also?" 

Okay, so I think I understand the question and I'll respond and if I don't actually respond correctly, just ask it again and slightly rephrasing. So our platform authenticator, it will work on legacy…so by legacy, you mean a device that does not have TPMs or enclaves, our platform authenticator will work on those devices. When you get into the details, the way that shows up is through key provenance. 

So with every identity, so in our system, there's an identity and then an identity has what's called bound keys. And a key is an asymmetric key pair, right, so we all kind of know what that is, wrapped up in a certificate. And in TPM systems, obviously, it's attested to by some of that native hardware and in an enclave, there's a similar thing that you can kind of do. 

In a legacy system that doesn't have this, you basically just don't have that local attestation. So the platform authenticator will still work but you don't necessarily have the same level of trust that you get through a TPM. And what we typically see our customers do is they'll write policy that carves out, for legacy devices, they may not consider them high-trust devices, they may consider them like a medium-trust device, and just not allow them to access things like payroll or monetary transfer, that sort of thing. 

But the key idea is actually, our platform authenticator will really work on any device, Linux, Windows, MacOS, iOS, Android, whether it has an enclave or not, but the keys that it's able to construct will have different provenance and how you want to let…how you want to treat that from a device trust level is something that you just configure in policy. 

I can just expand a little bit on that previous question unless anything else comes through. But, you know, again, key idea at our company is we didn't want to try and invent new crypto primitives or protocols, we wanted to try and use what existed. So at the top of our model is an identity, right? 

And identity really is kind of some metadata with an internal unique identifier, and then credentials are bound to that identity. So a credential is bound to that identity in a very specific way. You construct a key pair, key pairs are always constructed locally in the platform authenticator, not in the cloud, right? We never really have keys in the cloud. 

When they're constructed in those TPMs, there's a hardware, or the enclaves, there's a hardware guaranteed that those private keys can't move. 

The certificate, it's then…the certificate that actually contains this material also traditionally contains that identifier, that unique identifier related to that identity. So when that certificate is signed, you can think of it as basically being sealed, right? So that's how we know it points to that particular identity. 

There's something else called provenance of identity, which has to do with, well, how do I know this virtual identity points to this physical identity? And that gets into some identity proofing topics. But similarly, when you go through identity proofing, usually there's this challenge, right, prove to me that you are Jasson Casey. 

So I would do it by showing you a picture of my face and moving it around, like I'm not a robot and then hold up my passport. And what would happen is that we compose into this request, that request would get signed, right, so they can't be tampered, man in the middle, integrity, protection for insider threat, all that kind of stuff, shipped off to a proofing vendor. The proofing vendor compares the image of the actual face to a government database, right, not the image from the passport, it compares the passport, is it valid, is it in circulation, when it decides that's all good, it then gives an answer with some additional metadata, signs that whole thing so it's sealed.

So this concept of integrity protection and sealing is also kind of really strong in the system. But key in all of this is key pairs are constructed on the machine that's running the platform authenticator. If that machine is produced in the last three years, there's usually a strong guarantee that private key physically can't move. 

So the attack vector is no longer I get a database, I have all these keys, the attack vector is I have to go after a singular endpoint. So it really kind of changes the model from like a linear model to a constant model, which is great. Like, we're like de-amplifying the event space so to speak.

Learn more about risk-based authentication. 

‍