Transcript

Listen to the following security and product experts share their insights in the webinar:

• Holger Schulze, founder of Cybersecurity Insiders
• Jasson Casey, Chief Technology Officer at Beyond Identity 
• Patrick McBride, Chief Marketing Officer at Beyond Identity

Welcome to today's Cybersecurity Insider's webinar on "Why Strong Passwordless Authentication Is a Foundational Element of Your IAM and Security Portfolio." My name is Holger Schulze. I'm the founder of Cybersecurity Insiders, the online community for cybersecurity professionals. Thank you for joining us today and taking time out of your busy schedules. 

Now, today's webinar is brought to you by Beyond Identity. And Beyond Identity provides a fundamentally secure authentication platform that provides frictionless MFA while eliminating passwords. And now it's my pleasure to introduce today's presenters. First, I'd like to welcome Jasson Casey. 

And Jasson is chief technical officer at Beyond Identity. Welcome, Jasson. 

Jasson

Thank you. 

Holger

Next, I'd like to welcome Patrick McBride. And Patrick is chief marketing officer also at Beyond Identity. Welcome, Patrick. 

Patrick

Thanks, Holger. I guess there's a, how many chiefs does it take to give a webinar joke in there somewhere? 

Holger

And can we answer that question today? Exactly. So, thank you, Jasson and Patrick, for presenting today on passwordless authentication. And our audience is curious, right, to learn more about how passwordless fits in your organization's IAM and security portfolios, right? But before we go there, would you mind telling us a bit about Beyond Identity? 

Patrick

Yeah. Be happy. It's a good place to start. We're relatively newcomer to this space. So, you get a... Since we're not on cam today, I think everybody is, you know, prior to some of the Zoom cam calls... You can see Jasson and I upfront and in-person here on the slide. 

But, yeah, let me give you a little bit of a backstory in the company. This tech really got... We got started on the technology really back in the 2018 timeframe and, you know, really pulled it together as a company in 2019. And we're pretty excited to have two kind of Silicon Valley industry legends at the helm, Jim Clark, who some of you may remember from a company called Silicon Graphics originally. 

And then he famously hired five guys out of the University of Illinois Urbana-Champaign super-computing center and put them up in Silicon Valley and started a company called Netscape, which was the first commercial browser. But they actually did a lot. 

They did a lot on, not just on the client browser side, but on the server-side, and along the way, they invented a technology that we knew back then as SSL, Secure Socket Layer. It's now known as TLS, or as most of you would be familiar with, at least the block in your browser these days. And I tell that piece of the story because we actually use a piece of it. We'll tie that in a little bit later. 

So, yeah, Jim has a pretty storied record. And TJ worked with Jim originally at Silicon Graphics and helped out early on and in Netscape, and then went and helped found a company that was the first broadband over copper, was really the predecessor to high-speed cable oriented internet to the home that they sold off to AT&T quite a while ago. So, again, these guys, you could, without any exaggeration, say were at the forefront of the commercial internet. 

As a company, we launched... So, we got started on the software earlier, Jim and a small band of engineers who had some pretty interesting ideas, and got rolling. And then Jasson joined the team in 2019. I joined a little bit later in 2019. And we kind of publicly launched in, April 14th, which is, I know you all will remember smack dab in the early part of COVID, not always the perfect time to start, but hey, you know, that happens. 

We were about 30 employees at the time. We're up over 170, up 180 employees now. And we built a platform we'll talk a little bit about, we're going to talk mostly about the problem day. We'll give you a bit of a taste of it at the end. But it's kind of one platform, one consolidated platform, and we really support, you know, three different specific use cases. 

So, we've got a solution, a passwordless MFA solution for your workforce. We've got a passwordless MFA solution for end customers. So, everything from banks to e-com to fintech and everything in between, for example. And we've applied the technology, actually, with one of our customers, you know, kind of pushing us down this path. 

Had some great ideas about how to apply what we were doing in terms of doing strong authentications for the workforce and customers to provide really strong authentication into their DevSecOps environment, particularly into the repo, and also the ability to sign the code that goes into the repo with an identity that's bound to their corporate identity. 

So, you know exactly who's submitting every little piece of code that goes into your software repo that ends up coming out the other side as a product or whether that's internally or externally delivered depending on the kind of business you're in. So, it was a really interesting modification where we do... 

We'll touch on that maybe very lightly at the end. So, that gives you a little bit of the background on the company. For those who are playing along at home, we'll leave a couple, like, the Bingo game, the breach bingo game or what do security marketing guys say on a webinar call, we'll at least check off some of the boxes here, and we'll talk a little bit about zero trust too just to kind of put that in context and give you another block on your Bingo card. 

A good place to start with all this is the only reason we talked about these various different breaches here, and there's hundreds of others that we could mention easily, is that they all share one characteristic. I mean, sure, they share multiple ones. They're all companies and important organizations. 

But the big thing that they really share as the initial attack vector for the breaches that all these guys got caught up, you know, pretty famously, was a password. Probably the most famous is the solarwinds123 password that the SolarWinds team said, kind of blamed, you know, hung around the neck of an intern that was exactly certainly well received in the security community. 

You can't blame the intern for a mistake like that. But listen, it happens all the time. In that case, actually, it's interesting because they also bypass the multi-factor authentication capability. But you guys already know listening in. I know if you've listened into other insiders policy for lot of these attacks peeled back and talked about specifically. 

But the end, you know, idea here is that they all started with a password. And, in fact, for those of you that keep up with the annual Verizon data breach investigation report, which traces back to the root cause of many of the data breaches 70% plus kind of consistently year over year of those attacks are credential-based attacks, or at least that's how the initial...was the initial attack factor. 

