Transcription

Of what we're gonna go today, I I wanted to take some time to kind of enumerate some of the things that we're saying. We wanted to, you know, make this risk based case for it. So we wanted to talk about some of the actual threats that we're seeing. And, what we're doing today to kinda protect against those threats and, you know, what isn't what isn't working. We're gonna dive into, this idea of MFA and that not all MFA is created equal.

I think that'll make sense when when we get there. We've got a library that we've created over time of various different access, exploits, and actually gonna take you through, one of them, you know, as an example, today, you know, just to put a real face on on some of the conceptual things that we'll be talking about. And then we'll move on and talk about what actually makes, you know, for those of you that have been following along, particularly in the MFA world, or following some of what Department of Homeland Security or more specific to the CISA folks have talked about as phish-resistant MFA.

So we'll we'll talk a little bit about what makes something phish resistant.

And we'll also continue to talk about, you know, the important role of of device trust and and how that plays in. And then we'll we'll follow-up with, you know, a little bit of an idea of what all of this together might look like something that we call Zero Trust Authentication, what it might look like in action, and we'll actually do a demo there, as well at the end in I'll jump into Q and A. So without further ado, let's get started.

This may look like some of your environments. You know, we we've got, you know, one of the issues, you know, that that, you know, we all know about is the ability for phishing attacks to be successful. And a lot of people, a lot of our customers have done a lot of things over time to try to improve that. You know, so kind of in the email sphere, you know, we talk about, you know, putting in, spam filters and, you know, doing some fairly sophisticated things, you know, even using a machine learning and AI to to better classify that doing DMARC rules and things like that to try to you know, avoid getting, you know, spammy stuff from from places where it shouldn't, reputation, you know, leveraging threat Intel, etcetera.

But the the real point of this slide in the next couple is the what we can do is we can reduce the problem, but we're not actually solving the problem. So you know, whether it's, you know, one user that clicks the link and and logs in into a, you know, potentially malicious site or if it's a larger number, the bad guys are, you know, are winning. You know, they they have to, you know, they have to get through all this stuff But these are kind of what I would call a set of probabilistic controls. They reduce the problem.

They certainly weed out a bunch of stuff but they don't solve it. That's not to say, by the way. I'm not trying to throw any of these under the bus. I think, you know, having, you know, a defense in-depth strategy in place makes sense.

This, you know, when we're talking about email, in particular, makes sense. And then there's some other things that people try beyond it. But, you know, if we only get five thousand emails and and really are able to reduce that, it looks one way. You know, if we get you know, a lot more emails, you know, if we're if it's a kind of a a ten x, you know, scenario, you know, then we've got, you know, ten people into or clicking on malicious links.

And what if it's five hundred thousand email, you know, the then we've, you know, the the problem just expands. So this is, you know, certainly a part of the kit that most organizations will will implement, but now when we expand that out and talk about the because since this is a multichannel problem, it's not just email. It's, you know, text SMS stuff, it's Discord channels, it's social channels, etcetera. So all of those, you know, play a part, and and a lot of us have talked about this, you know, idea of the the expanding landscape that we to protect against, and, you know, this, I think, illuminates that, in a big way.

So, you know, we can't have, you know, all these or even if we did, I and one of the things that I've always done, you know, since my analyst days was use kind of the the magic wand test. If we implemented these controls perfectly for email, if we were able to implement additional controls like this across some of our other, channels, we're still only reducing, the problem, not cutting out a classic problem.

And how confident would you be if if you filtered all that stuff out that that one of your employees wouldn't click, you know, taking a page out in the honesty book here. This is actually we're a KnowBe4 customer. So one of the things that we use is training and and, you know, user, training on, you know, spotting malicious phishing emails, you know, looking malicious links, etcetera, but potentially mis mis malicious links. But even in that, you know, we're not perfect.

In fact, we went from, you know, not so great. Seven point one down to six point four, but we're not, you know, we're still not at industry average. The good news is we've got a a set of controls that you'll see in place that still protect us in this regard. So even if those those phish type messages get through, we've got some other controls in place that, that'll backstop that, which we'll talk about.

But, you know, I'm sure many of you look like this, you use a set of filtering, you'll use a set of, you know, training, types of things, but, you know, you you're never going to drive this all way all the way to zero with a set of, probable controls. And we know that to be true. I mean, we know that, you know, from all kinds of reports that we see, whether it's CrowdStrike team that does an excellent report every year. I recommend you actually read their, threat report every year, you know, or the Verizon data breach report that's been going on, I think more than a decade now. Some of the same things come up year after year after year. They've been the same for a decade. So, you know, we know for a fact in 2023 that 86% of the web application is that they looked at. And these are actual breaches that happened in the, you know, data breach investigation report 86% of those involve stolen credentials typically as an initial access vector.

That's that's actual data. That number fluctuates around every year, but it's it stays high.

The second side is actually one that I lost a bet to my CEO on a little while back, and we were having an argument. And then, you know, he showed me this one, you know, right out of the, Verizon report. But, you know, basically, how to ransomware breaches, you know, start or or happen and my inclination, you know, as a cyber security guy was, oh, somebody clicks on the bad link, it, you know, directly installs, you know, of a ransomware kit that then then migrates, etcetera.

