Nile Campus Zero Trust

And we'll focus on the secret as we talked about, you know, we believe that traditional nack is broken. Customers are telling us, and I talked to hundreds of CIOs and CISOs and clearly telling us that the NAC is no longer meaningful for them. It does not meet evolving needs.

Analysts are telling us that, and we are seeing that, you know, why customers buying Nile is because of the Jira trust that we have built in. Why is that? Let's talk about it.

Traditional NA is broken. You know, it's built on, frankly, on a broken infrastructure. The network is a permissive network.

You start with the VLANs, it's a permissive network, then you're trying to bolt on. Today, 60% of the cybersecurity attacks happen because of the vulnerabilities in the network. As we said, you come in, you discover the network, you discover all the resources connected to the network, and you start propagate them malware.

That's a foundational problem. And especially OT devices cannot protect themselves. And now, you know, jj, to your point, there are overly solutions that are coming up and trying to do slash 32.

So we are doing bandaid solutions after bandaid solutions. And then other one is, as you guys know, doing the wired thought onex is almost impossible. Doing the host isolation on the network is impossible.

There are customers who spent 5,600 hours, two manuals to make sure the host isolation happens. And as soon as something changed, it all failed. So this is why the customers have given up on trying to make the NAC work on the wired networks.

There are some, and we continue to use the vlan. As you guys know, VLAN is basically, you can communicate with each other. Initially, we started VLAN for limiting the broadcast.

Then we started using Wise VLAN and Data vlan for the quality of service. Now we are using VLAN for the segmentation purposes. So again, trying to leverage what we've created 30 years ago and trying to use it for different purposes.

And IT purpose, it does not align with the J Trust principles, which is the default, deny continuous authentication, authorization, every user and devices to be connect, authenticated, authorized, least privileged access. None of these principles are, you know, VAN or the NAC can provide you those capabilities. And let's be honest, you know, you know, when you look at, uh, the reports that are coming from the YOU analyst, they're saying that, you know, the NAC market is gonna go down significantly because it's no longer meets and it's gonna be replaced with Campus Zero Trust.

And what we call, so when we talk to your customers, they have told us explicitly, my remote users are less secure than office users. That's kind of counterintuitive. You would think your office network is a lot more secure.

The reason is, when you're a remote user, you're using one of the SEC provider. They have the client connector talking to the SSC, and then the application, every user is isolated and protected from rest of the environment. Once you come into the network, you have the IT devices, OT devices, your, your devices exposed to the rest of the devices on the network, and you're dealing with do Onex n solutions, v Lance, all of these things.

This is what customers are telling us that remote users are more secured and what do they want. Again, you know, we have a customer advisory board and we talk to, you know, a lot of sales and who are, you know, running enterprises. They wanna go to, you know, trust.

Whether it's a you a remote user office user employee or guest or IT device or OT device, you need security across all of these locations, not just one solution for something and another solution for something else. So customers, for the remote users, they're going with the SSC, they'll continue. There are lots of solutions, great solutions, but when it comes to the onsite, when the employees come to the onsite, that is where the campus zero task comes in, where every user is authenticated, authorized, every user is isolated from another user or every device.

And, uh, grab, we give you microsegmentation capabilities and you can, um, define granular controls. And with the, so no longer n you're no longer dealing with any of those challenges. It's a true campus euro test that comes out of the box.

And more importantly, it can connect directly to the Zscaler or Prima Access or Netskope or any of the SEC solutions out there. We can in, we integrate with them and the traffic is automatically going for all the knot out. Everything is west that's within the building is protected using Campus zero test.

And what does it mean? So, we'll, I'll not spend a lot of time, we'll go into more details. Hey, here, the NAC capabilities, we need more capabilities than nac.

It needs to be built in, not a bolt-on. So these are all the capabilities that you need in order to meet the campus. Zero trust definition.