So, you know, that's why we...one of the reasons we went down this path to create and start the company, we actually, originally, our stealth mode name was something called Zero Password. But we spent a lot of time really going beyond that because as we really looked into this market, there was some other things that you needed to do about. But let's back up for just a second and just, you know, kind of talk a little bit. I'll have Jasson jump in here about... 

There's this concept out there, about identity being the new perimeter. I think we actually stretched that to identity MDM point, which we'll talk about a little bit. But maybe Jasson, you can kind of take us a little back through the history of, what the protection capability and what that looks like now in the context of a more modern, in both infrastructure that people are using with cloud and a modern post-COVID working environment. 

Jasson

Sure. So, we used to build and really design our networks around the idea of, "Here is the safe zone, and here is the unsafe zone. And here, in fact, is the demilitarized zone where we're kind of sure about stuff, but not exactly." And we had these trust barriers, right? 

The way that you cross from the untrusted zone to the trust zone is by proving certain things about yourself. And when we're talking about firewalls, we're really just saying, you know, having the right IP address and TCP or UDP ports in your source and destination attributes. But key in that example is this idea that there are these boundaries where if all we could do is just build these boundaries and make sure that across the boundaries we could establish trust, then everything would be good. 

And the reality is that has always been problematic because it turns out there's many ways of walking through those boundaries that are valid, right? The firewall doesn't really help you much when someone clicks on an email link or opens up an attachment that has some sort of payload attached to it. 

And the end of the day, like, it really boiled down to this notion of, like, transitive trust where you just kind of assumed that if you see something on the inside, it must be trusted and if you don't, you don't. And it's really been kind of woefully inadequate in really almost everything that we've done in terms of building out security architectures. 

And that, of course, has led us down the path to realizing that we kind of need a different model. 

Patrick

Yes. As we went from that, you know, what we used to jokingly call either M&M security hard on the outside, a little softer in the center, and you had to pass through that candy barrier into something that looked more like the old castle and moat version into something that looked more like the village where some of the things you needed access or you could put behind the walls. But, you know, frankly, a bunch of things you needed access were outside the walls and some of your good people that needed access to things inside were outside and vice versa. 

So, this idea about that one single boundary, obviously, broke down and kind of... The picture to the right gives us the today reality is, and expectation from users and both customers or employees and contractors is we pretty much need anywhere access to anything. 

And that's kind of a...that becomes a tricky picture. So, effectively, that endpoint went from the, inside the firewall all the way out to the perimeter where it's effectively the user and their device. And we're hearing again... So, now you can check off another box in your Bingo game here if you're playing along. But zero trust is something that a lot of us have been trying to do and work towards for many years. 

I mean, it's not just the marketing term that everybody is, you know, latching on to. And maybe, Jasson, you mentioned transitive trust maybe you and your puppy there can give us some explanations of some of the other kind of attributes of trust, and then I can come back and we can relate it in the context of some of the things that we see as issues with the current tech in place. 

Jasson

Apparently, a deer is in the front yard. And, ordinarily, we think of our front as secure, but the dog realizes that just because they're in the front yard doesn't mean we should allow the deer on the property. So, she's getting a little worked up over there. But, yeah... 

Patrick

When she barks, does that create an alert that goes into the SIM or into the SOC? 

Jasson

It definitely creates something that eventually makes its way to me and depending on who is on the phone, one of us has to deal with it. But, yeah. Transitive trust, at the end of the day, it doesn't really... If you can't do anything, it's something to do. 

But, at the end of the day, it's not a great security model. And what you really want is you want to actually understand why you trust a thing, right? The key concept behind zero trust is just realizing that the only thing that you trust is the thing in which you build the trust yourself. So, for instance, if someone claims that they are John, I would ask for some sort of proof that they are John, not that they just have a name tag on them. 

And I would assume that just because that person was probably John five minutes ago that five minutes later they may not still actually be John. Or just because their device had reasonable controls and a good posture five minutes ago, may no longer be a trustable device. Maybe I should no longer let it receive certain critical data. 

So, the key idea really is, number one, really making sure that you understand why you trust a thing and making sure that you have tools and controls that build that trust up pretty much as you need it, right? 

You kind of assume bad things are all around you and you slowly just build what you need on a transactional basis. And the second thing is, then you redo that, you redo that in a continuous way. So, I don't have a safe network. There's no such thing as a safe network. There's only the network. I don't necessarily have a safe device. In a moment in time, a device might be safe, but there's no necessary thing called a safe device. 

And so if people can use any potential device, if the network is just a way to get access to applications, then how do I, in a continuous sort of manner, establish that the person who's trying to drive a transaction is, in fact, who I think they are, that the device they're trying to pull data to is protected enough to manage or view that data or control that data. 

And that if they're doing this over some extended period of time that the reason I decided to grant an authorization initially hasn't changed, and I shouldn't withdraw that authorization five to 10 minutes in. These are really kind of the key questions that pop up once you start to realize, like, the implication of zero trust in that, like, I assume the environment is hostile. I have to build everything up on my own in terms of identity, authenticity, and integrity, and privacy. 

And I have to do it continuously and basically improve over time. 

Patrick

Yeah. So, if we kind of take that thought and apply it to some of what we were just talking about, this idea of the identity, the individual, John, in this case, and the endpoint, the whatever they're using to gain access to the applications and dataset, or you have to think about those as the key new area of attack. 

