Palo Alto Networks’s Doug Good, SVP of Global Systems Engineering, highlights the company’s suite of zero trust security technologies and how its technology cooperation with Beyond Identity can enable zero trust access to applications and data.

Transcription

Doug

Hello, everyone, and thanks for joining us here today. My name is Doug Good. I'm the SVP of sales engineering for Palo Alto Networks, and I want to spend next few minutes talking to you about Palo Alto Networks, the security landscape, and our partnership with Beyond Identity. 

The security landscape has changed drastically as applications have moved to the cloud, users have gone mobile and really, in some cases, hybrid, and our threat landscape continues to evolve. And what this really means is that our traffic patterns completely changed the user's location, the application location, and how the traffic flows between those has changed drastically. 

And, at the same time, our threat landscape has changed in the sense that our attack surfaces exploded with people working from home, on the road, in the office, coffee shops. So, we have to manage security in a very different way than we have in the past. In the past, we've historically looked at doing this with either best of breed products or with the platform. 

And it's our belief that due to the current environment, where we have more than 3000 security vendors funded, and according to cyberseek.org, we have more than 750,000 open cybersecurity professional roles in the U.S. alone. So, you have this expanding footprint of solutions, you have a gap in talent and in order to try to bring that together, we believe that a platform approach is the right avenue. 

Now, doing that, but also doing that with best of breed products, and don't take our word for that. Here are 12 different categories where the Palo Alto Networks are recognized by third parties as leaders in their particular part of the portfolio. But it's important to us that we bring that solution to you as a portfolio. 

We're going to focus today on network security. But before we do that, I do want to highlight that we also provide cloud security solutions, protecting not just your applications in the cloud, whether that's private apps that you've deployed in the cloud or SASE-based applications, but also protecting the data that you have in the cloud. 

In terms of security operations, taking a entirely new approach to the SOC, bringing in ML and AI to automate many of the tasks that have historically been manually administered, and reducing that workload on the SOC, moving to a more high fidelity output and backing all that with Unit 42, one of the best threat intelligence and advisory services units in the industry. 

But let's focus a little bit on that network security piece. It's our belief that you should be able to get the best security services and the best security efficacy delivered consistently, regardless of whether those apps are in your data center, in the cloud, if they're SASE-based, if you own them, if you're knowing general web browsing and do that regardless of where the user resides as well. 

Doing that through a consistent administrative interface, a consistent policy, and delivering it in whatever mechanism you prefer. As part of doing that, there are a couple key pieces to the Zero Trust approach, but it really starts with the ability to integrate with partners. And the integration between Palo Alto Networks and Beyond Identity, starts with the fact that before we grant any access, the user needs to be authenticated and authorized. 

But we want to do that in a way that gives the best possible user experience. So, things like passwordless phishing-resistant MFA to give the user the best experiences while we provide the highest level of security. 

But it's also very important in Zero Trust that we don't do this as a one-time event. There's too many solutions that once they test for authentication and authorization, it's a set it and forget it. It's critical that we have continuous trust verification, that we have continuous authorization, that we have continuous security inspection, and we do that again regardless of where the user resides, regardless of where the application resides. 

Now, what we'd like to do is take a minute and give you a quick demo of this integration with Beyond Identity and how that works together to provide that user experience and that security efficacy for the end user. If you don't mind, let's roll the demo. 

Chris

Today, we're going to focus on a simple yet all too common scenario. A company already using Palo Alto Networks remote access solutions needs to grant an external auditor access to their network for ongoing certification work. However, they know that many external contractors have access to tens or even hundreds of systems. Credentials like passwords and security questions often end up saved to all the wrong places like SharePoint or Excel spreadsheets saved onto Wikis. 

Beyond the simple benefit that the Beyond Identity password solution has no more passwords, there's nothing to save to a spreadsheet or a Wiki. Enterprises also gain control over what machines can get a credential, using fine-grain risk-based policy sets. In this quick demo, I'm going to show you what that looks like. First, we'll show an example of the simplest possible enrollment process for an external user, and show how that user logs into the system using a Palo Alto Networks remote access solution. 

Then, I'm going to show you a quick view of the administrative interface to demonstrate what the configuration looks like, for an administrator granting that limited access to external contractors, we'll make a quick comparison of just some of the administrative options for internal users as well. So, let's move over and take a look. First, let's start with the enrollment process for the user. What I have here is the inbox of our user, Pam Beesly. 

Many of you may know her from the path. She's actually been promoted recently and she's going to be contracting for the...she's external contractor for the Weyland-Yutani Corp. And she's gotten an enrollment email to log onto the extranet. So, we jump in right here. She's gotten that email, some simple steps. 

First one is to download the Beyond Identity authenticator, and clicks on that, and she'll get the option to download it for her operating system. For those of you who have seen a setup dot exe and next, next, next run before I'll save it. I've already got that installed, but it's fairly straightforward. Once that setup.exe runs, she can go and register her passkey. This is a one click to open it. 