Alright, with that, I'll hand it out to my colleague Shiva. Again, to go through all these, you know, the details between the NAC as well as the campus zero trust and continue on campus. Zero trust.

Thank you, ssh. So one of the key things that, that we are trying to do is, uh, and you'll see the next, uh, few slides in this theme is we're talking about infrastructure access and policy. So infrastructure is the underlying infrastructure.

All we need to do secure, it follows the zero trust principles. Access is how do you gain access to the network, basically authentication. And then policy is once you're on the network, you have an IP address, what can you do, right?

So in those three buckets, if you start with traditional networks, you are talking about T acts, right? That's, that's what's been used. You try to, you know, control who can access the network.

In the zero trust world, especially in the service model, we are saying, why do we need to access that hardware, right? The hardware should be built with all your logs, everything streamed, you know, in real time. You need that last breath.

You know, we can use a mobile app, but eliminate that whole access need. And the only reason is, hey, if we can access it as Nile, someone can break into it, right? And this is our responsibility, so we have to lock it down as tight as possible, right?

Second is encryption is not there by default, right? You can buy a switch that supports Max X, setting it up is a nightmare. I don't know, single customer who's really set up max sec with n that comes by default.

So an AP to switch is max X encrypted, you know, from switch to switch is max sec encrypted. So if you try and snoop those traffic, you're just gonna get encrypted traffic. And this is completely done in an automatic format where these devices come up.

It's designed to, you know, form that Mac sec connection with the sphere and then also mutual authentication. That's not something that's done today where you mutually authenticate with, with your controller or with a switch. Uh, with Nile, it's, it's end-to-end, right?

AP authenticates with the switch and vice versa, switch to switch. All that stuff is again, built in using the search that are burned on these devices, right? So we're trying to make sure that the underlining hardware is, is as air tight as possible, right?

Uh, and you know, we'll have Avinash talk us through a bit more details. one X enabled or Macau enabled. You have to identify those ports.

You have to basically use an external ice or a clear pass or any of those, you know, uh, n solutions to really tie all this stuff together with Nile that comes baked in, right? one x and or SSO Macau, you name all the odd types that exist today. It should be an automated fashion and as simple as possible, right?

It should not be a default allow, there should be no bridging so that you avoid any of that layer two malware propagation that can happen by default. The VLANs, it's a big burden, right? Let's face it.

Sure. If you have a retail sites, everything is cookie cutter, you can use templates and just, you know, paste it across. But that's not true in enterprise, right?

Every closet is a snowflake. Every closet has different configs, different types of devices connecting in manufacturing, people randomly plug stuff, loops are formed, and these are all the doings of VA, right? And let's not use VAS for what it wasn't designed for.

And that's why it's a full blown dear three network. You don't configure. It's all identity based.

You know, you, you create rules, you create policies, and if nothing matches, you can manually go and override that stuff. Identity based office is very, very critical. You know, we think that's a cornerstone for zero trust.

Uh, and it, and you'll we'll see a bit more in detail. It's not just identity, it's even a, you know, device posture that go hand in hand to make sure that the policy is appropriate. And we'll give you a good example around that.

Continuous authentication in n skim is all built in, and we'll talk about that. You basically disable the user right off the network right off the bat, right? You don't have to worry about whether certs are expired, whether they have the PSK key, none of that stuff, right?

So it should be continuous max proofing. Why should we set up max proofing today? That should just be there by default, right?

That, that, that is a vulnerability that that exists. So let's not worry about configuring it, it should just work. You know, by default, default devices, you can, from a policy perspective, everything is allowed to talk to everything by default, right?

You, you have to put in the rules. The policies with NI is the opposite. Zero trust should always be either deny or lease access privilege, right?

That's what we wanna talk through. And then finally, zt ZT integration should be very simple. You just give us your API key, your provider, and that's it, right?

