Edge to Cloud Security: Harnessing NAC, SASE and ZTNA

My name's Adam Fuss. I'm the VP of product for the Edge Connect SD WAN solution. Um, I go, I sit in the SSE and security product vu.

So there's quite a bit of integration that we are working on, uh, to bring our products together. Um, just quickly an overview of our SASS e solutions. Um, there's really three pieces to our portfolio.

At the top. We have SSE, which is our cloud-based security solution, really heavily focused on ZTNA. Uh, next piece down is Edge Connect SD wan.

This is to connect, uh, branches, data centers, the cloud. And then the third piece of all this is ClearPass and nac. Uh, we actually have done quite a bit of integration throughout this whole portfolio, and that's what I'll be talking about today.

Uh, we've integrated ClearPass into Edge Connect, where we can get device context, identity, all that sort of information. We've also integrated our SD-WAN and SSE solutions, and we're actually about to take that much further. So let me start off with the problem statement first.

Um, we have noticed with many customers that we are working on ZTNA type of solutions with that. They have very much brownfield environments, and there are just applications that live everywhere. So branches, data centers, the cloud.

And to connect to these applications in the ZTNA world, you actually have to use what's called a connector. And so this allows our cloud to broker app, uh, users back into applications inside of the network. And this is all well and good when all the applications are in the data centers, where I have infrastructure where I can run that connector.

Traditionally, it will run as a, a virtual machine. Um, but when the applications start living out in the branches, um, that's a whole different problem. I may not have virtual infrastructure there to run this connector, and that means that I end up having to connect to our cloud, connect to a data center, and then route across the wide area network to get to the application.

So not necessarily the most efficient path. So what we have done and what we're about to, uh, you know, release here soon is we have added the SSE connector into the Edge Connect, um, SD-WAN solutions. We're actually running this as a container.

It's fully hooked into the data path of the Edge Connect, and it runs as a service alongside our SD-WAN services, our firewall, uh, our swig automation, everything else that we have, uh, on this platform. And what this ultimately will look like for the end user. And then I'll show you actually how you deploy this, um, is that that user now can just go connect to our cloud.

That's where they get all the security brokering and all the inspection capabilities. And then our cloud is connected directly into the branch, wherever that connector is enabled. So no longer are they having to hairpin through a data center or some gateway inside of the network.

They actually can very simply, um, you know, connect right into the branch or the site where the workload lives. We've had a lot of customers coming to us saying, Hey, we have third party contractors and these other people coming into our networks to manage HVAC services. This problem is actually much more prevalent than we ever thought.

And so people need to get into the site, uh, down to the site, but they need to do it efficiently. So let me jump to our demo here, Put this out the way. So what we're looking at here is the Edge Connect orchestrator.

And in the orchestrator here we see we have our appliances on the this side, and we have a tab here for H-P-E-S-S-E. So this is where we've been adding integrations to build, uh, towards our unified SSE portfolio. Now, the one that's selected right now is our secure web gateway integration.

So we had, we do have the ability here to actually go into a subscription, provide an API key to our SSE offering, and that actually connects our cloud, uh, orchestrator up to our SSE Cloud. So they've, they're now talking. And when I do that, what happens is I have the ability to form tunnels automatically to our cloud for secure web gateway integration.

So if I wanna use a cloud-based swig, um, I can very easily at scale deploy this across hundreds or thousands of sites, really with just dragging a box over. We automate the entire process of creating the tunnels. What we've added in is the SSE connector now.

And so what we have done here is, and it's gonna go and sync. We now, we can see we have some different sites that are selected up here. And we can see we've actually deployed this connector, uh, across a bunch of different locations.

Now, I didn't have to install a virtual machine or do anything like that. I simply actually, you know, make sure I'm on the right version of the Edge Connect operating system. And I go over to Connector Association here and I can see, uh, what sites the connector is associated to.

And if I wanted to, let's say, associate that connect into Portland, uh, to this site here, I would just say associate connector, or I could just do it to all of them. And when I hit save here, and I'm just gonna skip this, in the interest of time it goes out, it calls the, uh, API for our SSE offering. It gets all the information it needs to configure that connector.

It downloads the connector actually from our cloud into the container, the appliance, and then it actually goes through and fully completes the process of standing up the connector. Now, if I go look at the, uh, the axis side here, we can see under settings and connectors, we have the connectors that are instantiated from the Edge Connect orchestrator and from the fabric. And so what was a process before of actually, you know, deploying a virtual machine, making sure I had infrastructure at the site.

If they're an SD-WAN customer, they very easily can connect the connector, you know, throughout the entire network, really within minutes. So try to keep the demo straightforward today. I wanna see if you have any questions.