And and the reality is that certainly is one of the ways that it happens. But the top way, the top initial attack vector for ransomware, is the use of stolen credentials to log in to desktop sharing or other remote access kind of software, where the the bad guy can then deposit the the ransomware, or you know, maybe they'll even move laterally in the network and get to a particularly juicy target, and then go. But, you know, the initial attack vector there, is the same. So we know, you know, for example, that that passwords are are just not cutting it in in this case. And that's not obvious new news to anybody, but I just really wanted to take a a data and risk based view of this rather than, you know, a a preachy view.

So kinda where we are in the state of play is we've got these first set of controls that we talked about, you know, email filtering and proxies and and mail server, you know, better configuration of our mail servers, etcetera. And that's kind of one of the first lines of defenses. And then, you know, one of the other you know, lines of defenses, you know, particularly protecting against the issue with, with passwords being an easily, easily fishable, credential was MFA or or what we've put here is really traditional MFA. When we talk about that, we're talking about, you know, one time passwords, one time tokens, push notifications or even even things like, number match.

The problem is, those traditional MFA, and what I'm talking is the 99% of MFA that's implemented, at companies, you know, today, just doesn't take care of this idea of credential theft, and we'll dive into this in more detail. And it doesn't stop the attacker in the middle, kind of the phishing bay proxy based attacks and and or side channel attacks when we're talking talking about push notifications. So the end of the day is, you know, even with two control sets, we're still in a probabilistic, you know, category. And the answer is, you know, as we've seen, the bad guys are getting through.

And that's, you know, that's, you know, pretty well known. I know many of you follow the news pretty closely, you know, particularly your different channels that talk about cybersecurity. On the left side, we've just got some of the headlines, and these aren't just attacks. These are attacks that included MFA bypass.

So part of the the attack, you know, part of the TTP was to go around above over, whatever MFA, that was in place And it's interesting if I if I go back, geez, about a year, a year and a half, had lots of discussions with various CISOs, we're involved in a couple of different CISO networks. And, you know, I we were we were pushing this pretty hard kind of, you know, and I got a lot of pushback, you know, quite honestly. We we got a lot of push back about, hey, Patrick. That, you know, it really can't be that bad.

You know, you know, are we really seeing this in the in the wild? Microsoft says MFA blocks 99% of attacks. There's some Google numbers, that are that are similar. And the reality is, yeah, it it really happens in kinda what a difference a year makes, you know, the in this past year and 2022 and 2023, there's been quite, you know, quite a bit, whether it's, you know, CrowdStrike, you know, showing reports that you know, really shows this as a problem that's active and in the wild or Microsoft coming back around and talking about, you know, the the ten thousand organizations that we're being specifically targeted with attacker in the middle kind of techniques that we'll we'll go into in a bit here.

So, yeah, it's a real problem. This is in theory, you know, this is actual problem that's happening today and happening at scale. It's not we're not talking about the realm of the sophisticated nation state hackers.

This has really dropped from that level, of attacker down to, you know, your garden variety financially motivated, tacker.

Alright. So let's look at kind of a a couple of categories. When we say not all MFA is created equal, it's because they're using a technology or an architecture that is open to various different kinds of tech. So on the on the left side here, we've got a set of social engineering attacks, using different kind of pretext, you know, some ruse to get somebody to click on a link, whether that comes through email, chat, you know, or SMS, or using what's becoming known as prompt bombing, you know, sending lots of different requests, to an end user, having those those end users, you know, get push fatigue.

I've got, you know, when I started talking about this and some of the the CISO and some of our security engineer discussions, we have, you know, just about everybody raises their hand said, yep. You know, one of my guys, including, you know, too often, you know, some people with, you know, relatively deep or privileged access to things, you know, kind of, you know, fell prey to some of the prompt bombing and phish, you know, push fatigue attacks. So there's one class, and And the idea is any factor, you know, that is a password or a password by another name, whether we're talking about, you know, a one time password a magic link, you know, etcetera, etcetera, or, you know, another knowledge factor, for example, the color of the house that I grew up in any of those things, you know, are just weak factors, and and we'll talk a little bit about those.

The other thing is there's, you know, fishing kits, you know, that are are pretty easy So by, by the way, when I on the weak factors, any factor that an end user to, you know, put that context around that, any factor that I can get a end user to give me, like, over the phone or over an email or share with me, you know, is is by definition and a a weak factor. It, you know, it's a shared secret and, and not good. On the phishable side, this is where, we've seen a lot of, improvement, if you will, and the TTPs that the attackers are using. And the reason is is there's really easy to get fishing It's right here.

We've got one called Evilgenix two. That's one you can, you know, I've got the GitHub, you know, link in here. You can just go search on GitHub and download this. This isn't something that's, you know, necessarily sold on the deep underground where it takes a lot of skill to go get. And there's a bunch of other, attacking kits just just like So this is, one of the more popular ones in which you can launch, you know, basically a man in the middle attack.

Before we jump in and talk a bit about how that works, if if you guys are playing along at home and you've got your Bingo card out, we we actually have to say something about AI and since I think every cybersecurity, you know, presentation for the last six months has done that. But you know, kind of putting that into the context of what we're talking about is AI is just gonna make this this worse. We've we talked about a set of controls that were probabilistic And the fact that we were relying on, you know, often relying on users as as part of that, you know, while the level of difficulty for the bad guys to to pull off these attacks when they can, you know, use AI to help them code things, you know, is gonna go down.

