Listen to Jasson Casey, CTO at Beyond Identity, and Max Kurton, Head of Content at EM360, on the "The Next Phase of Cybersecurity" podcast. 

Transcript

Announcer

You're listening to "The Next Phase of Cybersecurity" podcast. With this series, you can stay up to date with all the latest information and trends in the cybersecurity space by hearing from today's leading analysts, end-users, and vendors so that you can be prepared for all scenarios to help protect your business.

Max

Hello and welcome to "The Next Phase of Cybersecurity" podcast, an EM360 production. My name is Max Kurton, head of content here at EM360, and your host on today's podcast. Now, in today's episode, I'm being joined by Jasson Casey, who's the CTO at Beyond Identity. Jasson's here to debunk the myths about passwordless authentication, exploring its value, benefit, and key role for businesses today. So Jasson, welcome to the show. Thanks for coming on today.

Jasson

Thanks for having me.

Max

Very welcome. And before we delve into today's questions, would you mind just giving us a bit of background on yourself and Beyond Identity?

Jasson

Sure. My name is Jasson Casey. I'm the CTO here at Beyond Identity. I've been building infrastructure and security infrastructure for about 20 years. I got started with Beyond Identity back in 2019 when we first got started. The company's mission is to solve authentication for people that's both usable and takes user design and UX into account and provides the controls a security team expects to help them manage, you know, their typical functions their typical security controls.

So it really kind of got started as a workforce product but then we also realized that the core cloud services and libraries that we use to build our workforce product could also be used as a SIAM offering where customers, or Beyond Identity customers could actually get the Beyond Identity experience for their end-users by building directly into their apps.

So Beyond Identity, we're a two-year and change old company, and we're focused on making authentication easy for end-users, but at the same time, actually providing rich security and fraud controls for platform and workforce administrators.

Max

Excellent stuff. Yeah, I had the privilege of doing some work with Beyond Identity in the past and big fan of what you guys kinda put out there into the market. So I'm excited to pick your brains a little bit here, Jasson, and get your thoughts on the topics I kind of mentioned at the start of the show. I think a good starting point for us to kind of talk about here is to help bring our listeners into what we're gonna be talking about.

So let's just go through from your perspective and what you're seeing in the market today, what are the current myths and misconceptions about passwordless authentication and how would you describe the current state of security solution?

Jasson

Sure. So passwordless itself is a giant fishing net that it seems like many companies are kind of using to catch possible attention. And we've seen it be used for things like emailing magic links to customers. I.e, you don't have a password, just click on this link in your email and it will log you in to your service, to people suggesting that passwordless could be actually managed by password manager tools. And really those are kind of passwords by another name.

Like, when we say passwordless at the end of the day, we mean a couple of things but first and foremost is rather than having a symmetric secret, like, a traditional password system in a service provider's authentication database, we move to asymmetric secrets or strong crypto. And so what that basically means is the database that's used to try and help authenticate whether a user is who they say they are, it only contains public keys.

So if the database was ever to be leaked to reveal, it's only leaking information that helps identify a person as opposed to authenticate that person. So that's kind of one key thing. Another key thing is in asymmetric cryptography, remember you have a private key and a public key, and by design, the public key is meant to be given out to everyone. And that's how people can validate who you are.

We take the private key and we construct the private key on behalf of the end-user. And we do it inside of specialized hardware inside of most modern devices. So most modern devices that people can buy, iPhones, Androids, modern Windows PCs, even Chromebooks and macOS, desktops and laptops, they all have a specialized hardware function now that lets you construct keys inside of them, asymmetric crypto keys with these really nice properties that the private key physically can't be removed from the device.

So, when we say passwordless at Beyond Identity, we mean moving from symmetric cryptography, or at least symmetric secrets for authentication to asymmetric secrets, using strong crypto, pinning that private key inside of hardware, doing all of this on behalf of the user to where they don't actually have to understand what's going on. So actually improving the usability experience.