The connector in this particular case, 'cause Access security is an SSE. Yes. Usually was endpoint clients, right?

Yes. But this is obviously an aggregation device like Gate Gateway that's connecting to that. Is there a behavior configuration change or policy differences within the SSE sort of framework?

No, there's not. So the connector itself, uh, it would be the same exact way you would deploy it for anything else. It it is the same exact software, actually.

Okay. So for anybody using ZTNA to come inbound into the network to access applications, the policy is the exact same policy you would create today. What's kind of different though, uh, and what's really nice is we've created this nice walled garden on the Edge connect for the connector itself.

And so packets exiting the connector traverse our next gen firewall stack. So if I want to do I-D-S-I-P-S or other sorts of inspection, uh, on the Edge Connect for anything egressing back into my network or going back out, we actually have the ability to hook all that in right there. And so there is some additional capability that's actually added in as well.

And those policies, uh, unified Orly Con, like Edge Connect policies are still Edge Connect policies. The ex the SSE access security policies are separate still today? They are, yes.

They, yeah. But the goal eventually central unifies all of it, all the way through the wifi into the iot device. Absolutely.

Yeah. I mean, we are driving hard as a company and product teams towards like Universal Zero Trust. Yep.

I mean, our view of the world is that, you know, you do the policy in one place, it's enforced at a gateway, it's enforced, you know, at an access point, at a switch port. Uh, it's enforced in the SSE cloud. This is something that we are definitely driving towards.

So It'd be like, you know, all the way to PV land, all the way to iot device type all the way through. Yes. Got it.

Does that include the HVM manager? So you're all the way to the data center input to data center common policy. I need to let, uh, whoever's was going that one, but right now, like on from the HP Aruba networking side, it's been primarily on, on our portfolio.

Um, definitely that could expand out into other parts of the HP offering though. Hello everyone. Uh, my name is Matthew George.

I'm a technical marketing engineer focusing on NAC solutions like ClearPass and Central nac. And today I wanted to give like a really quick overview about one of our newest, uh, offering in the NAC space, uh, which is, uh, central. So our journey towards cloud native NAC started way back in 20, uh, 19, uh, when we started doing the market research about what are the customer requirements, and one of the main takeaways was everybody, uh, wanted to or have a very simple way for the users and devices to connect to the network without all the complexity that an on-prem NAC solution has.

And with that in mind, we created the cloud auth surveys, uh, in 2021 in classic central platform. And now in 2025, we have the new central, or, uh, we have central n in the new central platform. So let's see how Central Mac works.

So all the aps, uh, gateways and, uh, switches that are managed by Aruba Central would establish a rad sec connection to the central platform. We don't use, uh, radius at all, uh, because Radius is, uh, inherently insecure and cannot be trusted over, uh, public, uh, cloud and untrusted networks. Uh, and once a request, uh, reaches Central Mac, we can do authentication and authorization against cloud-based identity sources like Google Workspace, Microsoft, entra, uh, and Okta.

In addition to, uh, validating the group membership and other attributes from the IDPs, we can also work with the client Insights module in, uh, new central platform. Client Insights is the advanced profiling and visibility module within New Central, where, where we combine that device fingerprint. So traditional device profiling has always been based on static, uh, profiling, like using the device fingerprints.

But now in Client insights, we combine device fingerprints with the traffic flow information, and we use our AI ML models to, uh, derive very accurate and granular, uh, profile information about the devices that are connecting to the network. In addition to that, client insights also has these integrations built into third party, uh, systems like N DM solutions like Intune, uh, uh, Jamf Workspace One. Uh, we also have integrations built into endpoint security solutions like, uh, VMware, um, workspace One, or, uh, it, it could be Microsoft Defend or CrowdStrike.

So leveraging all these integrations, we are able to fetch compliance attributes. We are able to fetch information like whether the device is managed or not, and we can use all of that as part of the NAC policies in the new central, uh, platform. Uh, we also have the, uh, air Pass, uh, a service called Air Pass, which uses sim, uh, based authentication.

This, uh, service is only available in the US today, and we support at and t and, uh, T-Mobile Central n also contains the, uh, cloud guest module, which, uh, offers, uh, several different types of, uh, guest workflows for visitor logins. And here I wanted to talk about, uh, some of the key use cases that we are trying to solve with, uh, central n. Uh, and just like I mentioned before, like on-Prem Mac solutions tend to be very complex, and it's, uh, it's more, uh, suited for use cases, uh, that are very niche.