And we've known that. I mean, obviously, passwords have been under attack for years. There's billions of them. Many of you probably gone, "Have I been pwned?" and looked up your email address and seeing the various different credentials that have been stolen and that are out there on or in the dark web or not even in the dark web, during the lit up part of the internet that everybody knows about. 

So, obviously, if you're going to figure out who it is using something like passwords that have been fatally flawed isn't going to give you the level of trust or any real level of trust at this point. And then, really, everybody's kind of go-to, industry go-to is MFA. And we actually agree with that, but unfortunately, as we've started to learn, there's this concept of phishable MFA. 

And if it's something, you know, that is... If it's a proverbial... If you're using a password to start with, think of that as your hollow wooden door, and you're going to put a second factor in as kind of a screen door. You really don't have much of a trust boundary there at all from the identity. We're going to click in and talk about that a little bit. 

And Jasson brings... I love doing this with Jasson. He always brings up this idea of transitive trust. And one of the interesting issues that we've had with some of the legacy authentication capabilities where you're one, authenticate users is they were so inconvenient that either they weren't turned on all over the place, you might have only for a couple of key applications maybe externally-facing applications or just very, very high-risk applications. 

But if you turned them on and ask people to pass through that trust or, as Jasson said, every time and you recheck them, you ended up having such a crappy MFA experience that your users would revolt. So, the counter to that was these ideas of session timers and things like that. And as we've gone through and looked at this, I mean, we have customers that had started out anywhere from a couple of, you know, usually many hours, but more often, kind of, a couple of days to a couple of weeks. 

That's a huge amount of transitive trust. I mean, you're opening the door, you let them, you check them, you know, through the door, but you're letting them back in kind of any time without rechecking anything. And so, you know, those are some of the kind of foundational issues with how we did authentication that really don't fit the zero trust model. Another main issue that we had was this idea of... 

We're going to talk about this in the context a little bit about authentication. But this really applied to a lot of things that we've done in security. You didn't see it in the picture because I doctored it, but I've got enough gray hair to remember all the controls we put in, in the beginning. And I also remember there was kind of two schools of CISOs, kind of the old school, "You'll do it my way, however, we say." 

And now we've got kind of new school folks who are really worried more about user productivity and user experience getting in the way. It's particularly acute when you think about it with customers because if they don't like your user experience, they can easily go someplace else. It was typically less of an issue internally, but it's something that it's, as we talked to lots of the CISOs every week, it's something that is really in the lexicon of security teams really worrying about how productive and how the user experience is. 

So, passwords actually violate the heck out of that as does kind of the legacy multi-factor authentication kinds of things where you have to go pick up your phone, pick up a second device log into MFA, or get a code, or log into your email, grab a magic link and do things. So, it was pretty inconvenient and from a user experience while we might have improved security somewhat, and we'll talk a little bit more about that it pigeoned, really torpedoed the UX, and therefore, that's what we were left at. 

We have to keep making this trade-off, so we're doing either longer timers or we're doing, not putting MFA in front of every doorway that you have to go through. But that's not why we do it in the real world, right? In the real world we, you know, if you get your key card to your new office, you get it downstairs. 

That doesn't necessarily, you know, get you onto the elevator to a certain floor. When you get off the elevator, it doesn't necessarily get you into the office space. And if it gets in the office space, it doesn't necessarily get you into, to all the individual offices. So, we've kind of replicated this checkpoint of boundaries that you keep having to have the right key to get through in the real world. 

And in the digital world, we've made a bunch of trade-offs because some of the foundational elements that we put in place, you know, just weren't fit for the purpose, really. Passwords were, you know, a crappy authentication method forever. And the things that we pasted on top of it, were the ways in which we tried to change that just made it worse for end users. 

So, I talked a little bit about this idea of "legacy MFA" kind of that when I say that I want to make sure you're not taking away from the discussion that we think MFA is inherently bad. We just think you have to do it the right way to make it good. And so, you know, legacy MFA that's based, you know, on passwords and has other things that can be phished out is just not inherently strong. 

And the government, and Microsoft, and others are realizing that. There's lots of warnings now about, in particular, saying that nobody should use MFA now, that it's phishable, for example, MFA that travels somehow over the telephony network which is pretty easy to get into as all of you know. 

I mean, whether, while they were breaking into the network just directly, or SIM swapping, and all the different tactics that folks can use. Or if I get a presence on an endpoint, and I can phish an email or a code out of SMS text or even out of an email, another potentially compromised channel, it just doesn't hold the strength that it needs to. 

So, issue one, it's... A lot of MFA is unfortunately not as secure as people think it is. And many of the most commonly used methods are the least secure. And it's interesting. The more secure methods of MFA, for example, sending a push notification to a device with an app on it, a second device with an app on it is more secure because you're sending that push over a secure channel. 

But what we're starting to see is you're putting the user back in, and we're hearing lots and lots of stories where the user gets an alert on their phone, they don't check it very carefully. The hackers know this, so they'll, you know, send it once, or twice, or three times and, eventually, a lot of users will just push the thing to clear the note and unwittingly let the attacker in. 

So, that kind of, you know, attacking the user, you know, is starting to happen. We've all known for years that that's kind of the weak link. So, the second one is just really low adoption rate. Users don't like it. If you made them do it, there's... Jasson pointed out, you know, in this idea of zero trust, we shouldn't have any transitive trust, you should check them every time, and then continuously keep checking. 

And if you did that, you know, with some of these legacy solutions, it would be such a pain that they just wouldn't go. And the last thing is something that I'll hark it back to what Jasson said earlier about, you know, how the tech is evolved. I mean, we've got cloud computing now whether it's SaaS applications, or platforms as a service, or even just pure infrastructure as a service or... 