The spearfishing lures themselves, and we're already seeing this are getting much improved, you know, certainly gone over the days of the the noble prince in Nigeria and and or other emails, phishing lure emails that we get that are, you know, full of grammatical errors or mistakes. You know, we can create very nice lures that are, you know, grammatically correct or even in the right tone of you know, Northern or Southern in the US or or in the Queen's English, you know, for example. And they, you know, so that that's gonna happen. And then now what that's really doing is the time of of exploitation from a new vulnerability is is going to go down, you know, with some of these. So those are some things that I think, you know, we see in terms of the way AI will impact as a interesting little exercise we did.

Our CTO, Jasson Casey, has a, you know, a pretty nice, LinkedIn profile. I grabbed that profile, and then we used this prompt on the on the left, dropped it directly into ChatGPT and asked it to effectively give us a a phishing email. Now ChatGPT and some of the other ones actually have some guardrails on it. So it, you know, try not to, you know, so they try not to do malicious things.

It doesn't take a whole lot of work to to work around those those guardrails, as you can see here in our prompt email on the left side. And what the result was was three different emails that we could use. And this was probably the, you know, the best of the of the three that we we took, you know, and this, you know, really talks about, you know, Jasson's involved in a lot of, you know, different cybersecurity and, you know, groups. And, you know, this shoe is just one of the one of the groups that, is fairly prominent, you know, and and hearkened back to some things.

So created a very well crafted and, you know, very believable email. So, you know, that that's kind of, you know, you know, an idea of the result of that. And like I said, that was only one of of three responses.

So let's let's talk a little bit about kind of the exploitation of these and and how this is actually how this actually works. And and I'll really, you know, jump into a demo here. So we've built up a library of exploits against, you know, different kinds of m f or different kinds of MFA, different kinds or even different tech, you know, so different companies, etcetera. I'm actually gonna, I'll pick on the Microsoft guys, but, you know, they're in good company. Like I said, you know, the the vast vast majority of MFA that's being used in production today is susceptible to a a lot of these technical techniques. So this is an isn't something that, is, you know, just, you know, just affecting the Microsoft guys, you know, for example.

Alright. So let me I'm gonna stop here. Let me give you, you know, kind of a a a little bit of an idea of how one of these man in the middle, you know, proxy based, attacks will work. And so this is kinda directly out of our, our, you know, our threat, you know, attack library So the first thing, you know, we're using Evilginx.

Oops. Let me back up there.

Where we're using the Evilginx kit as it says here. We're using, you know, we set up an environment that looks like a lot of customers that we work with. So it's an Azure AD environment using, you know, authenticator and and the passwordless version of that. And then we're using number match and biometric and still able to very easily, you'll get around that. So let's, you know, first start, with, you know, how does this thing work? So the actives in our play, the the victim, the attacker, and the proxy, this will go through the different steps, as part of this attack. We'll share the presentation out so you can take a little bit more time with this.

I'll pause it there for just a second. You know, so there's, you know, a set of steps that happen you know, the the phishing link goes out. The victim, you know, tries to log in, gets, you know, provides credentials. We capture the the proxy captures, you know, credentials passes those on to the to the service that that the the victim was trying to get to.

Get a challenge, an MFA challenge, in this case, a number match, push notification, and or a number match. In this case, it's a number match. And then you know, they provide the response, you know, both to legitimate server, and then it's at that point when since that's that traffic is being routed through the see that we can grab, the session cookies and and reuse those and and then do a session hijack. So let me show you how that looks we're gonna start off with a fish, show a legitimate email.

You know, our victim is doing work, gets the email, click on the link, looks legit, logs into the to the service, you know, to get to the the data. You know, we do the number match, as you'll see here. So we did the you know, combination of the password, this authenticator, and number match. And and then we're in.

So the good guys in, and but also what we left is this residue in the proxy server, which was the session cookie. And then we're gonna take that session cookie and inject it right back into the application, and now our bad guy is in. And it's kind of important to notice in that note in that is the bad guy could be anywhere. You know, with this kind of a attack, we're not stealing and reusing the credentials.

We could have done that too. In this case, it was we couldn't reuse that credential. But if it was a password base and, you know, say a one time password, you know, we could steal the various credentials and log back in. But this one just actually stole the session cookie and injected that back in and and and reestablished the session, which could be done from anywhere. You know, now we're working you know, the the login authentication flow is done.

We can log in from kind of any server. You know, so that's, you know, that's one of the ways in which these, you know, MFA bypass kinds of attacks happen.

Let me move on. Alright. So what do you do?

So the the let's talk a little bit about implementing, a phish resistant option. And and what, you know, there one of the key things in in doing this is really taking the human out of the loop. My god, have we put a lot on humans with, you know, when it, you know, talks about access and and authentication? Right?

We we made him choose passwords, you know, lots of different passwords, you know, a new password for each different server. We made them, quote, unquote, you know, choose a long and strong password. By the way, that's a myth, you know, the long and strong password, you know, it doesn't matter. It only matters if it's, you know, twelve, fourteen, eighteen characters, and and some special characters and, you know, if we're trying to crack the passwords, but that's not the way bad guys get them.

They steal them while they're in the clear. While they're being typed into, you know, to a login screen. If if I've got a man on the endpoint, or, you know, we'll use this proxy based to grab them right out of off of the network. So, you know, the I don't need to crack passwords to actually get passwords to log in.