Like if a organization has a lot of niche use cases, then uh, maybe a complex on-prem solution might be a good fit. But here, uh, we are aiming for simplicity. So in terms of, uh, user authentication, we support do one X with ETLS with authorization against cloud-based identity sources.

Uh, we do not support username and password, uh, authentication because passwords are considered inherently insecure. Uh, vendors like Microsoft are on their way to deprecate, uh, u username and password support, uh, in their operating systems as well. Uh, so now when we do, uh, certificate based authentication, there needs to be a way to easily, uh, push a certificate onto the device and provision the network profile as well.

And this can be done using a Aruba onboard app, or if you want to use different mechanisms, like if you want to use ad group policies or active directory, or if you want to use, uh, active directory certificate services as your PKI, or if you want to use, uh, Intune or, uh, workspace one management to push, uh, certificates onto the device, all of that can be done, uh, today. Uh, so we added support for something we call the bring your Own certificate, which means that we can work with external PKI, uh, and any kind of, uh, uh, cas out there for user authentication. We also have, uh, mp SK, uh, based workflows.

So MPSK is multip appreciate key, uh, and there are two flavors of MP SK, that's the user based MPSK, where a user will log in using the cloud IDP credential would generate appreciate key that's unique to that user, and then the user can connect all their personal devices. So this is really useful for like dorm room scenarios where I have, uh, a bunch of personal devices I want to connect. And so now MPSK lets me do that.

Then there's the admin based MPSK, uh, where, uh, and this is more useful for, uh, devices that are not assigned to a specific user. Uh, so corporate owned iot devices, for example, right? So the admin would generate appreciate key, which then can be used with a device or with a group of devices.

And for device authentication, uh, we support Macau against a list of registered Mac address, or we can do allow All Mac out as well. Sure. So this, this is cloud native.

This is, uh, fully cloud native on the new central platform. Okay. And so with it being cloud native, is there, does it scale horizontally like indefinitely, or is there a set amount of endpoints that this can support from like an like, 'cause because the physical boxes, you have like a hard number where if you're like over 50 K endpoints, you Yeah, That's need put another box in place.

So Yeah, so we haven't, uh, found, uh, like that upper limit yet. So based on our internal scale testing and the published numbers that we have is, uh, right now the number that we tested against is like a hundred thousand users. And, sorry, 300,000 user groups in IDPs and a hundred thousand users.

Yeah. Okay. And so as far as like, okay, so a hundred K, so, so if a customer with this being cloud native, it wouldn't be like site specific that they're authenticating their endpoints, right?

So does that mean if the customer has more than a hundred thousand endpoints, there's going to, they're going to, We, we can, uh, scale horizontally as well. This just the test numbers. Uh, but uh, we can go beyond that as well.

Okay. Yeah. From a, from a product, uh, portfolio perspective.

So this is NAC services running in Central. Is this effectively replacing ClearPass? Uh, no, it's not.

Uh, because as I was mentioning before, like customers have very different use cases and some of those use cases are more complex. Uh, whereas, uh, what we are looking for with central N is to service those simple standard use cases where customers just want a simple way to connect devices to the network without the complexity. Okay.

So if you're doing TechX, for example, right? There's no way to, like, there's no secure way to send TechX to the cloud, so then you would need, still need something on-prem. Okay.

And I, sorry, my slide jumped ahead a bit. So in terms of, uh, guest authentication, it can be as simple as, uh, click to accept terms and conditions or as complex as self-registration with sponsored, uh, access. Uh, we also have the Air Pass service, the SIM based authentication service, as I mentioned before, which is predominantly used for, uh, uh, friction way, frictionless way to get the guest users on the network.

So for captive portal deployment, does that make it easy with this or captive portal configuration is separate, Uh, in, in terms of Air Pass or in terms in Terms of No, well, not that it's Central Generally, yes. Central captive portal. Does that integrate with this or, Yeah, it does.

It, it makes cap portals easy. Like, uh, for example, uh, if, if you had a lot of sites spread across the country, then, uh, with the on-prem next solution, you might be thinking about like building redundancy. So you might be placing like two of those on-prem boxes, like each sites just so that you have local redundancy.

But now with everything on the cloud, the redundancy is built into the cloud architecture, so that, that saves you a lot of work in terms of the routing, the traffic. And in terms of deploying the on-prem boxes as well. With this, can I do a policy that says, as long as you have a valid Google account or GitHub account, you get access through the CAPTA portal, You can do that.

So, uh, as part of our visitor solution, we support four different, uh, social identity providers, and that's, uh, Twitter, LinkedIn, Google, and Facebook. Yes. No Blue Sky In your time.