You've got lots of different, you know, things that you need to get to that are obviously not on your network. And with traditional or this legacy MFA, it doesn't do anything about that other piece of the new perimeter. We talked about the user and identifying John, but we also need to know is this actually John's device that's coming in? 

And with MFA, I can go to any computer and log in. I can go to the famously insecure computers in the hotel lobby or the library or, like, a kiosk like that, that we... Anybody that's been around security for a long time doesn't ever log into those things to do anything important. They might browse some stuff on it, but they're certainly not logging into account because they just know those things are like, you know, compromised as all get out. 

So, it just doesn't do one of the jobs that you need to do when you need anywhere access to anything, particularly, a set of cloud applications, and you want to be able to control, in some cases, which device they're coming from and even assesses that device, as Jasson said, at the exact time that you're trying to log into is secure enough for the job. He also said that you want to continue, you know, to check that, you know, over time. 

So, those are... When we look at this and step back from it and look at this in context of the ideals and principles that you're trying to achieve a zero trust, legacy MFA just doesn't stand up to what you're going to need moving forward. And I put this up here. It's an interesting... I'll let you read for a second. 

And I've got a link to this. Man, I picked this up, like, two weeks ago. I've known Roger for some time. He's one of the front facing, you know, technically, you know, been around security for years and years. But there is no before... These are the folks that do the security testing of your end users. And he wrote a really interesting piece on phishable MFA. 

So, if you want to take a look at that and dig into it a little bit more, and just, it's actually a well-written piece. It was on LinkedIn. I've got a link to that at the end. So, I think Ian Allen, you know, from Gartner said it pretty well too. I think his quote was, you know, "You basically can't be using... You fundamentally can't use passwords, and you really don't want to use, you know, legacy MFA. 

The way that people are going is really passwordless and, you know, really high-fidelity, high-trust MFA. So, the Gartner team has been pretty activist on this as well. So, I'm going to give an analogy and then I'll let... 

Jasson, by the way, likes to give you fun because he calls this my painting by number slide sometimes or some of the other ones. But we're going to dive into some architectural things as well. But one of the models that works pretty well, albeit, is not anybody's ideal of a frictionless experience is the airport. 

So, if you are thinking about, like, what might an ideal solution look like for, that we'd need at these modern high trust know a way knowing it's Jasson and a high trust of a way of knowing that Jasson is bringing a device that's okay to the party? It would be the checkpoint at an airport. You've got to be able to confidently authenticate those users. And so now we're all having to switch over to a real ID which does a better job. 

It's actually two things. It's better, you know, tamperproof material the state licenses that they issue here in the U.S. now. But they've also done a better job of identity proofing the beginning, making sure that you're you when they issue that license to you, so we can have a better route of trust that we're more confident that the bearer of the license with the picture is actually that person, and they just didn't come in with fake or other credentials. 

So, that's a piece of it. And so the next piece is at the checkpoint is they don't just look at your ticket and your license or your passport, and then let your walk out to the airport. They're putting you through the magnetometer or the full-body scanner, and they're certainly not letting you get on with your bag without throwing that through the scanner. And many of us who have been at the airports in the slow line are taking off our shoes, and our belts, and all kinds of other things as well. 

So, they check all that stuff and before, so they're not just checking the person, they're checking what else they're bringing, you know, onto the plane, on their person or in their bag. And so that all works out pretty well. And by the way, this idea of no transitive trust, if any of you have glasses or were eating out in the airport lobby and forgot your wallet or credit card in and had to rush back out to get it, it's not like they wave you back through. 

It's not like they... Oh, the security guard saw you and they just say, "Oh, yeah. You came back through here a little while ago. Go on through." No. You're going through the whole rigamarole again. "We're going to check you over." So, what it doesn't do in that context is I don't think anybody would say, you know, that the airport experience is a frictionless experience. So, an ideal solution in the digital environment, you know, also has to meet that test as well. 

So, anything to throw in there, Jasson, or because we've got another slide, we'll talk a little bit more detail about that but... 

Jasson

The image that I would get everybody to hold in their mind, right, is the problem that you're ultimately trying to solve is caused by just the modern work architecture, the fact that people can be on any device, right? Maybe it's a device you control and manage and maybe it's not, right? People can be anywhere in the world. 

They may not actually be on your network. The only network you can really count on is the internet, right, for them to get to the application. So, how do you truly answer the question of, "Are they the identity they claim to be? Is their device secured enough, right, not secured but secured enough for the criticality of whatever it is they're trying to do in the moment?" 

That's really kind of the setup. And we feel pretty strongly that the answer to that...the easy answer to that is the only system that's guaranteed to always be in the middle of every transaction driven by a person, at least, is the identity system, right? The system that's responsible for authenticating users. So, if the system responsible for authenticating users had some sort of real estate on the endpoint as part of the authentication process, then it's easy to start to see that you could actually gather all the data necessary in real time to answer the questions of is the security posture of the device and the risk of the identity claim sufficient for the criticality of whatever operation they're trying to drive right then and there and in the moment? 

And we feel that the right answer to that is also a seamless experience to the end user. 

Patrick

Yeah. So, we've got up on the... I gave you the analogy of the airport, you know, confidently authenticating users. The way we think about that is a password will never get you there, period, end of story. And we've got some really secure ways to do it. 

In TLS, you know, none of us worry about, you know, are we talking to the correct server anymore? In fact, our browser will warn us if we're talking to a server that doesn't seem to be a valid server or doesn't have a valid certificate on it. But whether it's a user to a server or server to server, you know, we're pushing around trillions of dollars over the internet using public-private key cryptography. 