So this this idea of long and strong passwords is is, you know, is a myth that unfortunately remains. But, yeah, we're putting the burden on those guys. First of all, you know, they they go to log in to the server, and and the browser can validate that the the server is you know, has a certificate, but that doesn't, you know, necessarily validate that it's actually the server that the user thinks they're trying to get to, you know, using you know, we can create, you know, pretty interesting URLs that look very legitimate using, you know, even cyrillic characters are just using, you know, different naming conventions that that look legit, and and we can stump the human as as we showed even in our scenario, you're gonna get, you know, with with our KnowBe4 and all the training that we do or that you guys do, you know, people are going to, you know, not necessarily recognize a, you know, a phishing link, a URL, and they'll click it.

So, you know, then the then the human executes the auth protocol. So this, you know, it puts a lot of it in the human, and the way we think about it is let's let the machine do the work. So one of the things you can do, you know, for phishing resistance is well, well, there's there's a couple of pieces. So the first piece is really anchoring the credential in hardware and and specifically in an enclave or TPM trusted platform module.

And what we're talking about is putting a key in a in a specially designed separate part, of the computer. And and they're available on all modern devices, whether it's my my iPhone, kind of ever since the iPhone 4 came out, and we were using the fingerprint, you know, reader on the iPhone4. Apple for example, in its infinite wisdom decided, hey, putting fingerprints in an Apple server, you know, where it paints a target on probably isn't a good idea. Maybe we need a secure place to store those things, you know, where they can't be moved.

TPMs were used lots of other things, include including validating different pieces of the operating system, you know, as they load it up, but they're also now being used to store credentials in biometrics, etcetera. So we can use that same thing to store private key. So that's a pay that's a piece of it. It's not if we do it that way, those those keys aren't accessible in memory. They're not acceptable, you know, accessible in disc, etcetera.

The second piece of phish resistance is really making sure that credentials don't move. If we take a credential and move it across the network, as we saw in this man in the middle kind of attack, that's when it becomes exposed.

And people think, well, wait a minute. We've got, you know, TLS to give us a a private connection between, you know, an endpoint and a, and a server or an application and a service that we're trying to get to. You know, why why isn't, you know, why why doesn't that, you know, solve it? And the answer is those credentials pass through all kinds of various services and and third party things.

You know, for example, you know, they'll likely pass through a CDN network, something like, you know, Cloudflare or AWS Cloudfront. They're gonna likely cross And by the way, in those cases, you know, we're opening the the, you know, we're we're opening up the TLS connection and reterminating it. Same thing if we go through the load balance from like AWS or an F5, or, you know, when, you know, we're not just talking about a server, you know, the service is really based on, like, a Kubernetes cluster, for example, know, same thing. We've got containers that are gonna open up and reterminate the TLS connection.

So, you know, there's lots of different places along the way that either the bad guy could hack into and get access. And we're not even talking about the proxy, you know, base attack, or, you know, a somebody at one of those service providers, you know, a a malicious employee, for example, an insider threat. So whether it's a an external malicious threat or an internal just a threat. Both of those are open, and there's just lots of places.

So, you know, we wanna make sure that we anchor those credentials in in, you know, in hardware and the TPM, and we wanna make sure that they don't move. What does move is we can sign a certificate and send that over. And then we can prove that that certificate was signed with a private key that matches a public key that we could keep. By the way, that is how TLS works.

How do you extend that? We, you know, be above TLS, what we need to do here, you know, is not only make sure that we've got a TLS connection but we have to have an application level signing, ceremony so that, you know, for example, the way we do it is we've got a platform educator, a piece of software that runs on whatever you're trying to log in from, and we've got our back end cloud. Our cloud initiates that request to the platform authenticator our platform and authenticator can validate that the domain it came from, you know, is the one that, you know, is has the the key or is associated with a key that's that's stored in the in the TPM.

So those are things that we can document. That and what that, you know, gets called, you know, the this idea of of those sets of validations is what the government calls in, like, the NIST documentation. I think it's the 863, is verifier impersonation.

And that means that, you know, you can impersonate a service. Therefore, you can't get man in the middle, you know, for example. So it's and that's a big piece, you know, there's two things with modern MFA that are problem. The keys, you know, the the credentials move, and they're not verifying the the the the folks request in the authentication as we saw in the Microsoft example that we went through.

So what we think about is eliminating whole classes of root cause, you know, of things. That way, you know, you you can't stop phishing emails from happening. You can't stop you know, our employees or customers from clicking on those, can we make the action of clicking on those moot? Like, we it doesn't do anything. So where we started was in the idea of credential theft and and going passwordless.

And then we, you know, focused also on, in fact, this was kind of by design from the beginning, you know, blocking these arbitrary phishing attacks adding, you know, persistent adding the, you know, phishing resistance to our MFA. So we only use, in our case, we only use factors that are strong, and we're not susceptible to the man in the middle type of attack. We've done the verifier impersonation work that we we need to. There's still a class, that we've that, you know, that we've got to pay attention to. So we've done, you know, credential theft. We've done the phishing, you know, kind of the man in the middle attack, but what if my host is compromised? What if the endpoint itself is compromised? So making sure that we take care of that you know, set of use cases is what we've we started working on, and and we've got some more work to do as does the industry.

So what might that look like? That that's what we, you know, those sets of things or what we have lumped in and and called Zero Trust Authentication. So it's a combination of issues as an MFA, device trust, and then continuous authentication and validation. So, you know, we protect with credential theft by having credentials that don't move.

