Watch Beyond Identity's CMO Patrick McBride go through a tour of our Secure Workforce product. 

Transcription

Hi, I'm Patrick McBride with Beyond Identity, and I'm delighted to take you on a tour today of our Secure Workforce product. Secure Workforce is a passwordless and phishing-resistant MFA, and it's one of the three products that run on our advanced authentication platform. We thought we'd talk a little bit about zero trust, but rather than telling you what it is, we thought we'd show you it in action because it'll be significantly more impactful. 

By way of background, when we designed Secure Workforce, we wanted to take care of a couple of really thorny issues with the existing authentication. First of all and obviously, passwords. Passwords are the single largest initial attack vector for the vast majority of attacks from ransomware to account takeover. 

They're completely compromised. So, you know, we eliminated passwords as a piece of it. Unfortunately, the antidote for the password credential theft issue tended to be MFA or traditional MFA, but the traditional MFA like one-time passwords over email or SMS or things like push notifications are merely a speed bump for attackers these days. 

In fact, I would point to you a 2022 report on the Microsoft blog that talked about an active campaign in the wild targeting 10,000 organizations with man-in-the-middle attacks allowing the adversary to bypass existing MFA. Also, MFA has a really horrible user experience. 

And that has some specific security ramifications. So it's, you know, either lightly adopted, we've got a lot of customers that only turn MFA on for a couple of critical applications and don't think about the other applications because many users are logging into five, 10, 15 applications and going through that crappy experience on each of those things, they would come after you with pitchforks if you turned it on. 

But secondarily, one of the ways they get around is they'll turn MFA on, but turn the session timers up to days, weeks, or even months, which just gives a window of opportunity for attackers that you don't want to have. Lastly, with regard to existing authentication solutions in MFA, they don't take into account the endpoint. 

The easy button for attackers is to attack the identity with credential theft and reuse, but the second, you know, favorite choice is to get a footprint on an endpoint because the appropriate security controls weren't in place. So, you want to know, you know, whether the endpoint that you're bringing into the environment allowing to access data and resources is appropriately secured. 

So, let's show you what that might look like in action. Many of you might recognize the front door to Okta. I'm going to log in just to give you the experience. You'll notice we only have the username here. We don't actually have any password field. I'm logging in as I do every day, we dog food our own problem or a product or sip our own champagne as some call it. 

So, here's our login experience. I'm going to click the next button. I'm going to be asked to put my fingerprint on my Mac Pro fingerprint reader and I'm in. Didn't have to pick up a second device or do anything. Now what's interesting here is that was a really simple authentication experience, but it really belies at exactly how much happened in the background. So, let us show you what exactly did happen. 

I'm going to, you know, go to our Admin console and let's take a run through some of the policies that got evaluated during that transaction. As you can see, you know, our policy stack, and this is our production environment, has 48 rules, goes all the way down to, you know, these rules. You'll see at the top part, there's a set of monitoring rules where we're basically saving data about what our fleet looks like, what versions of things that we're using, etc. 

Then we get down to a set of allow and deny rules as we go on. I'm going to take a look at a couple specific rules. Let's start with rule 23 and 24, these are the ones that kind of matched me. In fact, I'm pretty sure I fired on 24. We'll take a look. 

But, you know, I'm coming in from a Mac. We wanted to validate that my fire vault, my disk was encrypted, that my firewall was on, and that it's Jamf-managed. And also that the Jamf connection's available so that we didn't block and just in case it wasn't. We get all that information from our Authenticator. Authenticator runs on the platform that you're trying to log in from so we can natively gather, you know, all this information. 

And I'll show you that in more detail in just a second. Let me also take you to rule 12 and 13. So, in addition to getting natively information about the security posture device, we can also grab third-party information. So, you know, we can look at things like, is CrowdStrike running? What's the CrowdStrike Zero Trust authentication score? You'll notice that both of those things are in monitor mode at the moment. 

And monitor mode is something that we can use to turn on a new policy and just see how it would've impacted users before we actually set it to allow or deny, which we can do and I'll show you that in a second. Lastly, I want to show you one set of rules and then we'll take a little time to build a couple of rules that you can see. 

And you can see that we can work equally well, whether we're talking about a managed device, you know, like the Jamf-managed device that I'm using that also has CrowdStrike running, you know, or if I'm bringing a phone to the party. In this case, we're looking at, you know, is it an Android or an iOS platform? We can tell if it's rooted or jailbroken. Again, we can tell that natively, we don't need a third-party product. 

So you don't have to install an Intune or an MDM on a contractor or a device or a BYOD device to still get a level of security posture that gives you a higher level of trust that that device will be secure. So, let's take a look and go into the policy builder. I'm just going to edit a couple so that you can get some idea. 