And then providing authorization policy to access that key and to use services in the cloud that really helps customers match kind of their unique risk profile to, you know, the transaction that the end-user is trying to drive. Or more simply put, allow low trust devices to do low critical things like check email. But for high critical things like move money, maybe require the device to be high trust.

So when we say passwordless, we don't mean let's substitute password access for email access. We mean strong cryptography, we mean really kind of using modern security techniques while improving the usability to kind of try and improve outcomes for both audiences, end-users, and workforce or platform administrators.

Max

I think that definition is very important to kind of make there because there is, as you're saying, this misconception if someone says passwordless, it's being spread out as a lot of terms. And this is something I kind of wanna explain as we kind of go through the show because another element of this, and I think hopefully this should be the easiest question I'm gonna ask today.

But, you know, InfoSec leaders, we know that passwords are kind of described as this number one attack vector because of breach theft attack. You know, they're fundamentally insecure as a concept. So the question to fire you is should enterprises get rid of passwords and go passwordless once and for all? And why are some organizations still holding onto passwords even though they know the risk of them?

Jasson

So just to kind of reiterate a key point, like most incidents don't start with a really complicated exploit. Most incidents start with someone using valid credentials in an invalid scenario to log into a service as opposed to breaking into a service. And, you know, depending on whichever statistics you like, I've seen everything from like two out of three to 80% of incidents, they all start with valid credentials being used. Credential stuffing, credential theft, or when we get over into ransomware things like brute-forcing kind of either simple or well-known passwords in RDP services.

So in all of those cases, clearly the initiation of the process, the protections just aren't working that are actually in place. And so when we talk about using passwordless for that specific instance, what we're really saying is we're kind of saying disrupt the initial vector of most of your incidents today by preventing people from being able to use valid credentials or credential stuffing.

Now, that only is possible if you're replacing it with a system that number one, has that asymmetric property combined with the fact that that private keys are kind of locked in the hardware. I can't credential stuff if I can't move the key off the target device. I can't credential stuff if I can't get access to the key. So that's kind of one key thing around passwordless and how it actually disrupts that initial vector, so to speak.

But the second part of the question is, how far should you go? At the end of the day, the goal should be, how do I protect all access of my workforce to critical services and non-critical services? But the reality is, is every business is gonna have some sort of legacy services where there's always going to be this question of how far in do I push this new service, and is it even possible? And honestly, that can be a very business-based decision.

So for instance, we've run into customers where they may have some old mainframes, where the old mainframe has no hope of speaking any sort of modern authentication protocol. And so in some of those scenarios, what they'll end up doing is they'll do deployments in phases and they'll restrict the mainframes to a certain small audience and kind of leave the legacy techniques in place.

But for 90%, 95% of the rest of their use case and where most of their risk actually lies and how incidents actually start, they're going to basically, as more marketing group likes to say, like, shut the doors on invalid credential usage.

Max

Yeah. I think that's interesting to kind of look at that approach and how it kind of comes into this. And when we're talking about these organizations that are still holding onto the passwords in a roundabout way, they're being sold these go-to security solutions of password managers and MFAs. So for those people who are still using passwords, and some of them might want to remain using them, how effective, sorry, are they really?

Jasson

Again, like most incidents today start off with the use of valid credentials. And for the effectiveness of things like password managers, I would basically just ask the question along the lines of like, you know, are your non-technical friends, family, spouses, parents, siblings, actually using password managers? Password managers have a usability problem combined with the fact that they're helping people really kind of just plug into a legacy model of authentication.

So password managers really aren't... Again, when they bring such a usability problem to bear, everyone has kind of seen when they bring poor products to their user base, their user base is usually gonna find workarounds and ways around using those poor products to try and get the experience they want. And we kind of look at password managers in that similar space. They don't really have a high usability component, therefore they don't have much penetration or adoption.