So let's, uh, do a Q demo. Uh, so this is New Central, and once we get to Central nac, uh, we get to see this dashboard where we break down information in terms of success versus rejects and, uh, reject reasons, the top sites, where the requests are coming from, we can, uh, drill down into specific sites and see this. So, uh, we also have the client dashboard where we can see a detailed information about the clients that are connecting to the network.

So here, for example, if I were to, uh, search for a user, uh, called Adam, uh, I can see that there are, uh, two different devices connected, one over the wide, the other one over the wireless. And now if I were to, uh, click on, uh, any one of these, uh, devices, uh, here I can see that, uh, on the left hand side, there's the user group. Uh, so this is a group membership of the user on the IDP side, which was, uh, used to derive the policies and the outcome for this user was the role that was assigned, uh, which is VIP employees.

Now, uh, one quick demo that I wanted to show is like how, uh, how well we've integrated the IDPs into our solution. So I'm going to remove, uh, Adam from the VIP employee group. And what that should do is it should trigger a notification to Central NAC that something has changed for this user, that the group membership has changed.

And when we see that, uh, central NAC would check whether, does this mean that there is a change in outcome for the user? Does it result in a change in VLAN or a role for the user? If it does, then central n would force a REA authentication, uh, and apply the new policies.

And this takes like a minute to happen. So while we are waiting on that, let's take a look at what device Adam is using. So on the bottom left hand side, uh, on the classification, this is where we show the information that we get from Client Insights, and we can see that, uh, client Insights was able to accurately classify the device on top of that, it was able to apply certain tags as well.

And these tags are coming from a third party integration. So we have integrations built with, uh, CrowdStrike, Intune, Microsoft Defender, and we are able to pull in compliance and other attributes, all of which can be used as part of the NAC policies. And, uh, another thing I wanted to point out, if you look at the vendor, we can see that this request came from a Cisco switch.

So we, we now have true third party support where, uh, we can, uh, authenticate users from, uh, any, uh, kind of, uh, um, any kind of network infrastructure, and we can support all these complex work workflows, uh, there as well. So now, uh, let's, uh, take a look at Adam, and we can see that the role now, the user group membership now changed to employee, the assigned role changed to employee and the VLAN would've changed as well. So this is true zero trust in action.

Like we made a change for on the group in the IDP, we changed the group associated with that user, and that within a minute triggered, uh, a chain of events which led, which led to the network access, uh, being, uh, changed as well. So this is, uh, o one of, uh, one of the better ways, uh, that we, uh, we, we have been able to integrate, uh, the NAC and the IDP together that happens on the reauth, right? In a a typical solution, it would happen at the ot, you would've to wait for the device to come again.

That's right. But this, that's not the case here. Okay, got it.

Here we get direct notification from the IIDP that something has changed, and we forced the re-op at that. Oh, you forced the re-op. Yeah.

Got it. Exactly. So it's more real time.

Yeah. Can I ask, um, you mentioned, uh, everything was being done via RAD sec. Um, does, uh, does ClearPass act as the ca server in that case?

Or is it, do you have to use like a Microsoft? Um, so you don't have to worry about the ca the EC client or the server certificates at all? Uh, because, uh, all you have to do from a config perspective is when you set up a wlan, you have to select a central Lancaster authentication server.

Okay. And then the ap, uh, switch gateway will it, it, it knows what needs to be done, will set up the rad SEC connection. Okay.

It will use the TPM search on the device as a client certificate. Okay. And the CAS search for the, uh, central N server, uh, built in as trusted, uh, cas on the device side.

So the RAD SEC tile comes up automatically without, uh, you having to know anything in, in detail about the CER certificate. So, so we're talking about wireless, uh, at this point, but is there support for wired as well? Uh, yeah.

So this request came up, came from a Cisco wired switch. Oh, okay. Is That, so, so we have both wired and wireless.

Is that true for third parties as well? Yeah, Cisco, this came from a Cisco, yeah, Cisco switch. Oh, right, right.

Sorry, the, the RADS sec ca question. Oh, so the rad sec ca you don't need rad sec for third parties. The way, okay.

The third party support works is, uh, you need a AOS 10 gateway between, and the third parties will send radius requests to the gateway. The gateway will then establish the Rat SEC tunnel. So it acts as a man in the middle and the proxy.

Okay. So you're like, Cisco switch would be radius to the gateway. Yeah.

Keep things simple, uh, within the campus. Yeah. Okay.

And here, uh, so there was a question about like whether we work with wired and wireless. So both of these users, uh, Adam, uh, both of these devices for Adam. Uh, one was wire, one was wireless, and we can see that the role change happened for both of them.