They're not going to let me, you know, publish any rules, of course, but let me just take a look, first of all, at the device side of things. So, you know, whether it's any one of these devices, you can see the ones that we support. That means we've got an authenticator running on that device. We can look at all kinds of different, you know, attributes. These are some of them and we can do custom ones. 

You know, for example, is the firewall on? Is certain security software installed? You know, is other software installed? Are certain processes running or not running? In iOS, is fire vault on, your disk encryption, etc.? What version am I on? Am I at appropriate version level? 

And again, we can do all of those kinds of things natively across lots of different platforms. I'll also show you, you know, just in the integration side of things, this is where we can pull risk signals from other products, so Intune, Jamf, CrowdStrike, etc. And we're continuing to build this out. We can natively pull that information and then action it. So, you know, if we've got the Intune connection available, then we can do some tests, for example. 

And as I noted, we can allow or deny. Let's do one for, you know, CrowdStrike that would be different. Let's say, you know, the CrowdStrike's Zero Trust assessment score, which is from their Falcon agent, you know, rises above 80, then we could actually, you know, deny the transaction. 

ZT score too high, call the help desk, etc., if only I could spell, right? All right. So, let me get out of that because this policy engine not only is super robust in the ability to develop rules for authentication or registration, you know, I want to show you how that works in conjunction with our event log. 

So, you saw me log in, let me take a look at a couple of the transaction. So, let's look at the policy transaction. We noted when we were doing a quick tour of the policies that I probably fired on rule 1, which, in fact, did happen. This is the allow transaction that let me in. So, it fired on rule 24, and you can actually go and see...well, actually, before I hit that, let me make one other note. 

You'll note that it not only fired on rule 24, but it fired on rule 24 based on the policies that were published on this date. We version-control those, and I'll show you that in a second. So, we can take a look at exactly the policy that fired. Here's the rule that matched and actually allowed me in and here's the other rules that were evaluated and the outcome of those evaluations, all of that, of course, is in the log file. 

So, we get very fine green detail on exactly what's happening. That's super good in investigation, you know, scenarios. That's also good when you're talking compliance. We know exactly what happened and when. Going back to the policy engine for just a second, you'll see that our last tranche of policies were published 17 days ago, and so we, you know, publish new ones and we have them version-controlled, you know, all the way back. 

So, we can go all the way back to the beginning and know exactly what policies fired, for what individual, in what transaction. One other thing I want to show you in the event log because it's kind of quintessential part of zero trust and, you know, actively using zero trust principles is the idea that we not only check those policies during the authentication transaction, but we go back and check those policies continuously. 

So, all the things that were evaluated when we first did the authentication transaction, you all saw it, it's super quick and easy, continued to fire. Invisible to the end user, our cloud talked to our on-platform authenticator and asked it to provide fresh data, fresh risk signals, and make sure that things were still in place. You know, was my biometric still on? 

Was my firewall still on? Because we all know that that could change, a certain software up and running at the time. So, one of the key principles of zero trust is that you don't do it once and done, you do it on a continuous basis. So, let me, you know, take you back and give you kind of a graphic view of what happened in the scenario during our authentication transaction. 

You know, first of all, we did an access request, Okta delegated that to us. So, their cloud talked to our cloud, our cloud talked to authenticator, and we did asymmetric cryptographic transaction to make sure that the private key that's stored in the TPM that's associated with us matches the public key that's stored in the cloud. 

That's how we validate that it's me without having to send any kind of phishable factors. That gives us a twofer, we can also validate whether it's an authorized device. Am I coming in using a device...because we bind the identity to device, we can tell whether it's Patrick and whether it's a device that we've authorized Patrick to use, and then we go on and collect those device security posture signals. 

And as we talked about, we collect additional risk signals from Jamf and CrowdStrike. All of those get incorporated into the policy decision before we ever grant access. It's not good enough though. Then we have to continuously check those things and make sure that, you know, the user behavior didn't change, that the device security posture didn't change. If it did and we saw something, we can actually quarantine a device with CrowdStrike or drop it off the network with an integration with Zscaler. 

And, of course, we take all that rich data and make it available into your SIEM for your SOC team, whether it's, you know, allow or deny or just messaging rules. And we have integration with Snowflake where you can do deep data analytics on that kind of platform. That gives you an idea of how it looks like for our particular environment. And as you might suspect, we've integrated with lots of other single sign-on products and lots of other parts of your security stack to make sure that we can accommodate and, you know, we're clearly adding to that. 

So, that's zero trust authentication in action. You know, don't ever trust, always verify, always MFA, continuously, you know, unphishable, etc. So, I hope that gives you a good idea of what that actually looks like in action. We always think showing is better than telling. Have a wonderful day.