So then we look over at MFA, that becomes more interesting but a lot of MFA is a fairly kind of weak secondary channel using non-private infrastructure, things like SMS and email delivery and whatnot. And it could go much, much further and eventually you get this dovetail of, like, kind of a modern MFA and passwordless into something that consolidates.

And kind of our view on that at Beyond Identity is, you know, the optimal solution is a solution that gives me kind of multiple dimensions of factors when I'm authenticating a person, gives me a policy layer where I can quickly kind of slice and dice my enterprise to kind of match the authorization levels for the moment. If someone's trying to do something critical, make sure that their device is high trust. If it's not, then that's okay as well but, like, really giving that capability or that level of control to the administrator is kind of key. And when we say establishing trust, we don't mean, you know, a toggle switch that says, "Hey, Beyond Identity thinks this is high trust."

We mean fine-grain policy that lets you the customer administrator say, "For me, high trust is the firewall is enabled, the discs are encrypted, CrowdStrike is running, jam for Intune is running with these explicit policies. These registry keys have these values, or these P lists have these values." Like we mean a very precise thing that you can define that really kind of crafts the risk model according to your enterprise itself.

Max

And again, that definition is so important and especially important for a lot of organizations to understand as well. So thank you for those kind of definitions there. And before we kind of switch gears in the conversation, it would be nice to kind of understand from what we've been discussing when we're talking about passwordless authentication, what are the short and long-term business benefits of implementing it?

Jasson

I mean, the most obvious short-term benefit is again, like, stop credential incidents happening. Stop the invalid use of valid credentials for unauthorized people starting to create an incident in your infrastructure. You know, whether it's our solution or someone else's solution, you gotta move off of symmetric secrets and kind of legacy passwords. You know, the plug for us, of course, is we can get you up and running in about 10 to 15 minutes.

It's really easy to try out and that's kind of our push as we spend a lot of time on integration using kind of common and open protocols, things like OAuth and OIDC and SAML, where we can plug right into the back of your existing SSO or IDP provider and you can immediately kind of see what this looks like. The long-term implications though is this starts you onto your zero trust journey.

"Oh, zero trust. Great. I hear that all the time. What does that actually mean?" The premise of zero trust as far as we're concerned is how do you build trust continuously and really almost at the transactional level. Any user on their laptop or their phone, they're constantly doing things. They're logging into Salesforce and checking a forecast. They're logging into bill.com and paying a bill or moving money. They're doing things that represent risk to your business.

So how do you know that every time they mash a button to move money or to retrieve a forecast or a key competitor set of research, how do you know that if the user is who they say they are and the device they're using is in compliance and actually is sufficiently protected to either receive the data or to trust to issue the monetary transfer? So, like, the long-term implications of moving to a technology like what we're describing, is we get you onto that journey. We give you a transactional model of security, and we assess trust essentially on every button click, every transactional request that's issued from the device or the mobile phone. And one other kind of key thing to point out there about Beyond Identity is in our model, we have a cloud service and we have what we call a platform authenticator. Our platform authenticator, it runs on the machine the person is using to pay that bill, to pull that Salesforce forecast, not on a secondary phone but on the device they're actually trying to drive the transaction from.

By being on that device, we have an ability to see the security state and posture of that device in real-time as the person is trying to pull the forecast or move the money. And that real-time nature of security posture to wrap that transaction, that's really starting to fulfill the continuous scrutiny of continuous authentication and authorization that zero trust kind of calls out when you dig into, like, the next definitions of it. So, sorry, that was a long answer but the short term is help yourself and reducing incidents. The long term is start your journey on zero trust because ultimately you're gonna have to go there anyway. The workforce is changing in a way where you're just gonna have to figure out how to run a security model when your workforce is working from anywhere, possibly on any device, you know, accessing apps that they need for their business.

Max