She will grant access to Google Chrome to open the Beyond Identity platform authenticator. That's the program she just installed. Doesn't require administrative access. It's user level only, which is great for contractors and external users who don't necessarily always have admin on their machines. So, Pam now has a credential registered in the external extranet of this particular corporation. 

I'm going to switch back from the Beyond Identity platform authenticator now to the browser. Close this browser tab as I'm being instructed to because I always follow instructions, and I'll now connect to Palo Alto Network's Prisma. At this point, we're already passwordless. 

So, Pam has installed the authenticator and gotten a passkey, and she's now going to open and connect to Prisma Access using Beyond Identity's passwordless login. So her browser... So the Palo Alto Networks system is configured to pull authentication from Beyond Identity in the backend. So our browser has connected to the Beyond Identity platform authenticator here locally, and it's getting a biometric. 

I'm going to put my finger, or Pam's finger, down on the reader to identify myself, verify myself and get into the Palo Alto system. As you can see, that was about as simple of an access protocol as you could possibly have. And what's our step four, install the Global Protect client and connect, and her customer has sent Pam a copy of this here. 

A gateway name, the agent is up here in the Palo Alto Networks Prisma system. Again, I've already pre-downloaded and installed these things. You know, again, if you've done a setup.exe in this case to a setup dot MSI and run through it once before in your life, you've done them all. 

So, I'll pop open GlobalProtect here and I will paste in the portal address that was included in the email. Hit Connect. And what we're going to see here is a passwordless Beyond Identity connection to a remote access solution provided by Palo Alto Networks, in order to give Pam access to her customer. 

Here, I will again put my fingerprint on the reader now to verify the biometrics that I'm not only coming from an authorized device, but I'm an authorized user. And in a couple of moments, here we go. We are connected. We're connected to the Germany Central gateway, which seems appropriate given that I am sitting here in central Germany, and Pam is able to do her work for the Weyland-Yutani Corp within literally just a couple minutes, even cutting off the installations of those two pieces of software. 

We're literally talking about 3 or 4 minutes. So, what did we see? What happened the backend? Obviously, for a user, that was super easy, but what's happening behind the scenes? What I'm showing you here is the policy engine of the Beyond Identity system. I could probably spend hours showing you all of our policy options and all the different, various parts of the system. 

But I wanted to focus on just a couple of things. The policy here, it's a lot like a firewall rule set. It's going to control how access is granted, when it's granted, who it's granted to, both for registrations and for logons. The rule that we just went through here was this contractor registration. I just got a little name on this contractor registrations for Windows, Max 1 Device, Enforce Hygiene. 

We could also do the...we can look at these rules for Mac, Linux, etc., I just want to look at the Windows rule here and tell you what's happening in the background. So, in the background, this company that was allowing Pam to join their network, in order to perform her work duties is allowing... If it's a contractor, who doesn't have any registered device, this thing, a maximum of one device per contractor. 

You know, as I was saying earlier, in these contractor use cases, you often see people passing around passwords, logging on from different systems, logging on Teammates. Here, we've got a very simple rule. We're creating a durable link between this contractor's account and their machine. They're allowed to have one device registered. Could that be changed, you know, if necessary? Of course. 

That's always in the control of the administrator. But, in most cases, most external contractors, you want to allow one machine. And so, when they're adding device, if they're a contractor and they don't have any machines installed yet, and this is a rule for Windows, we're also doing some basic hygiene. We're going to say, if at least antivirus is enabled, and firewall is enabled, and the disk is encrypted, those are our most basic hygiene elements, then we're going to allow them to enroll that computer onto their user account. 

Would it be nice in some cases to ask for a specific security software? Sure. But that would be more of an internal employee use case. For an internal employee, we can look at specific EDR systems, antivirus systems, settings, you know, all that stuff. But for, again, thinking of a contractor use case, we're just looking for generally, do you have some antivirus installed and configured? Is your firewall at least enabled and not disabled? 

And most importantly, or, you know, second importance after antivirus, are your disks encrypted? So, if you do lose your device, you're not, you know, granting access to the world, to whatever sensitive data you might have been working on for our company. So, that's just a simple, you know, example of what that rule looks like, allowing the contractors in. 

I have also simple rules here. For example, an employee, you know, for an employee, if they've got, you know, MDM, they're enrolled in the internal MDM system, they're enrolled in the internal EDR systems, we can let them do a lot more. We might not limit devices there, right? So, quite a number of different options of how to handle these things. 

I'll say just one example, what it could look like to handle a contractor. And handle contractor access to an extranet. There's one more thing I want to show you before we exit out of the interface. And that's just quickly everybody's favorite thing, the logs. Actually it's nobody's favorite thing, but I still want to show them to you. 