We we protect with this session theft, with this verifier impersonation resistance, and we protect malware delivery. We can't by the way, those first two things can stop whole classes, you know, rather than making it probabilistic, they can stop a whole class of of of attacks in in their feet. Does it is it gonna stop every attack? No.

But very large and very often used by the bad guy set of attacks as we, you know, talked about earlier. And then there's malware delivery. If I get malware on the endpoint, you know, can, you know, might I have a problem there? And there's some things that we can do there even as part of the off transaction, but one of the things we can do is make sure that the appropriate controls on the device that you're trying to log in from are in place.

So that it's much harder for a bad guy to actually get to deliver malware to that that device. So it's a combination of those things.

I I just kept this slide in from a prior deck a little bit for fun because when we started playing around with with AI, and asking it to create us images of of what these things might look up. This is what it came up with. So for for passwordless and phishing resistant and and device trust pieces, it AI did a pretty good job. You know, these were, these are not our images. These are, actually AI generated things. So, you know, clearly, it's it's advancing quite quickly.

So let's talk about literally what might this set of things look like in action. So I'll I'll, you know, now I'll go into switch gears and go into kinda what we're doing, you know, specifically at Beyond Identity and and how we kinda work in this ecosystem. So what I'll do is I'll I'll I'll take you through this authentic flow, you know, graphically and and talk about what happens. And then I'll I'll demo, what actually goes on in practice.

Alright. So the first thing, you know, I'm, you know, I'm sitting at my my laptop, and I'm trying to get access to one of these applications on the right, most organizations have an IDP or a single sign on in place. Those platforms, you know, whether it talk to Microsoft or, you know, at all, have a capability. It's actually part of the OIDC standard for delegated authentication, you know, which basically means let me hand off the off piece of the of the flow, you know, to a separate service.

So, you know, that's what they do to us. And then we validate two things. You know, is this an authorized user you know, we do a public private key. You know, we we basically exchange a certificate signed with the private key that is on the device in the enclave and check that against the public key that's registered in our cloud.

So that gives us a very high trust whether this is, is an authorized user. And there's other factors we we we can add to that, and we'll we'll show you that in a minute. But then we also check the device security posture or the controls in place that you wanna see in places. My firewall on is my, you know, disc encrypted know, it are the pieces of software that we're using to protect us, whether it's things like CrowdStrike, you know, EDR, you know, types of technology, MDM technology, are they they implemented and running at the time of authentication, you know, for example.

Next, you know, that that's a, you know, a pretty good start, but a lot of organizations have made a hell of an investment in a lot of technologies. What if we could use signals from some of these technologies that are often used either for configuration, you know, or for detection and response. What if we could use those signals, those risk signals to make a better, more informed decision about whether we ought to let, you know, me or the device I'm using, you know, have access to the application I'm requesting to. So that's what we do.

We check those risk signals, and and we'll show you that. And great, if everything pans out, you know, we grant access, and they move along. Now that's really interesting, but one of the issues with with zero trust and one of the issues that we've had with authentication, you know, heretofore, is we often will grant a session token that's open for, you know, at least hours, sometimes weeks, and we've actually run to with a a a couple of our customers that will go unnamed, you know, session tokens that they keep open for a month, mostly because the authentication process was such pain in the ass, they didn't wanna put the end users back through it.

They kind of, you know, they they rallied and and and got them to extend those those session things so that they didn't have to do that again. And we all know, you know, we've we've been anybody listening in, I'm sure has been in cyber security long enough to know that, you know, that, you know, an hour or a day makes a lot of difference. Things can change on the endpoint.

You know, malicious, you know, you know, something malicious can happen it. I can turn off the control. Something can just stop working. One of my controls in places, you know, can get turned off, etcetera.

So the way we think about this is don't just do an authentication , then continually check recheck that, you know, recheck the authentication side of it, your user behavior signals to see if anything's changed there, recheck device security posture. And if anything bad happens, and and, you know, we've got an issue, then do something about it. You know, this is taking a page, kinda, from the New York subway, if you see something say something, right, in in our cases, if you see something, do something, thing. Let's quarantine the device, you know, for example, or drop the network connection so we isolate it so that the, you know, if somebody has a chance, if there's a bad on the endpoint or potentially a bad guy on the let's isolate that so that they can't do what they wanna do, which is move laterally in your network, and get to, you know, in a higher order target.

So that they can't do the damage. So what we're thinking about here is prevention. You know, We we we all know prevent detect and respond, and we spend a lot of our our budgets on detect and respond, you know, kind of appropriately when the the bad guys were in there in their dwell time in our environments, you know, ranged from weeks to months.

You know, we we obviously had a big problem and and we spent a lot of money taking care of that. But, you know, it's a whole lot better, to prevent classes of attacks, that you can prevent and stop them in your tracks. That way, your security operation center, and the SOC team can focus on, you know, other issues, other classes of attacks and and things. So, you know, that that has a lot of byproducts.

The last piece of this is obviously write this out to, you know, we we write a set of immutable logs, so the security operation center, you know, and, you know, whether it's integration with, spunk or, you know, kinds of tools or snowflake, you know, types of analytics, data analytics tools, you know, provide that information both the positive and negative, events so that they can be used, in, you know, reviewing, incidents in the future or even narrowing the attack, narrowing your search surface so that that security operations team can be better at what they do because they don't have to look at the sum, you know, they can take some of the things off the table.