So, as we all know, traditional security perimeters really dissolved in 2020, the influx of working in the cloud, and it resulted in the expansion of attack surfaces across the board. So which modern remote access threats do organizations really need to be most aware of going forward? And how does passwordless authentication work to combat that?

Jasson

Sure. So just to kind of recap, 2020 and even 2021 is gonna continue the theme. The world obviously has changed and how people work in it has changed. So one of our customers likes to kind of quote this simple line that we repeat, which is, you know, "The internet is your network. Any device is your work device and your data center is now the cloud." And what they're really just trying to say is you can't count on where an employee is going to be, what device they're gonna have access to. And they're probably not connecting into things that you directly manage anymore, as opposed to cloud administer. So how are you going to establish security controls in that new architecture in a way that you can afford, and in a way that you can kind of fit in, you know, the mental headspace of a reasonably sized team? How do you do something simply but effective?

So, those changes they're here, and the interesting thing about not just a passwordless solution but a passwordless solution that actually built an identity architecture from the ground up to support security controls. This sort of product or this sort of capability has an interesting and simple way of you reestablishing security controls in that complex work environment.

So an identity-aware security platform or an identity platform with security hooks, it's always going to be in the middle of every transaction. It doesn't matter where someone is in the world. It doesn't matter what device they're using or what application they're connecting to from a work administration perspective, every one of those transactions is going to have to get authenticated and authorized. And so another way of putting it is it's naturally gonna run through your identity platform.

So if your identity platform had some sort of security knowledge or had some sort of understanding of, you know, like the five NIST functions, identify, protect, detect, respond, and repair, it could help you layer in these security controls purely from an identity perspective. So a passwordless solution that uses a platform authenticator and kind of combines device risk into the whole equation is naturally like this sort of solution.

And so what we've done and where we've been successful in the year of 2020 and I expect is to continue in 2021, is helping customers specifically enterprises accelerate their journey in this fluid enterprise architecture where people truly can work from anywhere. And when I say, when people could work from any device, I don't necessarily mean that on an untrusted device we should just go ahead and let them do risky things. What I really mean is match the trust of the device to the criticality of whatever they're trying to do. And if they're trying to do something that's not critical, then you know what, we're gonna let them use their BYOD device as long as it's not jailbroken.

But if they're trying to move money, maybe the device they're moving the money from, you know, it really ought to have our EDR solution running. We wanna make sure CrowdStrike is up and running on that device. We wanna make sure that the firewall's enabled, that the ransomware RDP filters are actually in place. We wanna make sure that RDP authentication is configured properly. We wanna make sure discs are encrypted. So what we mean there isn't willy-nilly have at it. What we really mean is match the specific risk of the environment to the criticality of what someone's trying to do. This is how we say companies can be more permissive but still have established security controls that stand up from a compliance perspective.

Max

I think that's the wisest approach that organizations can take because obviously, this is something that has happened very suddenly. But they do need to be on the ball about how they approach it. And I think understanding the critical level and what kind of devices being used is gonna be so important going forward.

And just to expand on that a little bit further, because device trust is a building block to that kind of strong authentication of what we want, but how do you really know if a user's endpoint is secure enough to protect that most mission-critical data? And we were talking about zero trust earlier. So talk to us about how this device trust relates to zero trust.

Jasson

So zero trust is a set of requirements. And you could think of it as a set of design objectives and requirements. And obviously, it's more complicated that I'm gonna give you in 30 seconds, but at its heart, Zero Trust really just means don't assume security exists, build and verify the security controls that you expect, and do it continuously. Just because the controls existed a minute ago, doesn't mean they existed now. So you have to rebuild and reassess.

So why do I trust a device? Do I trust a device because someone dropped a certificate on it 18 months ago, and that represents a flag but yeah, they ran it through the device set up properly? Or do I trust the device because I actually inspected security posture and the inspected security posture actually matches the security posture I expect to be on that device? Because the private key rooted in a TPM that fundamentally is unmovable assigns things according to a signature that I expect based on the knowledge I learned when I bound that device from six months ago.