What, what popped to go do, how do we connect? All that stuff should be fully automated, and that's something that we think completes entire campus zero trust, which is making sure everything in the access layer is, is airtight. And then anything beyond the WAN is within SSE integration.

So with that, we'll walk through these three buckets of infrastructure, uh, access and policy. And I'm gonna hand it off ache to take us through that. Uh, so thank you Shiv.

And, uh, I, I'll, I'll cover some of the key aspects of in infrastructure security. The first one being the trusted platform module. So each Nile element comes equipped with keys, uh, cryptographic keys, which are actually stored within the TPM module.

Uh, so these hardware back backed keys will actually provide for a strong authentication and prevent against key extraction attacks. The second one is against, uh, secure Boot. So Secure Boot basically ensures that there's a trusted, uh, immutable boot sequence for any of our devices, and it uses cryptographic authentication again, to ensure that only Nile authorized software can run on these devices.

Uh, what this ensures is that anytime a nym comes up, it starts with the basic security level, and it protects against say, uh, uh, tampering or even flashing attacks. Like, uh, thirdly, the, it always runs the latest software patches. And the way we actually push it from the cloud, like say a hot fix is always over the secure t ls tunnel.

So you can't have any other channel, uh, channel through which you can actually push these hot fixes up, actually. And lastly, all access to Nile elements is, is actually secured. What does this mean?

Uh, typically, uh, network in, in infiltration starts with network discovery. You have protocols which you use for network discovery, like whether it be CDP, whether it be IP on which you have ping a trace route, or you have LLDP. These are blocked by default on NL.

Uh, see, in spite of this, there is some, a determinant intruder who actually wants to get into the box and understands that an NSV ip, uh, the next thing they would do is try to establish a connection with this particular element. Uh, using protocols like say Telenet or SSH talent is blocked by default. And SSH is actually disabled.

I would also go ahead forward and say that, uh, even for a Bluetooth interface that we briefly discussed, um, the Bluetooth interface, it serves, uh, employees an authenticated access with associate data algorithm, which prevents any kind of m enterprise access. So as a result of this, in any of the follow-up infiltration, uh, attacks, which would be like, uh, you would actually try to do privilege escalation or you could actually do reconnaissance or lateral movement, those are all stopped. Okay?

Uh, further carrying on, uh, like, like she mentioned, each of the devices or each of the Nile elements between each, uh, each other, the set of TLS connections, and this uses the previously mentioned identity ate, which is burnt into the TPM. So you can't have unauthenticated elements try to connect to the NSP. The next one is all the communication between the Nile elements in the cloud happen over a TLS connection again, but both the client side and the server side certificates are validated.

These are X 5 0 9 certificates, they're validated, and a trust chain is established. And only thereafter a message is sent over the TLS tunnel. And the last thing I would want to mention is maxik is enabled for traffic encryption.

This is basically ensures that the data, the data, the data packages that are flowing are encrypted and there's integrity which is enabled on that. And this secures all our, um, all the ethernet links, whether it be from the AP to switch or from the switch to switch, again, preventing against eavesdropping or tampering. With that, I'll hand it over to again, Thank you Manash.

So let's talk about access, right? So right now, we have tried our best to make sure that that network is as, as airtight as possible. So now, how do devices access the network?

So we all, we spoke to you about, you know, the switches being completely blocked by default, that colorless ports, uh, is an explicit deny. You cannot do anything without being authenticated. So from an authentication standpoint, we basically have three options, right?

one x, we go to the radius server. The radius server tells us, put this person on segment A, segment B, segment C. And segments are nothing but layer three constructs.

0. 0 slash 24 in site fee. So it's nothing but a subnet mapping, right?

So radio server gives us a Nile VSA or a, or a, you know, tunnel private id. Uh, and we can then put that device on the segment. So that's why there is no config on that port because the Radius server will tell us if Radius server doesn't tell us, we can do a Macau, uh, and Macau, we can do fingerprinting.