And then, you know, also say that information added to your governance and compliance tool. So it's really easy to prove that you're complying with these things that you're being required to comply with.

Alright.

So that's what it looks like on paper. Let me actually bring this over.

And wow. We're looking at me. I am going to first we happen to be just to kind of give you a perspective. I'm I'm actually gonna go through an authentication flow, and then we'll jump into the back end of the system and and kinda see it happen.

We happen to be, an Okta customer. We're using Okta as our IDP. We're also a partner of Okta's, and, you know, very happy with with that product. We're using we use CrowdStrike, you know, kind of across our fleet.

We use Intune on our Microsoft fleet. We use Jamf on our our Mac fleet, which which I'm part of, you know, etcetera. Etcetera. So let me first, you know, just do a quick log out here.

So here's a state. I've, you know, opened my computer, you know, this morning, I, you know, fingerprint it in, you know, which gives me access to the different applications.

That, you know, the tiles on on my desktop also gives me app access to log in to Okta. In this case, that's what I'm gonna do. You'll see that there's only space for a username.

There is no password. That's not something that we do because we, you know, we've just eliminated that as part of the authentication. We we've just pulled the password you know, all the way out. We're using a cryptographic, you know, public private key exchange, to do that. So let me, let let me go ahead and go through this. I'm gonna click next.

We'll start the process. You'll notice I've got a Beyond Identity Authenticator here. It's asking me now to put my finger on my fingerprint reader on my MacBook pro, I do this, and then I'm in.

So a thing to note, and we didn't talk about this at all, is you not only wanna make this secure and and take the user out of the loop, which we've done, you also wanna make this patently simple and easy and frictionless for users. So not gonna dwell on that, but I would it's something that we really pride ourselves on. We made this authentication flow something that, you know, everybody. In fact, one of the downsides of working at Beyond Identity is no, you know, if you ever leave and and and go take job someplace else and they don't have this, you're kind of you you feel like you went back in the dark ages.

So now I'm into in into Beyond Identity. I'm gonna go ahead and log in to the admin console and just give you some idea of of of what happened and and what kinds of policy evaluations happen So you can actually see, you know, live. So we've got, you know, as any counsel, we've got some insights about, you know, kind of what's going on in our environment. I'm gonna go directly into the event log.

Actually, why I'm doing that, I'm also going to I've got my my iPhone, with me. I'm gonna go ahead and sign in, from my my iPhone as well into my Okta environment because I wanna show you a couple of other things there. So I'm I'm authenticating. It's now taken my you know, biometric, my face print, and and now I'm in.

You you guys, I didn't plug this one in, but, you know, you can you can take my word that I'm logged in and you'll see it actually show up in in the log file. So if I go into my events log and I, you know, search by user. There's only one Patrick at the company. So don't have to be that.

So we got a couple of logins here. This was this was the one that I just did. For my for my Mac, but let let's first take a look at or excuse me, the the one I just did for my iOS, my Apple, a device, my iPhone, and then let's take a look at my, my Mac a login. So I'm gonna click on this, and one of the things that you'll see is which policy, you know, fired and which one actually let me in and and you'll you'll see this is the rule that actually fired to let me in.

So what what did it check? You know, first of all, am I on am I on a Mac? Yep. Am I doing an authentication transaction?

Yep. Is my user firewall, you know, turned on, you know, basically disk encryption? Is my is my firewall, on is is this a work issued device and managed by Jamf? It is.

And is that Jamf connection available? That wasn't we can run it through different policies. So this, you know, the one interesting thing here that I will note in anybody that spent time gripping through logs or trying to sort through logs and figuring out when something goes bad or something goes good, we kinda, you know, our policy team is, you know, some of the best in the business. You know, we make this evident.

You don't have to go browsing through or grepping through logs and sorting through logs, you know, the you know, our our log file tells you exactly what happened, you know, specifically, and how all the other rules were evaluated. But let me come back to that.

You'll see get back into user.

And, you know, we'll we'll see that this was a login, you know, a different rule. This happened to be a login. You know, it was an iOS, and this is the one that that may allow me to get in. There was a bunch of other rules were evaluated, but this is the one that matched and and let me in.

So let me go a little bit deeper into our rule sets. We've got a bunch of rules in in our policy framework. We're actually consolidating some of now, you know, for for our own policies. And, obviously, for any of our customers, you can customize this just to what you want. But let me run run down and we'll talk about the Mac OS stuff. And I'm gonna look at, you know, rule 23, that let me in. You know, as we said, it was a MacOS, we're doing an authentication transaction.

You know, the the firewall was on. Firewall was on. Jamf was on. And the the action was allow. And as you'll see, allow with verification.

You'll recall it made me put my fingerprint back on my reader. Hey, great. I came in in the morning and logged in either with, you know, if my was turning on my machine. I'd have to type my PIN code.

If I was just, you know, reopening it after it the lock window came up, I can just put my finger on the reader, but what if I'd walked away, you know, from my desktop, you know, and and left it alone, you know, before it allows, you know, before we allow some to get into the Okta environment, for example, and get access to all those applications. You know, we wanna make sure that it's still the the the right person behind the keyboard So that was an interesting one. Let me and and nobody needs to be afraid here. I'm gonna do a little policy editing.