And it works really, really well. It's proven, it's scalable, etc. So, we'll talk a little bit about that. We're going to talk about this concept, and I'll have Jasson take you through it in more detail about the how, but cryptographically binding the user to the device. And if you do that, you get a lot of really interesting properties, and we'll point those out in a second. 

And as Jasson said here, they'll ensure the device is secure before granting access. And this idea of appropriately secure for the whatever resource. If you're just trying to get to the lunchroom app, hey, maybe getting on from that library computer is fine. But if you're trying to get to a financial system where you can move money, you know, it's definitely not fine, and you want to do much higher level of insurance that, that device is trustworthy before you let it on the network. 

So, those are some of the things. And so that's what we did. And there was a lot of buzz about when we first came out and people talked about, you know, going passwordless. And we certainly think that that's a part of it, but that's only the starting point, in fact, even how we got to the name, that and some really good red wine, but that's a different story. 

So, the way we looked at... I'm going to take a quick run-through here, and then I'll have Jasson kind of give you the scenario about kind of how it works a bit under the covers in the context of a workforce and the context of a consumer application. So, we've eliminated the password out of the flow. So, it's not that we hid the password like some apps do. 

A lot of folks, like, use face ID and some of that, you know, don't use passwords at all, but some of you use face ID, and then they'll log you on to one of your systems, and it's just exchanging the password in the background. If the password is there, it's still vulnerable and somebody can get in. So, we've got an authenticator, and we call it an advanced authenticator that runs on the device, as Jasson said, it's got real estate on the device. 

And so that's... And our authenticator uses some hardware built into modern devices, you know, to basically do that binding. And, again, I'll let Jasson kind of take you through exactly how that happens, what we do. So, one of our factors is going to be the native built-in biometrics in modern devices, you know, where the backup is always a PIN code. 

People, by the way, confuse PIN codes with a password because it seems like the same thing. The difference with the kind of modern PIN codes on modern devices is that, one, the PIN code, it never traverses the network. It's not a shared secret. It stays on the device in a secure piece of hardware on modern devices. And the other thing is, it's got anti-hammering, you know, kind of if you try logging into your iPhone seven or eight times in a row, you'll get slowed down or locked out. 

So, these kinds of ideas where if you're using a four-digit PIN code, you can't just try 900 or 9999 times and one of them you're going to get in. You're going to get locked out well before that. So, pretty strong authentication into the device to the point where, you know, the federal government has asked Apple to let them in multiple times to which Apple has replied politely, "We wouldn't if we could, but we can't. It's not the way we designed the system." 

And the way we've engineered that since, you know, we use for our... We have multiple factors all the time since we've got our authenticator doing what it needs to do, and the combination of a biometric, you get two factors every time that are super, super frictionless, you know, the kind of authentication we like, but also super, super-high trust. 

So, that's where we get the frictionless authentication piece of it. And then, as Jasson said, the last thing our authenticator does, at every transaction and moving forward even more often, if you'd like to configure it that way, we checked a bunch of different settings on the device, and we pass that over to our cloud and we enforce policies. 

We will use the lunchroom application before. If it's kind of a low-risk application, maybe you're only checking a couple things, or you're just checking that as a registered device, you don't really worry about anything else. If it's that high risk, you know, financial application, you might check a lot of other things. Is the firewall turned on? Is the PIN code turned on or biometric turned on the time of login? 

Is it... Do we have encrypted... Is the device encrypted or if it's a mobile device, is it jailbroken, etc., etc. So, let me let Jasson dig into each of these things, and he'll talk to you a little bit about how we do this binding of the identity and how that login transaction looks in different scenarios. 

Jasson

So, the core of this architecture really depends on just knowing a few simple things. So, we have an identity service in our cloud, and we have this authenticator that runs on the endpoint. It's not like a push service notification where you have a secondary device. Our authenticator, it runs on the actual device that you're trying to, you know, move money from, log on to the bank account, or log in to the operation's view of your SIM. 

It runs locally on the platform that you're actually using. And in the core of the authenticator is this thing called the trust library. And the trust library at the end of the day, it does this really simple thing. Depending on what the user is trying to do, it packages up a request saying, "Hey, I'm Bob. You know, I'm Bob because look at me, I'm Bob. And I'd like to move $10 million into this bank in Grand Cayman right now." 

And what our cloud service will do is it'll look at that request and it'll run through our policy engine. It'll say, "All right. Bob is presenting with a fairly low degree of trust. Bob's wanting to do a fairly highly critical thing. So, we're not necessarily going to say no, but we're not necessarily going to say yes because the administrator has written a series of policy rules that say, "Hey, we want to... Bob is an important guy. We want to let Bob do things from time to time." 

But in order for Bob to move money of that magnitude, he has to actually prove a couple things. He has to prove that he's Bob with a high degree of trust. He has to prove that the machine he's on is likely malware-free and has all of the security controls that I would expect. And so the way it would do that is it would come back with a series of challenges. 

Excuse me. And those challenges would say things like, "Hey, Bob, I want you to prove that you can use a private key to sign a challenge in this moment that I know I've linked to you in the past, and that I know is protected by a PIN and possibly a biometric both at the same time because this is such a high criticality application. I want you to prove that you have that PIN or that key." 

And the easiest way you get people to prove they have keys is by getting them to sign things with keys. And I require that key to be managed in something called a TPM hierarchy. And that's kind of a very trusted computing way of knowing that they're doing something with a key that physically can't be moved off the device. 