So you can actually say, you know, HP printer 5 0 1 1, uh, is supposed to be in the printer segment, right? So when that device comes online, we fingerprint it and we basically put it on that printer segment. Third option is, if you don't have any of those rules, you can create this catchall pre-auth rule, if you will.

And we'll double click on that in a minute. And you can actually do guest or doc one or SSO on a wide device, right? So literally you get your, your corporate, uh, id, IDP page as a redirect page.

You put in your credentials, you can basically go and do multifactor authentication, and then you get access to the network. So that's how we basically make sure that these devices, uh, are not on the network by default. They have to identify themselves, whether they're iot, ot, or users, it doesn't really matter.

And then finally, once all that goes through, that's when you can actually get a DH CCP packet going through. So you're actually just gonna send A-D-H-C-P frame, and while you send that, we're gonna be doing all these things to, to verify who you are. And based on that, give you an ip.

one x, but SSO You support multiple levels for guest authentication. For the guest support, Yes. So what we support, uh, is you can do admin approved, you can do email approval, and that's, I think the next slide right here.

Uh, septum and condition move on. We've got SMS coming as well. Yes, multiple options.

So talking about that, there are multiple ways to authenticate radius. You can, you know, have 80, 80 gives us groups based on groups we can basically put you on on different devices. We can also integrate with ClearPass ice, get the groups and send that group information to Palo Alto using XML APIs.

You can do identity based if that's what you need. We have single sign on built in. All you do is set up an IDP.

It takes five to seven minutes to tie it with Nile. Once you set that IDP connection, you can use it to log into the portal as an admin monitor or help desk user, or you can use it as an end user on an open SSID, on a PS SSID on a captive report s Society. So you can actually just have that option that if someone connects, force them to go on to go through SSO skim indications also tied, as I said, you can literally go into the IDP disable the user right away.

We get notified, we kick the user off. So you don't have to worry about revoking certificates, p SK keys, none of that stuff, right? Even though they might be on the network, 'cause they have the PSK key, it does not mean they can get on the network.

Finally, fingerprinting is built in. We use multiple data points, whether it's user agent data, whether it's multicast frames, DHCP frames, DNS frames, uh, anything and everything that we can, when we can get that gives us a better score. And that's how we fingerprint devices and us being in line versus clear password.

Just in a d HCP packet, our fingerprinting obviously is much more robust than what it would get from an out of Band Max solution. So let's quickly touch base on wide SSO wide SSO. All you do is you create these rules.

You can say, uh, you know, dot one x, you could have fingerprinting rules. And when that device plugs in, it does not meet any of those rules. It falls into this pre-op segment, if you will, gets an IP address.

Two things can happen. You can either do guest or, or you can do guest and wide SSO, uh, that we can onboard the, you know, people automatically. So universities love it because they have students, teachers, staff, and they have guest people who come and who present.

Uh, so getting on the network becomes very easy. No, uh, you know, admin interventions is really needed that at point. one x, we check all the rules that you have.

It could be a MAC based o UI based, it could be a fingerprint, does not really matter. We then put you in a pre-op segment. Uh, based on that, we go and check whether you are an approved user or not.

If you are not, we get a redirect, URL from our cloud. We send you to the, to your, uh, IDP page. You log in, do MFA, your IDP tells us it's all good to go.

We then let you on the network and we move your segment in the back. We move you to the employee segment and, you know, tied with skim groups and stuff, we can even move you to employee versus, you know, uh, uh, uh, you know, employee versus HR versus sales, whatever we want, or teacher versus a student. And then finally go through DHCP.

So we make sure that this, this entire, uh, flow, uh, is something that enables our IT admin not to be sitting and approving devices one by one. Because if then it's an explicit deny, that's one big question that comes up. How do I authorize devices do have to do one by one, which is obviously not scalable in a large network.

And that's where all these rules, uh, you know, come into play. Any questions? Alright, so this is what I was talking about where you can basically get a guest page.