The good news is that my my security teams give me access to this. The better news is that I actually can't publish any change to the rules so I can muck I can mucks around in the sandbox and still not screw anything up. But let me look at a a a rule. So let's call it So the potential threat down.

So, you know, here here's what rule development looks like. So I I'm gonna look at specifically authentication rules that I could apply it if I'm adding a device and, you know, a a new device to the mix, but let's focus on the authentication. Yeah. Let's say any user, you know, I'll let's, you know, look at it for the Mac.

And let's take a look at instead of Intune, we'll go CrowdStrike.

You know, what if the zero trust score is greater than, you know, say, eighty points. By the way, we're monitoring this now ourselves so that, you know, we're figuring out actually where to set this. So CrowdStrike Falcon produces, you know, one of the things it produces is a zero trust base gives you some assessment of, you know, whether they think, you know, the the likelihood that that device, is, you know, compromised or potentially compromised or something you know, fishy is going on. So, I can do that.

I could add other add attributes, as well, if I wanted to, you know, I can add, you know, a series of those things. So I can chain some things together.

And then I could, you know, allow with OS verification, or let me get the, my right rule here is working in the wrong place. Add action.

Deny.

I can deny. I can monitor. I can allow. I can do all these things, or I can actually have CrowdStrike adding this.

We can look in different regions, all of those things. So I can deny, or I can also change this to, you know, not just deny but quarantine the device. And it's hidden under one of these things that I have to get my policy building skills a little bit better. But, you know, I can I can, you know, if it's greater than than eighty, then I can, you know, do, you know, I can take a take an action or check other things, you know, etcetera? So I've got deny, I can monitor, or I can allow it, you know, etcetera. So with that, you get some idea of the, you know, granularity and the integrations that, that we've included. Now let me go back, and I'll, you know, take a look at the I have my iPhone login as well.

That was the second one. Now, again, we're gonna pivot right into the thing that let me go. So this was rule forty three that actually let me in you'll see, you know, that's we'll scroll down to that rule 43, let me in. But you could see, you know, for example, if I was trying to log in to an iOS device, and it was either add, you know, or or trying to add an iOS device and it was jailbroken, you know, we could deny it and say, hey, no way.

We're not gonna let you add a new device already jailbroken. I could also make this instead of add device authentication, you know, for example, and then, you know, whether I'm either adding a new device or trying to authenticate. Let's say I add a device, everything was copacetic, not a jail broken device. Subsequently, I go and you know, because I wanted to get some interesting new game.

I jailbreak the device and then try to log in. You know, we still get a no. And there's other, obviously, other different actors, that we can change. And the last thing I wanna show here in the demo is, is just this idea of continuous.

Search by user. Alright.

You'll notice, you know, we've got the allow policies, but we've also and this was from earlier authentications, you'll notice, it's about, you know, every it looks like we're doing it about every twenty minutes, every ten or twenty minutes. We're going back and reevaluating the same policy. So I authenticated in. We did a bunch of checks, and I got an outcome.

If something changes, in the meantime, I turn off my firewall, for example, or I unencrypt my disk or I jailbreak my phone, etcetera. We're gonna look at this in, you know, in five minutes, ten minutes, etcetera, on a continuous basis and, and, you know, or I change location to some you know, new location that, you know, that wasn't authorized. You know, any of those things happen, I can, you know, now I've got some choices. I can core I can you know, quarantine the device.

I can knock, you know, knock me off the network, etcetera. So the idea of, you know, if you see something, say something, So with that, I I will stop. But that's that's what we think about, you know, when we're talking, you know, zero trust in action and going through the this, you know, this isn't theory. And I guess, a couple things to point out, you know, when you take a look at that at face value, seems like, well, wow.

You know, maybe that's a heavy lift. You know, maybe that's a lot to do. In reality, and this is, you know, this is shocking, and and you'll have to, I'll have to take my chief marketing officer hat, put it on the hat rack, and, you know, talk to you with my former, you know, been on the other side of the track's hat, we can actually get an Okta an Okta environment, for example, you know, up and running. Well, when we do a POC, very often, we'll schedule an hour to do that.

We'll end up having, you know, a team of four or five people on the phone, and we'll get that configured. So you know, we've gotta share some keying material between, you know, Okta and our cloud. So our cloud can talk to Okta cloud or or more accurately, so Okta can delegate that to us and we, you know, through the transaction.

So there's there's some of those things to do. You know, there's a download the authenticator. You know, you the end user can download it or you can push it you know, through MDM, you know, to your fleet like you do with the rest of your software. But, you know, we'll get, you know, four or five guys on the phone or gals on the phone and within a half an hour, they're already doing authentication transactions. And since it's not a not a nice switch, we can just, you know, take the four or five people that, you know, are do wanna do a POC, put them in a special group, you know, the Beyond Identity authentication group, let everybody else do what the organization do whatever they were doing, and and and let them try it out.

The integrations are, you know, pretty push button. It's click the integration you want, and then it becomes available in the policy engine. And as you saw, the policy configuration is, you know, a set of selections. What we didn't show there is the ability to create your own kind of policy checks.

There are some things. You can check for certain running processes. You can check with is something in, you know, installed? Like, is there a specific key in the registry, that you would wanna look for?

Is it, you know, or is a particular process actually be running at the time of authentication or at the time that you're adding the device, etcetera. So there was we didn't go for the depths of of the policy engine, but you know, it's really these integrations are out of the box things that that we've done and and made available to you. And so the lift is not heavy. Now having been again on the other side, that doesn't mean that it's it's a, you know, we just turn it on and fly.