So the difference in a zero trust model or not, it's really build the level of trust, don't assume and rebuild it continuously. So device trust as we've talked about from our product is more about a solution or put in another way, how do you achieve those requirements? What is a design path to achieve those set of design objectives of build your own trust and do it continuously?

And so, again, when I said, like, the architecture, again, this is kind of a 50,000-foot viewer cartoon architecture, we'd get into more detail obviously if we had to learn more time. But there's a cloud service that we run and there's a platform authenticator that runs on your device. The platform authenticator in the cloud, they have a ceremony or a protocol that they engage in on every transaction to try and establish what is the current level of trust of the device? What is the criticality of the application or the transaction the person's trying to drive through that, the cloud app or the native app? And is there level of trust sufficient for the criticality? And should we allow it to continue or is it not, and should we break it? Or in a more nuanced zone, the trust may not be high enough but it could be possible for the user to engage in some sort of action to raise the level of trust, and then we could let them proceed.

Max

Yeah, there's a lot of questions kind of directed onto there. And I think you've done a great job at putting such a big subject matter into such a short amount of time because these are important questions that organizations need to be asking of themselves and to understand where they're kind of going forward from that. As we kind of come to the end here, I think it's good to kind of wrap up everything we've been discussing today and put it into some real-world examples. So have you got any case study examples of how Beyond Identity has helped companies to solve their password security problem with its own kind of cloud-native passwordless identity platform?

Jasson

Sure. So, we have a bunch of customers that ultimately are doing a similar thing. They've had a combination of kind of enterprise architecture disruption just through, you know, COVID in 2020, and they're looking for a way for them to establish security controls in a visible but more permissive manner. I.e, how do we let more BYOD? Now that people aren't always in the office, how do we adapt our security model? As well as folks just trying to build a more modern enterprise architecture.

So we have, you know, one of our customers that we, you know, you can go to our website and kind of hear from their own mouths but Snowflake compute, they became a customer last year. They rolled us out through the end of last year, and, you know, they're allowing their workforce to authenticate and secure their devices in a zero trust model to access, you know, all the things that they need for their work.

Our rollout was actually pretty quick. I would say they probably had the best operational efficiency of most of the customers that we've worked with. But, you know, the benefits they got is they got deep controls and visibility while being more permissive for some of those kind of low criticality operations. But for higher criticality operations, they got really strong security control visibility and enforcement.

In some of our other customers, they were using kind of a hybrid software integrations that they had built themselves between an IDP platform, an EDR platform, an MDM platform. And for reasons of compliance and audit and forensics, they were trying to stitch all of these records back together to try and understand what in fact was the state of Bob's device when Bob triggered this particular action in Salesforce.

And in our situation, we're able to give them a single clean record against every authentication attempt that states exactly what the posture is. And the information's kind of signed over in kind of an immutable fashion. So access protection's kind of use case number one. Clear immutable audit is use case number two, Simplification of architecture, we've had customers reduce some of their VPN spend for our product. Now, obviously, we don't provide a VPN service but they were using their VPN client to do device security posture checks. It's simpler and easier to do that as part of the authentication flow through an IDP system or an identity provider like us. So there's a handful of use cases but it almost always starts with enterprises that want to simplify the usability experience for their end-users while making sure they have common security controls, independent of whether someone is on a managed device or a BYOD device. And really kind of dial in that risk to what they're willing to accept versus mitigate.

Max

So I think those are some great examples that you've just provided there, Jasson. And I wanna kind of see if you could take that step further. If we're talking about we've secured the common worker but what kind of comes next in that process?

Jasson

So, great question. And this is a little bit of a tie-in to some of the use case questions as well. So we've been working with a couple of customers on this but probably the biggest design partner has been Snowflake again. And there's this interesting question that, you know, we've all kind of had but a handful of people are really starting to drive, and that is how do I know the software that I'm building into my product was contributed by my developers and no one else?