Now, that's not enough, though. We may also say that, "I want you to prove things about your laptop, right? Prove that your laptop is not compromised, in fact, that it could easily become compromised." And in our particular posture, the way that we ask those questions is we say things like, "I want you to prove to me that not only is CrowdStrike running, but it's running in a very specific configuration that we expect it to be running. Not only is Jamf running, but it's running the policies that we expect it to be running, that your firewall is enabled with some specific screening rules present, that your disks are encrypted, and that you have on your purple socks." 

And only if all of those things are true, do we then allow Bob to move the $10 million to the Cayman. He probably wouldn't be allowed to move the $10 million to the Cayman. But, like, at the core, it really is a simple system. We have this trust library that's anchored in a technology called TEEs or trusted execution environments. 

This is a hardware capability that's shipped with most equipment since about 2016 that lets you construct cryptographic material in hardware enclaves where you cannot export that information. We have a policy system that lets administrators essentially define the risk of their organization as it is, not as opinionated vendors suggests that your risk actually looks like because no one's risk is a collection of four knobs. 

It's always much more complicated than that. So, we present this fine-grained policy language. And when someone wants to access a service or access data, it's a series of questions that always devolve down to, "Is the trust level of the identity claimed and the risk of the device sufficiently being mitigated for the criticality of what the user is trying to do?" 

Patrick

Perfect. So, yeah. I mean, as we talked about, you know, we've got a solution that runs or the authenticator that runs on... I think it's easy to say that, one, I think we don't support now, which is the Google, the Chromebook, I think, is the only one that we've gotten asked for, actually, by one of our investors that we'd really like to finish that one up. 

But, I mean, we've got it... Our authenticator literally runs across the widest range of devices possible, so, you know, Windows, Mac, Linux, etc., etc., and phones and tablet forms and things like that. So, you get this common experience of logging in. You get the super-high trust way of validating Bob. You get a super-high trust way of validating that it's Bob's device and the device is secure. 

And you get a very common experience for end users that's really easy. And we're coming down to it like that. We have just a minute. I'm actually going to do a departure. Totally unplanned, but sometimes it's kind of nice to see these things. I'm actually going to get to our Okta page. 

Jasson

Uh-oh. The marketing guy's going to do a demo. 

Patrick

Yeah. I'm not going to give them a hard one. We're not going to take them all the way through the policies. I'm just going to sign out of Okta. So, we're actually not the shop ourselves. So, we use their single-sign-on platform. As you saw, you all saw the tablet here that the set of tiles that I had access to. 

So, I'm just going to log in to the front door of Okta. And all of those things that we said that happened are going to happen. So, it's going to check me. It's going to check that I'm me by, you know, showing that I'm sitting behind the device. And it's going to check, you know, the... It's going to exchange the certificate signed by the private key that's sitting on... 

I'm running a MacBook Air in the TPM of my MacBook Air. It's going to collect the security posture data and send that up and all the, so the signs, the signature on the X.509 certificate, and the payload of data that we're checking, go to the cloud, and it's going to see if I pass policy or not. 

I'm not wearing my purple socks, so I'm keeping my fingers crossed. But let's see. So, all of those things kind of... You notice there wasn't a password on there too, by the way. Okay. So, it's asking me... My clamshell, my laptop is closed. 

I'm behind my big screen. So, I'm going to have to type in my PIN. Hopefully, I did that right. And boom, we're in. So, all of the... When we say frictionless, we kind of mean, really, frictionless. If my clamshell were open, alls I'd have to do is put my finger on my little fingerprint reader, but, you know, the system is smart enough to know. 

And that's with Apple that it's closed, and it's going to have to go to the backup since I can't possibly squeeze my finger in the clamshell part of it. But, you know, that's it. I mean, it's as simple as that from a friction standpoint. And that's why we think it's super-important to hit all of those things. And, in fact, at our company, everything you log in to, you get checked every time and it's, nobody complains. 

It's super easy. We all have a dozen or so, you know, a couple dozen applications that we're logging in to all the time. But we keep our timers down to almost nothing, you know, because, you know, it doesn't matter. It's so easy to get in, nobody worries. So, if you kind of look at it in a timeline, we're at that point where we're going past the early password lists stuff where we certainly are past... 

We are at the time that finally, Bill Gates predicted back in 2002, I think it was, and ours was either '02 or '04 where he predicted, kind of famously, that passwords would be gone. And it took us longer than we needed to, but we went beyond that where it's not just getting rid of the passwords, it's really providing a frictionless, I would say, "zero trust authentication." 

So, you're not trusting anything. You check everything every time, but you make it easy enough that you can do that without inconveniencing everybody. And I wanted to have Jasson to talk about... What do you think, I mean, between us and some of the other vendors kind of playing in this space? When we get past where we are now or where we were when we launched, 2020, where you can just put this stuff in. 

Maybe if you could do two things. If you could talk... We did promise and we talked about the flow from both a workforce and a consumer thing. So, I did want to hit that. And maybe talk a little bit, you know, we've got another minute or so, you know, about where this is likely going in the future. 

Jasson

Yeah. So, as Patrick mentioned earlier, we have three products, and they're all, again, based on the same core architecture, right? We have this Cloud Identity service and real estate on the endpoint with what we call the authenticator. And at the core of that authenticator, again, we're constructing and using keys to sign challenges. Sometimes those challenges are simply about the person. 

Sometimes those challenges are simply about the computer. Sometimes those challenges are about the person and the computer to help security administrators make sure that they're handling risk in kind of a fine-grained way so that they can provide the best user experience. What you saw Patrick demonstrate was our Secure Work product. Essentially, it's what you can use for your employees and your contractors. 

