 Good evening everyone, welcome back to theCUBE, the leader in live tech coverage. We're live in Las Vegas at Caesars Palace, CrowdStrike Falcon 23, the seventh Falcon event. Over 4,000 people here. We've seen a lot of growth in the ecosystem of CrowdStrike. We're pleased to welcome Beyond Identity next. Couple of guests, Jason Casey, CEO. Kurt Johnson, Chief Strategy Officer. Welcome gentlemen, it's great to have you on the program. Thanks for having us. Thank you. Jason, start us off, give us an overview of Beyond Identity. Who are you guys? Why was the company founded? So we are a four year old startup and the inception of the company really was kind of two key ideas. One was password suck and why are we still using these things to actually authenticate? And solving that was kind of a very obvious do this thing with like a mobile HSM and use what's available in phones and modern laptops today. And the second idea was, well, wait a minute, if I now have a footprint on your device that's actually managing this authentication that doesn't involve a password, I now have an ability to answer other security questions. Are the security controls I expect relative to what you're trying to do present on the device you're actually working from? And that really is like the most important question you can answer from an access perspective, right? Access is the bridge. Everyone drives over to get it data and to get it services. It is the ideal place to answer the question not just who you are and what you're trying to do but are the things I expect on the device that's going to receive the data actually present. That was the original impetus. That was four years ago, fast forward today where we've got more than a hundred employees. We've got, now I'm actually remembering who can I actually talk about and not talk about? We have a lot of paying customers. Some of the big ones you can see on our website. But yeah, this is the use case we saw. Kurt, talk to us about this strategy that you've employed and how the partner ecosystem is really a catalyst for that. Yeah, it's been a critical aspect of our strategy from the beginning is bringing in the partner ecosystem. To Jason's point, how can we provide the highest level of assurance not just on who is gaining access but what is gaining access? And while our application does that very well it was built to design to tie in to the identity ecosystem that was already in place at these companies. They've made investments and identity provider and single sign-on solutions for years. And how do we enhance that and add a layer of security on top of that? Because as we've seen in the news lately a lot of the identity aspects are, identity management started really an administrative task to make it easier for people to get applications, get access to them, not necessarily secure them. So tying into that ecosystem but the reality today is we've seen the requirement of organizations investing heavily in their security ecosystem a lot around detective response. So almost the philosophy and the ideas we expect somebody's going to get in. So now let's find it as quickly as possible and prevent any kind of actions. What we were thinking is how do you take all of that rich signals, that rich data and bring it to the point when you want it most which is when somebody's gaining access? So we really built out the platform to tie into products like CrowdStrike that can read risk signals on the endpoint and make authentication decisions about them. With partners like Zscaler to make that a continuous process because the other big aspect of our strategy is that we're calling it zero trust authentication. First eliminate the passwords. First and foremost make authentication fishing resistant pulling in the device signals as Jason just mentioned but then tying in through third party integrations the rest as many risk signals as we can to make a true determination at that point of authentication that you know exactly who and what is gaining access. So passwords do suck. We all hate them. But what sucks worst is the user experience, right? Across because we have application creep. I mean, there was the day you're like, oh, wow, cool app. Now you're like, another app. Did you download the event app? No, I haven't and I'm not going to. But the ones that we really use are vital. You know, our airline apps, they're critical and we constantly going through lost password, going through the questions that we can't remember the answer to, update the app, close it, re-install it. So what's needed, I mean, I wonder from, you know, if this is even feasible, a horizontal platform that we can bring across the industry and have a common user experience. I mean, it's, I know the big internet companies have tried to do that with single sign on but that doesn't work either and there's a feature rich or lack of feature richness. So is that the objective to create that horizontal user experience? And is that even feasible? So, yes. And it kind of starts with two key observations at least from a security perspective. If you're the average company, 80% of your security incidents have to do with some sort of access compromise. And the two large buckets that mostly contribute to access compromise, credential theft, right? And the second, it's a little bit more technical sounding called the signing full exploits. Maybe you've heard them like man in the middle, man in the browser attacks, those sorts of things. The easiest way of solving credential theft is what if you could ensure a credential couldn't move? Turns out modern hardware now comes with these things called enclaves. They're tiny little processors, they're not in your CPO. You can create a credential in the enclave with a property that it can't move. Can't move, it's never in memory. It's never in memory, can't be dumped to the file, can never leave the system, never goes through the internet, never touches any of these third parties. So if it doesn't move, you can't steal it. The second category, how do I guarantee that I can't actually interdict the authentication? The weakness of passwords, the weakness of TOTP, the weakness of Microsoft number match authenticator, the weakness of push notification, they all require a human to execute the protocol on the client side, right? It's a machine on the server side. Humans have error rates, right? Maybe some are worse than others, but we all have error rates. Why can't we mechanize the client side of the protocol? And like the simplest way I can put that is when you go to a site and you dump your password in, right traditionally, or you put your TOTP code in, it's kind of on you to know, is this the legitimate site? And yeah, your company's going to have a bunch of controls trying to screen this out, trying to screen that out, but they're going to have error rates too, right? It's a probabilistic problem. Doesn't have to be, right? The challenge can be part of the protocol. The challenge can include who the challenger is. The key that's going to assign the challenge can have some associated data saying who the valid challengers are. There can be a bi-directional signature verification and only move forward if the challenge itself is signed by the appropriate person that originally agreed to enroll the key, right? So you can mechanize the elimination of that man in the middle, that man in the browser attack. Those two categories can actually be prevented or eliminated, not reduced, but actually eliminated. So the credentials crisis can be solved. For that, and there's a couple other things that sound and smell and taste like credentials. What is a session cooking? What is an access token, but a password by another name? Most companies implement them terribly, treat them like symmetric secrets, move them around all over the place. Turns out you can buy those on forums just like you can buy passwords and credit card numbers. That can be solved using the same mechanics as well. So our mission, we're a security company solving identity problem. We don't really believe identity companies solve security problems. We believe they solve productivity problems, maybe create security problems. And we think it takes a principled approach to really kind of get there. It's so true. I mean, what you're saying, go ahead. I was just going to add, Dave, I mean, to your point, the system we created into, you know, when password just became the way to do it, then we had to layer on multi-factor authentication. Somehow we created a process in a system that made it increasingly difficult for the good guy, the end user, to gain access while making it increasingly easy for the adversary to do it. So we created this balance here. And we often say, you know, you don't need to break in anymore, you just log in. And so that is how we've come to accept the fact that we can train that away. I mean, we train people that smoking's bad for you, but I don't know if you walk through the casino. It's not eliminated. So like we need to ship this to JSPO at any time the humans involved in the equation. We've added friction. And we've also increased vulnerability because unfortunately, humans are going to do something wrong at some point in time. What's your vision of a passwordless future? Is that a direction we're going in? No credential of any type should ever move, whether it's a password, whether it's a session cookie, whether it's an access token, whether it's an SSH key, whether it's a GPG key, like all credentials should never move. They don't move, they can't be stolen. Credential usage should always be guarded by policy. As much of that policy that can be baked into something called trusted computing should be, and that's just a fancy way of saying there's a hardware proof that what I expect is happening is happening. There's a log that gets created that I can always validate offline and see if something went wrong. And my only real assumptions in this whole process is that the foundry at Infineon hasn't been compromised, right? So is there a vulnerability in the system at some point? There could be a particular avenue, but it would almost require taking over the chip industry. So the vision for the future, ultimately, is authentication should always answer the question, not just of who you are, but are the things I would expect on your device, action on your device, relative to what you're trying to do? It should prevent credential theft, not reduce it. It should eliminate man in the middle attacks, it should not reduce it. It should be easy on the end user and it should be easy on the administrator. Writing policy to be really restrictive on people that cause problems versus permissive on people that don't is another key part of the equation. So you know, part of what we've been saying forever, it's changing the way that the world logs in. We know there's a few billion passwords out there, so it'll take a little time, but we've really made it our direction. We do this for the workforce, for employees and the applications they log into each and every day. We do it for customers and companies customer facing applications. So this applies equally as well, whether it's a user experience that they love it so they don't have to log in with passwords, they can do it from one device, they don't even need a second device. We'll at the same time making it hardened and more secure for the organization. It's a true win-win, so I think we have that, but as I said, we have a few billion passwords to get rid of out there. Explain why push notifications through SMS for the audience, why push notifications through SMS don't cut it. Sure, there's two reasons. The dumber reason is actually easier to explain, which is I have your password and I'm trying to log into an account and your phone keeps getting a push. You just hit no, you go back to watching TV and Netflix or TV, I do it again, you hit no, I do it again, you hit no, I do it again and finally you're like hitting yes just because you want it to stop, right? And that's called push fatigue. So that's the dumb answer and that dumb answer has a non-zero rate of occurrence. But again, if you turn it up and you spray, you're going to get success. The slightly more sophisticated, but still you can execute this with a tool that you downloaded in five minutes. That phone, that push notification doesn't have any context with what's going on in your device. It doesn't know, like if you're holding your phone and you're holding your device, there's no concept in that push that the device in your left hand is actually what's actually initiating the authentication. Those are two disparate channels with no shared context. So if someone has interdicted your connection and they're just relaying your credentials to the target site and they generate a push that just goes around back to you, you still think you're logging into a legitimate site, they're just relaying everything to you so it looks legitimate. They social engineers are you saying, hey, I need you to do this thing real quick. So you're like, oh yeah, I'll do it real quick. And then you approve, right? With the push or you put your TOTPM that goes through in the side channel. The adversary now gets the release on the access token. They can push it back to you so you still know nothing's happened. But now if they want to, they can jack your session, they can move the token to another endpoint and they are you. They can enroll another device, they can do a password reset if it's a legacy system. There's no shared context. We think this is like what Jason's talking about is the skill of an advanced adversary. You can get these kits available for free and with just the most basic of skills you can spend if they made it a paint by numbers approach. So it's not in a sophisticated adversary. I was talking with a CISO, they had a real incident where their head of treasury got a call from one of their employees because there was an emergency need to wire a significant amount of money and it required the head of treasury's approval level. It was a legitimate claim, a legitimate transfer, a legitimate employee calling them. He just happened to be eating breakfast in the concierge lounge of the hotel. And so instead of going back to his room to his company-hardened machine, since there was an urgent need, just went to the computer in there, logged in with his password, got the push notification, entered it, wired the money, signed out, there was malware sitting on that machine that allowed somebody to see all this and collect all this, went immediately back into that system, wired a whole bunch of more money to the wrong places. So you think it's rare to find it's increased happening just over and over again. Another common question, explain why facial recognition doesn't solve this problem. Oh, so there's a couple of things with facial recognition. First of all, if you just stop with facial recognition, that's kind of a password with another name, it's a symmetric piece of data. So it's in the minute someone steals that data, they can now present as you. There's also a privacy concern, a lot of people don't want, they're biometrics stored on services that aren't healthcare or gov or even in those conditions. There's another technology called biohashing where you take the facial, just call it the data that represents the face, take a random number, you run those both through a hash, it's kind of like salting passwords if you will. There's some challenging issues with those. They're not a substitute for asymmetric cryptography. Asymmetric cryptography, just doing digital signatures is truly how authentication should work. When you do that, the private key doesn't have to move. If you do that on a machine with an enclave, you have a guarantee it won't move. That's really the bulletproof way of eliminating these two classes of problems. Everything else is really just trying to chip it ice. Yeah, big trade-offs. Not to mention, by the way, when you're on a laptop, it's a completely different experience than when you're on a mobile app. No, right. It's just, again, the consistency, I love to what you said, Jason, you look at identity as a productivity problem. Because that's what it is. We waste so much time, we get so frustrated, and it leads to mistakes that we make because you just push on the wrong button. So how do we get to that point where the user experience is that nirvana that you're envisioning? Well, I mean, obviously we want the answer to be call us. But if you're not going to do that, what you need, you need an authentication system that's based on digital signatures, asymmetric crypto, that's actually leveraging the enclaves that exist in all three of these devices on the desk. Almost any device that you could buy is going to have an enclave. Even the cloud providers now provide enclaves in their virtual machines, right? Amazon calls it Nitro. So you need an authentication solution that uses those. It also needs to do something called fish resistance. That's the man in the middle prevention. NIST gives it this really simple name. They call it verifier impersonation resistance. But it's a thing. So you need a solution that does those two things delivered by a company that cares about user experience. And I think that's why the password list has become a very popular thing. You went to the RSA conference, you had a black hat, you see it on every booth. Where it starts and stops the similarities that takes the password away from a user experience. Doesn't take it away from an adversary who can use it. Doesn't take it out of that sequence. So yes, user experience, critically important, but it needs to be combined with all the other aspects. Which is architecture that takes advantage of these capabilities so that credentials aren't moving. I mean, that's the bottom line. That's what I wanted to do. Just to double on what he just said, if you go search for password list, you're going to find 300 vendors. Login through email magic link is technically considered password list. What we're talking about here is like actual secure authentication that has a great user experience. Bit different. I'm sorry, go ahead. No, that's a great point. But again, it gets back to architecture. Actually taking advantage of modern capabilities. First principles. It absolutely comes back to first principles, right? For 10 years, so it's like the blessing in the curse. 10 years ago when this all got started, the best we could hope for was great forensic tools that let us respond quickly. And it's built this whole industry. Now, modern electronics have advanced to the point and authentication protocols have advanced to the point where we actually can solve some of the root problems that were causing breaches or at least initial access back to those two categories. So yeah, technology, architecture is fundamental. It does require principle thinking. You do have to kind of go back to the basics. But at the core of it, it is still pretty simple. Credential shouldn't move. You should have a guarantee they don't move. You should take the human out of the loop. If there's any part of the protocol that the human is ever responsible for, that's an entry point that an adversary's going to study and take advantage of. What's your favorite customer story you mentioned? I'm looking at the website right now, a lot of great names that you think really articulates the value of what's beyond the known names delivery. I'll talk about the stories I won't name the customer. Cool. So we basically have a couple different variations on a theme. So one variation on a theme was customer started deployment, very conscientious, scaled over a very long period of time, experienced an incident, didn't impact any of the devices we were installed on. And then within 30 days, we were on everything. So it was just like we played a role in an incident to very quickly kind of secure the solution. As well as when you have a credential anchored in hardware, whether it's anchored in the adversary's hardware or the customer's hardware, it's anchored in hardware. So you actually know most people have an inventory of your hardware. So even during incident response, you can actually partition the adversary or they're in a VM in which case they can't pass the hardware TPM check. And again, you know they call themselves out and you're no longer disruptive to your work population, you're not telling everyone to reenroll or go see the security person. That was pretty interesting. Another one was discovered by a CISO at one of our own companies. It was a use case, we didn't even fathom. So in our authentication system, we have this big policy engine in the cloud. So it lets our customers basically say, you know, for BYOD, we only want to check a few things but let's limit only to these apps for managed devices. We want to check that, you know, crowdstrikes running and they have a zero trust score of X and all of these other controls. We want to check that the process that's asking for the authentication was launched from a signed executable built by Microsoft or Google and no one else. A customer had started writing policy rules but rather than using actions like allow and deny, they were using these actions called monitor. And what this does is anytime one of these rules hits it generates an event. And then they were basically building a picture of compliance issues across their fleet just using an analysis of this event flow from the policy engine. All of a sudden we realized there's this passive device trust angle to the product that we didn't even think about. So now we've kind of turned around and practiced it to push it out quite a bit. But understanding what's going on in your fleet, understanding where you have hardware issues, where you have software issues, helping you actually prioritize based on what's going on in the world. Where am I going to get the most bang for my buck? What should I actually work on next? And then the other one, less from customer deployments and more from just selling, getting in and showing actual exploits against products and systems. It's been fun actually. It's also been a little scary in terms of like, it's pick a vendor. Yeah. Yeah. I'll have one quick story. One of our early customers, COVID happened, everyone went working from home, everybody accessing from home on these devices. They had to crank their VPN through the roof in order to kind of get some better visibility. Really came and bought beyond identity, specifically to make sure only corporate managed devices were getting access to the applications. It was really that device posture, visibility, the assurance and went full to every employee, every end user. And all of a sudden the end users no longer had a password. He said, he finally got the visibility needed to get rid of having to put all of this through the VPN with multiple hops and push notifications. All of a sudden he started getting thank you emails from his end users who are like, oh my gosh, this experience is incredible. And he said, I've never rolled out a security product in my life and got a thank you. That's for sure. Kudos to you guys. Great stuff. Great stuff. Thank you so much both of you, Jason and Kurt for coming on, sharing what beyond identity is doing. The immense capabilities and progress we have going forward to really combat the credentials crisis. We appreciate your time and your insights. Thanks for having us. Our pleasure. For our guests and for Dave Vellante, I'm Lisa Martin. You're watching theCUBE live in CrowdStrike Falcon 23. We back with our last guest of the day. Stick around.