Obviously, there's an education period. There's starting to build your policy, you know, your policies out, and make sure that we've got those in the right order. And we and some of our integrator, you know, partner can help you with that. But, you know, again, it's not a heavy lift.

And we can go from really fish take you from really phishable MFA with no ability to check the device with no ability to grab signals from from other products to that state where you can get full zero trust version of authentication in a very short period of time. So with that, I'm gonna stop and let me hide my screen, and I think we might have some Q and A here. Alright.

Okay. Yeah. We've got a, a bunch of them in here. That's that's great. So requirements to implement something like Beyond Identity, is is the first one. And, you know, in that case, we work with an IDP, you know, so, a single sign on product, like, you know, the ones that we mentioned there, you know, we a lot of our customers are are using Okta. A lot of our customers are using Microsoft Azure AD, or even on prem, you know, some flavor of both Azure AD and and traditional AD, for example.

And, you know, so that's a that's a piece of it. And and that's really the only other that that's really the only requirement. We integrate with that. If you've got other kinds of technologies that we can pull signals on or signals from, then then we can do those integrations, but you can do that at your leisure. It's not something that you have to do right up front.

Can we use Zero Trust Authentication to authenticate customer logins to our own product? Oh, that's a great one. Yeah. I spent well, I spent all the time really in the demo and talking about our secure workforce, customer.

So that was oriented. It allowing employees or or even, you know, partners and and and things like that that need access to the application suite that is that, you know, that that's part of your internal environment, but we can also take and help you implement, you know, FIDO passkeys for your, for your external environment, as an example. So, you know, you know, if you've got, you know, the the class example of a banking application or a consumer application that you've provided, you know, we can take those things passwordless and have secure phishing-resistant MFA. Interestingly, both are now requirements in the US federal government, you know, when the the we started out with this idea of a risk based case for, you know, for Zero Trust Authentication and particularly, you know, passwordless and phishing resistant.

The US government has mandated for all these systems that it has, you know, the that the government US government employees have access to that they are by the end of 2024 have phishing resistant MFA installed. It's not, like, maybe kinda, it shall. You know, they use the word shall have that. And for all the external applications, maybe, like, the IRS application that that we might log into to to get information, you know, about our taxes and stuff.

Those all in end of 2024 shall have a fishing resistant option. And that makes sense. They they're not pulling pushing them, you know, all the way to to turn on for everybody you know, the this new style of authentication, because that's, you know, a couple hundred million that may have access to some of these applications. So they're giving them a little bit more time.

But that shoe will drop too, and then they'll convert. Why do they do that? Because it is looking at exactly how the attacks are happening. They're looking at, you know, the the threat vectors that bad guys are coming into, and they know they can shut off a couple of those threat vectors by doing that.

I'll take one a couple of why are other why are other passwordless solutions like Okta Fastpass not considered Zero Trust Authentication?

We don't believe they're full zero trust because they haven't in in in some cases, it's not just Okta, you know, duo and others. They haven't all they they don't only use factors that are are strong, you know, like, you know, crypto based, you know, public private key, you know, they a lot of those will implement factors that are easily easily stolen. And and a big piece is they move keys around and they haven't, you know, established this idea in many cases of impersonation, you know, the the verifier impersonation, checks that that we end up doing and that the US government calls out, you know, in their documentation.

How would I how would you answer someone else? Oh, how would how is how are we different from, Microsoft Hello, for business. A couple of things, you know, first of all, in order to have, you know, you can use Windows Hello for business But if you wanna get things like the if you've they've also got conditional access. So if you pair those things together, it's close, but if you wanna be able to provide, for example, that across your entire fleet of employees plus contractors lot of organizations have contractors, you know, we can do that without requiring you, for example, to have Intune.

You know, for a lot of that stuff to work, in the Microsoft environment, you have to have Intune licenses for a lot of these other things. So that's one. The continuous authentication that we do, is another. We're always when we when we do that authentication transaction and pull pull data, we're always pulling fresh data.

So it's a combination, of a couple of those things.

See, I've got a couple more here. What I can do is since we're, you know, a couple minutes over, any of the the following, any of the the remaining questions that that we didn't answer we'll get back to the people that that answered them and and and drop you answers, as we, you know, do the follow-up email. We'll send a copy of the presentation for you and the copy of the recording if you'd like to share that with colleagues. You know, and by all means, if you've got, oh, one thing that I did forget I'll I'll do a quick share again is yes. Let me share the entire screen.

We've got a book that is a really worthwhile read. So we pulled all this together in something we call zero the zero trust auth that vacation framework that we build out and, you know, work and and had a book done. So, you know, you can just go to our website or or search on it, you know, QR code with your phone here and and grab that and and get a copy. Hey, if you'd like a hard, a hard copy, we'd be happy to send that to you.

So just ping me. My email is there. It's first name dot last name at beyond identity dot com or you can hit me on LinkedIn. You know, if you'd like a copy of that or if you got any other follow-up questions, or would like to request a demo and and do a deep dive, you know, with your more specific tech stack in place and your use cases we'd be happy to do that. So, you know, don't don't be shy with that as well.

With that, we'll end the webinar. I I thank you for all taking some time out of your very busy days to join us. And, we hope to, talk with you in the near future. Take care, and, have a great day.

‍