We also have a version of the product called Secure Customers. And the easiest way of understanding Secure Customer is everything that you've heard about and that you've seen, imagine it being delivered as a series of APIs and SDKs to where you could bundle this in as an experience into your own application. 

So, let's say you're shipping an application to your customers and you want your end users, through the act of just opening the application on their mobile device, to get that frictionless experience, but, again, with that high degree of trust and who they are and an understanding of the machine they're accessing it from. 

That's all, again, the same architecture and it's possible to embed that in your product. And that's just with our APIs and our SDKs. And there, we support a handful of development ecosystems on the cloud side. It's, series of REST interfaces, so it almost doesn't matter. And on the endpoint side, we support a series of Native SDKs as well as a JavaScript runtime. 

So, you can build this in Java... You could build this into a Javascript app that you've built. You could build this into a Kotlin app that you've built if you're building on Android or on Swift, if you're doing it on iOS or even C# and C++ if you happen to do Windows development. Just to be complete. The third product is Secure DevOps. And that's much more about providing tools specifically aimed at your technical workforce. 

So, your technical workforce, the most common thing that they're doing is they're probably writing software or maybe they're a DevOps team, and so, again, they're providing software that describes your infrastructure, right? A lot of people are doing this, maybe not everyone realizes this, but your network is no longer out and about, and in the cloud, your network is actually now in your code repository in your Git repository. 

So, Secure DevOps is a product really about helping you protect your own development process, i.e., the supply chain for your customers. So, what we do there is we, kind of, well, again, create authorizations and keys, but in that case, these things called GPG keys, to allow your developers to seamlessly sign the software that they are committing to the repository. 

And, again, this is one of those things that not everyone quite understands while everyone uses, is almost everyone uses Git to manage their software where they're developers are pushing. And by definition, everyone has SSH keys that they have on their local machines that they use to push directly from their local machine to these repositories. 

But what they don't quite realize is those SSH keys serve a similar purposes of a license plate on a car. They identify the car that's crossing the bridge. They don't identify the occupants of the car. And so Git has another mechanism that's often not used because it's a cumbersome process to actually sign the software and link it to a very specific author and actually protect the integrity of that software as it comes across. 

And so back to the car analogy, you can think of it as providing driver's licenses or identification cards for the passengers of that car. So, even though I know the car can cross the bridge, now I have a way to actually talk about the contents of the car or the code. And, again, most people don't use this functionality today because it's a bit of a hassle. Trusting developers and a large group of people to actually manage keys themselves and not mishandle them is not an easy process. 

So, with the same seamless experience that you saw Patrick demonstrate on how to log in to Okta a minute ago, we'll automatically construct those keys on developers' behalfs, link them to their corporate identity, establish a local configuration in their local repositories in the proper way to where the next time they decide to commit code, it's automatically signed with a key that links specifically to their corporate identity as opposed to their GitHub or GitLab identity or whatnot. 

Which, again, if this is all kind of new to you, we can kind of cover that in a follow-up at another point. But just to be complete, that's kind of the third offer. 

Patrick

And in the essence of time too. So, if we flip the clock forward, you know, we kind of think about it this way, a lot of folks are trying to get different signals that they want to bring into their authentication, which makes a lot of sense. But in some ways, they were using a lot of signals to try to strengthen the trust of the original transaction rather than starting with a fundamentally secure way to do it. 

We know it's fundamentally secured. This whole SSL and, you know, X.509 certificates is secure because that's the way we move trillions of dollars around the internet every day, like, literally every day. So, it's a trusted, secure way to do that. It still makes sense to bring in additional signals into it, but, you know, the way we think about it is those should be added on top of a strong fundamental trust model that we've talked about. 

And so we very much think we'll be bringing additional kinds of signals from other products and other places into that authentication decision, so it's not just our authenticator providing signals, but we're taking it from lots of other places. We also think if you have the high, high fidelity records that we're talking about, the trust in the person, the exact time that they're logging into everything, what their machine looked like that time, there's a lot of really interesting AI and ML, you know, machine learning that you can do on that data, you know, to provide some very strong anomaly detection signals. 

So, if you look forward, that's what we think this is going to be... I think other vendors will also, you know, realize some of this. I think we feel we're in a good place because just the amount and fidelity of the data that we're getting on these transactions is pretty good, I mean, or very good. It's not only the amount of data we're collect. We sign every chunk of data, so we know it's valid and active or valid in a way that it's tamperproof because we're using a lot of the same cryptographic functions to make sure that, that data is protected, we're not locking it up, but you can prove it, you know, is the same on one end that it was on the other. 

So, this idea of having that and doing ML to advance those signals is pretty interesting. I promised earlier that I would give you that link for these at, is MFA phishable? I think you could just probably...if you search LinkedIn and, you know, why a majority, or Roger Grime's phishable, or something like that, the short version, you'll get to it. But I think we've got a PDF file that we'll send out to you as well, so you'll have the link there. 

And certainly, you can pop us any questions, you know, over to my email that you see on the screen. But with that, I think, Holger, I'll turn it back to you, and we'll answer some questions now. 

Holger

All right. Let's see. The first question. "What do current regulations say about how companies should implement MFA?" 

Patrick

I'll give a piece of this and, Jasson, certainly jump in. One of the core pieces of documentation is from NIST, and they're encapsulating that in the 800-63. It really describes, you know, high-trust authentication methods. 

So, they absolutely recommend, you know, or require MFA, but they're doing a lot to reassess MFA and decide, you know, which things are trustworthy and which are not. And so things as we described before based on passwords that use, you know, any second factor that happens to diverse the public telephony network. 