So everyone has heard of like supply chain attacks. I feel like we have a new one every four to six weeks. And it turns out the supply chain it's a multi-step process. So developers submit code, code gets compiled and built, the final deliverable gets signed and shipped off to customers. And so customers traditionally, and this is what most people think about when they think about software integrity is, "Hey, this binary that I'm about to load, in fact, it was signed by a certificate that I can trackback to, you know, Mr. Vendor X or Ms. Vendor Y."

Well, in our particular problem, we were concerned with a little bit further upstream or put another way kind of garbage and equals garbage out. So how do I know that it's only my developer's contributing code that my big build system is actually going to then produce and then auto-sign at the end of the process? How do I know it's my developer's and no one else? Well, most repo systems have an ability to actually sign the software that you commit to the repository.

And if the code was signed in such a way, then the build system could fairly easily have a role that says I'm only going to build a system if every component in the system is signed and the signer is an identity of good standing. So we're releasing a new feature or a new product called Secure DevOps in the next week or so. And the goal is exactly that. So for anyone who's using GitHub or GitLab, or really a Git-based product, using Beyond Identity's platform authenticator, we will construct GPG keys for them.

And their developers will be able to kind of seamlessly sign their commit objects, and then their build system can query our cloud anytime it wants to verify the integrity of any individual commit object in the repository. So the thing that we really focused on here is number one, developers are a little bit finicky. So if we mess up their workflow or their process, or if we slow it down, they won't use it. Again, back to my, my earlier description about, like, poor UX begs its own security problem.

And by really kind of focusing on having a clean UX model and taking charge of constructing that GPG key on their behalf, we make it easy for them to start code signing, which isn't really something they've done. And you may have an audience member out there say, "Hey, wait a minute. The first thing I do is create SSH key pairs whenever I sign up or GitHub. Isn't that actually doing this already?" And the answer is no, it's not.

So there are two types of keys that come into play when you're using Git. One is the tunnel key, the key that authenticates you to open up the SSH tunnel that you then push information across. The second is the key that signs the piece of data that establishes integrity protection over the data that you're then going to push over that pipe. Most people only do the first. Most people only do the SSH key

And anyone who's looked at a Git log has actually seen this before. You can authenticate as a proper person, like, I could authenticate as Jasson Casey but then I could push over commit objects signed by Daffy Duck. And clearly, we don't want those sorts of things. So it's really the GPG keys and signing the commit objects that establishes integrity at the very beginnings of this software development pipeline.

And, you know, at the end of the day, every company that builds software is someone's supply chain. So, this is kind of where you have to start at the beginning and just tying that back into, you know, the Beyond Identity mission and strategy. At the end of the day, we want to manage all user cryptographic material and we wanna do it in a cryptographically secure way. So that's again, using the Ts or TPMS or secure enclaves in a way where the user doesn't have to understand what's going on.

And when I say cryptographically related, we also wanna make it possible for anyone to ever say, "This key is not related to this identity." And it turns out there's tried and true cryptographic protocols to be able to do that, that we've brought to bear and we're excited to kind of see people start using Secure DevOps.

Max

Definitely. I think there's some important differentiators in there. And I think you've given our listeners kinda a lot to think about there, Jasson, that they're gonna be curious about. So thank you for coming onto the show and walking us through all of this. It's been great chatting to you.

Jasson

No worries.

Max

Thank you very much. And thank you to everyone who did take the time to listen to this. If you are curious about what we've been speaking about today and you want further information, that I do recommend that you head on over to beyondidentity.com, there's some great resources that can answer your questions, or you can speak to a member of the team who will be able to help you out even further. Thank you once again to Jasson for coming on and for Beyond Identity speaking with us. We'll be back soon with another episode but until then, thanks for listening. Goodbye.