This is just acceptance and conditions. It could have been email approval, it could have been, uh, SMS, but the key thing here is employee login. And there are multiple use cases for that, right?

One could be, I want to have my, uh, you know, employee's personal devices on the guest network, but I don't want to kick them off every, every, you know, every day or every week. I want a longer duration. That's where SSO comes into play.

Or it could truly be I want to give them employee access. And if they go through SSO, I will put them on the employee segment and then let them through. You can, you can get best, best of both worlds.

Alright, let's talk about policy. The next one, and this is something that we are trying to redefine today. If you look at policy, it's all based on subnets for most part, right?

Everyone does, you know, something based on an IP or location that we are, we are plugged into. So with Nile, what we've done is we've actually re-architected this whole policy engine. Uh, first thing we do is we have defined a construc called groups.

Groups are three types. You can have a user group, a device group, or an app group. And user group is anyone who can authenticate using gradus or SSO, if you will, or skim, right?

With Skim, we can get those group names. So you can create a group called employee, and then you can create rules that anyone who matches sales, marketing, hr, put them in the employee group. You can create an employ an HR group or a sales group if that's what you want.

But the idea is all users fall into a certain type of user group, if you will, device. They're all based on fingerprinting. Now mind you, you can also do everything based on subnets, the way you wanna do it today, if that's, that's something you wanna do from a migration standpoint, we support that.

Uh, but you can create device groups. Device groups would be based on fingerprinting, all printers, you know, all my, uh, zoom rooms should fall in the IOT segment, IOT group, if you will, once you create the groups. Uh, the next one is the app one.

The app group is anything external to the NSP, if you will. So all your data center subnets all your applications, they can, they can be an app group that you create. Now with these groups come something called an attribute set.

Sorry, go ahead. Just while you're talking about this, just referring back, you had a slide up that showed what Nile does, what the customer's responsibilities are. Customer probably has a lot of this already done.

Is that one of the Nile things that you'll help them transition from their version to this version? Absolutely. We will support them and try and move them over from what they have to what Is that Automated at all or is this a It's, it's not automated today because as you can imagine, you know, we were looking at a Juniper, uh, you know, uh, output from a firewall perspective, right?

Completely different, you know, ip, uh, IP access list, if you will. Um, so we will look at that data, we'll figure out what user groups you want and we can assist you with, with migrating that over. Is this much of a pain point?

Sorry? Is it much of a pain point with your current customers? This one, The, the transition.

Oh, So migration, frankly, a lot of customers as we are talking about, is not leveraging any of the East West policies because it's extremely complex. Most of the policies are not south so that you can continue to keep in your SSC world or in our internet gateway or the Edge service. But other is for the east west, we're able to migrate them through professional services.

Uh, but many of them, you don't run into those challenges because customers are using simple vlan, employee vlan, guest vlan, and IO OT vlan. But are, I mean, for groups, especially for users and vice, are you not just connecting into whatever IDP they have? Absolutely.

And that's just a dynamic relationship integration that's persistent. Then they don't need to do anything. They don't need all, they have to say, I wanna create an employee group.

And as long as sales, marketing, HR comes in, put them in this group. So when Radius happens, when, you know, SSO and skim happen, okay, we got, Could just leverage the groups they already have if they've got that In their, yeah, we are not creating anything new outset of their existing constructs of Radius and, and, uh, skim and IDP. Yeah, attributes set is defining, I might be shiv, but I have two devices, right?

I have a corporate issued laptop and I have a phone. I'm doing SSO. So it's the same, right?

How do you distinguish between the two? And that's what attribute comes into play. Attribute could be an EDR compliant laptop, it could be location, uh, you know, or time of day.

It could be what SSI you're connecting to, whether it's wired or wireless. So now you can take that user group and tie it with an attribute set and create a more fine granular policy. And I'll show you an example in a minute I'll probably become more clear on what that means.