I think the way they described it now in the documentation is that it's "restricted" meaning that, you know, if a government agency or somebody that sells software to the government wants to use that, method then they have to...then somebody in the organization has to stand up and actually accept that risk or put in other controls that would help offset the weakness of that. So, I mean, what they're really telling you... 

And they do that, the way this sets it up, they do that, because, sometimes you can't change, like, right away for multiple reasons. So, they'll let you do it, accept the risk, or add some controls, but what they're really telling you is you shouldn't do it that way. So, that's yes... Anything to add on that, Jasson? 

Jasson

No. I think that the key principles there is at the end of the day, remember your users can thwart your own security if you make and present solutions to them that are not usable. So, usability experience really is important in MFA design as well as just the pure security requirements. The second thing is also just remember email and SMS, they're not valid, secure channels, right? 

It's not that you can't use them, but just know they should be treated as low-trust channels. 

Patrick

What else do we got, Holger? 

Holger

All right. Excellent. So, the next question here. "How has the increased need for distributed work changed requirements?" 

Patrick

It's an interesting... Fundamentally, I would say, I mean, you know, the whole distributed work model... Cloud computing was the first shoe to drop and then COVID... We were already getting more distributed pre-COVID, obviously, and then COVID just was the massive forcing function. 

So, we did push all that as we talked earlier out to the perimeter. But it also changed, you know, the way... So, the way that auditors and others are looking at this problem now. If any of you have tried to renew your insurance, you know, by the way, your security-related cyber risk policies, you are probably getting a much different questionnaire this year so... 

And that was based on so many of these new... There was so much increased attack activity as we went remote with COVID, you know, that got ratcheted up in a big way. And they're looking for additional controls, you know, particularly MFA as an example. So, a lot of those things can and really... 

It manifests itself and it is undoubtably true that, you know, the person and the endpoint, you know, are the new perimeter. It's not that trust zone that Jasson described earlier where we put our firewall and bad guys stay out, good guys in, kind of scenario. 

Holger

Thank you, Patrick. The next question. "Can you elaborate more on what you mean by device risk? Do you mean that you can ensure security on an endpoint without an MDM?" 

Patrick

You want to hit that one, Jasson? 

Jasson

Sure. So, yeah. So, what does device risk means? A password or a legacy authentication solution is inherently highly portable, right? If someone knows their password, if they have their authentication token, they can really log in from any machine anywhere to your services today, right? And generally, you'd have very low visibility into the state of the machine that they're actually logging in from, that they're gathering information from. 

You could argue, "Hey, there's some information in the user-agent header of the web request that's coming through and there's some fingerprinting technologies and..." There is some information in there that's kind of useful. All of it can be forged, but there's a little bit of utility there. When you introduce a platform authenticator an authenticator that, again, is real estate on the machine where the person is trying to actually do the thing from, you have an ability to answer all of these questions about what is the status of the machine that's going to receive this data, right? 

Let's say this data requires encryption at REST and certain amount of protection around physical theft. Wouldn't you like to know, are the disks on the machine encrypted? Is there a local authentication that's set up on that machine? Is there a screen lock that's set up on that machine? Maybe you don't want to allow the transaction to proceed if any of those things are not true. So, device trust and security posture of a machine really falls into that category of questions. 

And being able to answer that in a fine-grained way with real-time data in relation to every access request is really at the heart of what modern access architectures have to support and kind of what we do. 

Holger

Awesome. Very good. Looks like we have time for one more question. So, the question. "Are these recommendations for internal security? But what about developers or external contractors?" 

Patrick

I think the way most... Oh, go ahead, Jasson. 

Jasson

Oh, I was going to say the... So, with external contractors, the fact that they're an external contractor actually means a couple of things right out of the gate, right? At least in the U.S., you know, the IRS gets upset if you call someone a contractor, and then start sending them equipment, right? So, contractors fundamentally are going to start off in a different way. That does not mean that you as a security team and a security architect or a security leader, even a CISO, don't have custodial responsibility over the intellectual property of the data that these contract developers are working with. 

So, how do you, in a lightweight, in an easy way, understand the risk of the machines and the visibility of the machines that these folks are using to do good work for you, not be too invasive, but make sure that you're still exercising the oversight that you have to exercise around that data and those system access? So, the solution that we've talked about, it works in the same way. 

It doesn't distinguish in whether it's an employee or a contractor. You can. You can write policies that do different things depending on what you find on the device or properties of the identity and how they're set up in your directory. But, again, that's a choice that you get to make and you get to make in a fine-grained way. And you don't have to force them to install an MDM. 

But if they are running or if you are running MDM on your employees, you can certainly integrate the system with that MDM to get even more information. 

Patrick

Holger, thanks. I would tell everybody, you've got my email address there, if you've got either any follow-up questions on this general topic or other related stuff, certainly shoot me. It doesn't have to be about our products. I'm more than happy to field any of those. And would sure, certainly, you know, welcome if anybody wants to do a deep dive with us, just ping me, and we'll get you set up with one of our systems engineers, and you can talk in a lot more detail about how we might be able to help you out. 

Holger

Excellent. Thank you. And thank you, Jasson and Patrick, again, for, you know, sharing your insights on passwordless authentication. Thank you very much. All right. With that, we're at the finish line for today's session. Now, as we're closing this webinar, I would like to thank everybody in our audience for joining us. 

I hope you enjoyed today's presentation. Now, this concludes today's session. I hope we will see all of you again at one of our future webinars. Thanks, everyone. Have a great day.