And the reason I want to show them to you is, just to show you how we build this up graphically and show you exactly how decisions were made. So, what we see here is this policy allow and when I go into the evaluation, what we're going to see is what did match and what didn't match, right? So, she's not an end user, she's not in any of the internal, she's not in the VMware Workspace One, she's not in CrowdStrike internally, but she is coming with it to authenticate. 

This is the authentication event of her accessing the VPN that we showed at the very end of the previous part of the demo, right? She's coming to authentication, she's a contractor, she's on Windows, she had antivirus, she had her firewall on, and she had her system disks encrypted. Given that all that stuff was compliant the way we want to see it, we decided to allow her to join with OS verification. 

OS verification in this case, was the biometric fingerprint. That's managed by the operating system. We take whatever the endpoint has, if it's Windows Hello with video, if it's a fingerprint, you know, whatever biometrics are available. We can also support pins, local pins, of course, only, you know, chip and pin security model, not passwords. That's what that OS verification is. 

We take whatever's available on the endpoint. Now, we know that Pam, Pam Beesly, would never be careless with her passwords, but what about those who are? We know from bitter personal experience that it's common for people that have access to many different companies systems and also work in teams to share that access with team members that aren't necessarily authorized to have their own direct access but are still working for the same client. 

One very simple solution, I discussed a couple of times, is to only allow each user to register a total of one device. Unlike passwords that are fundamentally happy to be used on as many devices as possible, Beyond Identity passkeys give control back to the issuer, back to the entity controlling that extranet, controlling the remote access solutions. Here, I'm going to show you just a quick example of what it would look like if a contractor that's only allowed to have a single device tries to grant access to one of their coworkers. 

Now, I'm going to show this with Pam Beesly again. Now as I say, we know she would never do this herself, but I'm still going to use her to show this. I'm going to go back to Pam here. I'm going to open up the platform authenticator and you see we got this handy Set up other devices button. If I'm an employee, I should be using that. That's how I can, for example, grant access to my mobile phone. 

Whether I'm allowed to, if for example, it's a work phone with an MDM on it, or if it's a personal phone or maybe I'm requiring biometrics, that's all back in the policy engine. But as an employee, I know that I can set up other devices by going here, and to prove that I'm Pam, which I obviously am. I'm going to scan my finger on the reader here. And here we have a couple of options. 

We've got the option to scan a code, scan that QR code with a camera or you can use this one-time password. It was only allowed as generated after I biometrically authenticated as Pam to set up another user. And now I'm going to go to the photo of Pam's colleague me, and show you what it looks like when Pam tries to, or this coworker tries to install Pam's password. 

And so, I'm going to go here. I'm going to go here to add passkey, and I am going say I have a passkey on another device. And, actually, you know what, I'll just use the camera, because that'll save me the time of typing and oh, boom, what do we see down here? 

Policy denied. Dismiss. That is the policy in action that I was showing you earlier. That's what happened. Where, we sent the Beyond Identity console, that each contractor could only have a maximum of one device enrolled, that's why we denied that phone. I'm going to come back here to the console and just show you briefly what that looks like. 

I'm going to go back to the Events view, and refresh it. And here we see that policy denial, I'm going to jump into the evaluation here and here we get a nice little description of what happened. We can see the first rules didn't match. She was not an internal user, didn't have CrowdStrike, didn't have VMware, was not authentication, was a contractor but not authenticating. 

It wasn't on Windows either. And here we see, it was an add device attempt, but they didn't have zero devices. They were a contractor, but it wasn't Windows. Now, we could, of course, in our rule set allow people to use iOS devices, or Android devices, or Linux devices, but this is what the rule says. The rule says that Windows, that was not true. 

It was encrypted. It means that's good. But no antivirus, no firewall. And so that's why that attempt was denied. And at the end, they just got that access denied message. Those messages could be customized. We see some companies that say, put in their exact help desk address or how to open a ticket, various different ways to help their users, their legitimate users, get help without giving an adversary too much information. 

But, yeah, overall, you know, that, I just wanted to show you that sort of integration, what that looks like of granting easy user access to your internal users while denying access to either going out of compliance or, of course, threat actors. And this tight integration makes it easier and safer for existing users of Palo Alto Networks remote access solutions to grant and control access by contractors and external third parties. 

So, but not just handing out a password, but generating controllable passkeys. Organizations of all sizes can quickly reign in and get control of unfettered password usage and ensure better compliance with security policy and best practices while eliminating the risk of credentials getting stolen due to risky sharing practices. 

Doug

All right. Thank you for the demo, and, hopefully, that gives everybody a sense of what we're talking about when we talk about, how we can use some of this integration to, again, provide not just better security, and security that's resistant to things like phishing, despite being a better user experience. And it's very rare that we get that combination. 

But here's a case where we have phishing resistant, we have continuous validation, we have passwordless MFA, we have continuous authorization, and we do it all in a way that provides better security efficacy and better user experience. So, again, appreciate all your time and attention. 

Hope you enjoy the event, and thank you for spending time with us today.