Really quick question on that, with without an agent on the endpoint, how are you correlating the different NIC identities on a device? Yeah, so we are working with, you know, Intune or CrowdStrike, right? Uh, so these, You integrate with something already there.

Exactly. Okay. Right.

Service profiles, I think that's very straightforward. SSH only HT Ps only ports and protocols essentially. And policy sets is where you can create these actions.

You can combine all of this stuff and say, I wanna forward this out, you know, uh, to a Sims platform, or I want to allow or deny, right? Or send it to Zscaler, right? So some SSE platform, but the key thing here is this is all based on zero trust principles, right?

We are try, we are saying do the, create the policy based on identity, whether it's fingerprint identity for IOT devices, or it's a user, uh, based on radius or, or skim, uh, or, or SSO for that matter. Uh, so we, we make sure everyone is authenticated and authorized. We make sure it's continuously, uh, authenticated.

So skim, if someone gets disabled, the policy would change dynamically. Uh, and then finally we try to deny all or least access on how you wanna set it up, right? So we try and follow the core principles.

So I've got a quick question. You, you've gone through a lot of how everything's secured. Uh, what about the devices that need access, like, uh, apple TV or something so that your users can share screen or, or things like that?

Absolutely. So you could go and first thing is onboarding that device, the Apple device. You can actually go and create a fingerprint rule, uh, and say anything, uh, that matches an Apple tv, for example, put it on the IOT segment.

So when you plug that device in, if it gets fingerprinted as an Apple tv, it shows up in there. If it doesn't get fingerprinted, it'll be waiting for approval. You have to manually move it into that segment.

So now you are on the segment, you have an IP address, and now it starts advertising. Uh, so the key question is How does the employee get to that device? Is there a rule that has to get created to allow that?

That is correct. Yes, the advertisement will be automatic, but when you click on it, if there's no rule defined, it'll get basically get denied. Perfect.

Yeah. So by default, sorry, went too quick. By default, everything is denied in the NSP two devices on the same Subnet also cannot communicate with each other, even though they're on the same switch neighboring ports, right?

Everything will be denied there and there is what we call the trusts engine, where you will have to create those rules to allow that traffic to go through. So what really happens is once you plug that device in and you have that microsegmentation enabled employee can talk to a printer, uh, then that traffic will be led through, you know, through the, the policy engine. Uh, and that'll be allowed.

And how this all comes together is, is with this one example, uh, if I take, uh, John and John is doing SSO for example, uh, when I do SSOI do not know what kind of device you have. So whether it's John with his corporate laptop or it's John with his personal iPhone, I'll just get the group back saying employees, right? So if I create a rule based on employee, then his personal iPhone would also, you know, land up being, uh, you know, getting access to the data center subnets or anywhere the employee can go.

So here, what happens is the attributes set comes, uh, you know, in handy where you can actually say, if it's John and it's an EDR compliant laptop, right? one Access society and he's, you know, doing X, Y, and Z, that's the attributes set that you can form. You give him access to data center subnets.

And if he does not have an EDR compliant, uh, device, then he just gets internet access only. So now it does not matter what IP address John is on, right? You could, if you want to get put them on different subnets, you can do subnet based, uh, policies.

But what we are saying is do it based on identity. Do not worry about the ip. So you can literally have a slash 16 subnet.

You can put everything on that one subnet and you can have the policy, you know, uh, define what those devices can do. Now there are exceptions, right? There are your HVAC systems, right?

There is Sonos, right? Which needs broadcast to work, create a separate segment, enable broadcast on them, and, and let them be alone. But anything, uh, where you can actually fingerprint and you can have these devices that need to talk, you know, those, uh, to the upstream router or firewall or your, uh, industry subnets, uh, you can create policy.

So very quick, you have your policy here, you can click on that cell and then you can just go and create that whole policy with the user group attached to it, attributes sets, uh, and apply it.