So it doesn't matter what infrastructure you are on, uh, Cisco, Aruba Wireless, uh, all of these flows, uh, work seamlessly. So does that, does that also come into play when we're, I mean, right now we're authenticating, we're authorizing assigning a role. Where does enforcement of those authorization take place?

Like it, if it's it's multi-vendor, is there the option to where, okay, okay, great, I've given 'em this role, but what level of access do they have based on that role, and where do I enforce that access? Yeah. Uh, that's a good question.

So when it comes to a multi-vendor, like if you take that Cisco wide switch, for example, role doesn't mean anything to the Cisco page. So we can do a VLAN enforcement as well. And that's what I was, uh, doing here.

I was switching the VLAN for the user when, when that, uh, group membership was changing as well. So can I, sorry, can I map VSAs to That? Uh, right now we only support, uh, VAN and radius session, uh, timeout.

But additional VSAs, uh, are something, uh, we are looking at as well. So in terms of enforcement, we can do VLAN enforcement or role enforcement, uh, today, uh, everything else is, uh, future, But, but if it's v enforcement, it would still be at the point where that traffic comes back to an, an Aruba switch. Uh oh, no, it, it'll be enforced, uh, at the Cisco switch itself.

Uh, it doesn't have to come back to Aruba Switch. So whatever infrastructure they have, uh, at that place, we can work with that. Yeah.

Okay. Thank you. Yeah, The gateway doesn't have to be in line to the traffic, the gateway, just access the Rat SEC proxy all Got it.

Because, and this is nice, I, it's, it's nice that you have a multi-vendor approach because that certainly exists and to where that you're able to assign roles to endpoints regardless of whether, I'm just, I was just curious about the next piece of the puzzle where, okay, what do we do with those roles? Where do we actually control the access that they're, they're receiving? Yeah.

So you could like put a gateway in front and then take advantage of the roles that that's possible, but we haven't gotten that down that far yet. Okay. Yeah.

Appreciate it. Yeah. And just a, a last thing I wanted to show is, um, I talked about client insights, how it has a lot of, uh, valuable profiling information.

Uh, so I just wanted to take like 30 seconds to show, uh, how much information, right? So if we look at, uh, the client classifications here, um, gonna go, uh, indeed. Uh, so, uh, here in my, uh, test site, uh, I'm able to see detailed information broken down into like what vendor, what model, and what type of devices.

So there are three iot devices that are connected. Now, if I want to Dr. Di drill deeper into what those I iot devices have been doing, I can go into the explore mode, click on the IOT device, and then it just sorts itself and shows me data that's relevant to the IOT device.

And here I can see the external data upload, and if you want to create custom policies and rules based on this information, you can do that. So you can create custom tags based on the destination, uh, traffic destination, IP addresses, and so on. Any questions?

Yeah, one quick question, just, uh, again, kind of going back towards looking down the road, because you're mirroring a lot of the functionality and capability within ClearPass that's there today. Is there any appetite or drive to actually migrate everything into Central and thus eliminating ClearPass? Uh, so based on the conversations that we've had with, uh, customers large and small, uh, we don't anticipate that happening in the near term because, uh, ClearPass is a still a big, uh, part of, uh, our nac uh, solution.

And there's a lot of things that, uh, needs on-prem. Like for example, central Mac only works with cloud native IDPs. You cannot use any on-prem authentication point back, Back on-prem.

Okay. Yeah. So there are still customers using s QL servers for authorization lookups and such, so, okay.

Yeah, that kind of hurts my head, but, okay. Alright. Uh, yeah, I think I'm out of time, so thank you.

Alright. So thank you for sticking with us. We're, we're at our end.

I just wanted to wrap up and say, you know, I hope today you've seen over the last couple of hours, uh, just the way that we are really using data, right? That telemetry to really drive the experience, right? Whether it be the security experience, whether it be the, uh, you know, endpoint experience, uh, whatever, we kind of, uh, turn that data towards using AI fundamentally at the, the base of it, um, really is opening up and kind of new things that we can look at and how we can drive networks in much more powerful and more, much more, uh, interactive ways, right?

So, so that's really what we wanted to leave you with today. We've taken the approach of telemetry based networking that's driving security, that's allowing us to employ AI at very deep meaningful ways in order to grab an understanding of what's going on and help the engineers and the operators really get to the kind of crux of the problem and keep their networks humming along at the most optimal way. And then finally, really enabling that end user experience, even down to this idea of kind of NAC on potentially the third party devices, right?

Truly integrating a zero trust posture across everything in the portfolio. So thanks very much for your attention today. I hope this has been really interesting.