A VPN Enthusiast’s Guide to Migrating to ZTNA

Jo:

Good morning, good afternoon, or good evening, and welcome to today’s Banyan Security webinar entitled A VPN Enthusiast’s guide to migrating to ZTNA. We’re very excited about this topic, Ashur Kanoon is our local VPN enthusiast. He’s not just a VPN enthusiast, he is also the, uh, vice president of technical marketing here at Banyan Security.

He’s an industry veteran with a broad range of experience in engineering and marketing technologies geared toward cybersecurity, and today he helps some of the largest organizations in the world understand more about zero security, and especially how to migrate to that, a zero security strategy. And with that, I’m gonna go ahead and pass it over to Ashur. Thanks so much for joining us today, and just save your questions ’til the end.

Ashur Kanoon:

All right, thank you so much Jo. So, welcome everyone, uh, let’s get started. All right, so a little bit more about me. So, I have been in this industry for 23+ years. Uh, I work on VPN and NAC, the network access control. So, it’s really all about access, whether you’re on-prem and off-prem. Uh, I started back in the Cisco Pix days, and that’s evolved to, like, a VPN concentrator. Then there was the technology on the, uh, Cisco 7000 routers and switches, and then we had the Cisco firewall, the ASA and AnyConnect. And I’ve continued to work on, um, different products from Cisco, Juniper, and Pulse Secure. And now, uh, at Banyan we’re helping all these folks that, um, were using this technology 20 years ago to migrate to something that’s, uh, a little bit better.

And that’s what we’re gonna talk about today. So, if we look at the agenda, we’re gonna first talk about your goals. ‘Cause you obviously need goals, something you can measure against so you know how you’re making progress. We’re gonna look at, “How do you plan this migration?” Uh, we’re gonna look at things like how to discover resources in applications. Most folks who have VPN deployed are using a fat layer three tunnel, uh, and they’re really not sure who’s connecting to what. So we have, uh, features and functionality that will help with that, then we’ll also look at creating policies. These policies are based on the device risk level, as well as the resource risk level. Right? This is very different than VPN, where it’s just who should connect to what.

Uh, we take risk and device into consideration. We’ll look at how we do that, and then we’ll talk about how you enhance the user experience. Uh, a solution like Banyan, uh, makes it really easy for the end user. What I call decisionless access, uh, we’ll talk about how that works, and then we’ll also look at how you leverage existing investments. You might be doing some of these integrations today, uh, on your road access system. We’ll look at how you take advantage of those also going forward, and then lastly we’ll talk about putting your legacy VPN, uh, to bed. You don’t want to have two things running, and with the introduction of our service tunnel, uh, you no longer need a VPN, uh, anymore. So we’ll- we’ll kind of talk a little bit about that.

So, let’s get started with goals. So, the goals of moving from, uh, what you have today, the VPN, uh, to something that’s zero trust. Uh, there’s a few different goals, one is simpler deployments. And when we talk about simpler deployment, we’re talking about, uh, how do I manage the devices that I deploy? A lot of times you’ll have two devices at each location. You’ll have one that’s active, one that’s passive. Um, you might have a virtual instance that’s also managed independently in, like, AWS or your cloud service provider. Uh, we’ll talk about how, you know, to make that a lot simpler. Uh, in today’s legacy VPNs, um, most of them, each device is configured independently. What you really want is a way to push out configurations to all of them, so think about how you can figure authentication or your triple A serves.

Right? You don’t want to have to go and figure it in one, and then copy it to each one of your devices. You want to have centralized configuration, and that’s what, uh, Banyan’s solution provides. And then you want to have a much simpler end user experience, and I’ll just give one example. For most, uh, VPN vendors, uh, the end user’s used to going to the menu and then clicking down and seeing all this stuff, like 10 devices to connect to. They’re all for your organization, but they have to go and make decisions of, “What am I gonna connect to? Where does my application live?” And if you haven’t done technical users, they’re probably not even gonna know.

So, they’re gonna have to connect, and if they still don’t have access, disconnect or reconnect, go through the authorization process, authentication process. So, um, the way we make things… That the goal you should have is to really simplify the end user experience, uh, and make it stealth if you can. The best end user experience is when the end user doesn’t even know they’re using a product. They just go to a browser for example, they go and click on their bookmark and they’re in, they don’t know all the magic that’s happening in the background. Uh, another goal for your organization is to make the entire deployment more secure. And this starts off, um, by decreasing the tax surface on the edge. So if you have a VPN, you’re probably exposing, uh, different ports. Um, a lot of times that VPN appliance is easy to find, ’cause you’re using very common, uh, domain names like VPN.mycompany.com.

So, we want to make sure that everything becomes more secure, and then also you want more visibility. So today, your VPN… Uh, you might have multiple appliances, so you have to go check all of them to see who’s connecting. Uh, but you want a single pane of glass view of not only who’s connecting, uh, but also where they’re connecting to. So if you have an integration with, like, your identity provider from the Banyan portal, you can also see who’s connecting to all your cloud applications, so it’s not just on-prem. So, these are goals to keep in mind when you’re looking at, um, uh, uh, zero trust deployment and migrating away from VPN.

So, the next question is, “Why should I migrate?” Right? And one of the main things is… Yeah, one thing I always hear, uh, especially when we talk to customers about, migrating is, “It’s working, why should I change something that’s already working?” Uh, versus having something that’s safe, secure, and easy. So for a lot of organizations, when they say working, um, they really mean that their end users aren’t complaining. Right? But they’re not looking at, “Hey, have I been updating my software?” Um, the software that’s loaded on my device, uh, does it have any vulnerabilities? So, if you look at CVEs, just in 2019 there was 17,000+, uh, CVEs. And of those, 4.3 thousand were high.

So these are things like open SSL having bugs, having day zero bugs, and a lot of people say, “Hey, my device is working.” Uh, because it hasn’t crashed or my end users haven’t complained. Uh, but those devices are also giving, uh, bad actors access. So there might be malware that’s in your network, there might be kinetic control traffic, uh, that got in through your VPN. So working, uh, is not good enough, you want it to be safe, secure, and easy. Um, good enough is a compromise, and what we mean about good enough is people have gotten used to a poor experience with VPN. So from an end user experience, they have to go and make decisions for the admin.

We pointed out, like, configuration and monitoring is hard. You have to log into multiple things, or you have to push all your cis log traffic into something like Splunk and then go look at it. So, it’s another thing to maintain and pay for, and then performance and scale isn’t great. Right? Especially if you start thinking about, um, active passive deployments on the edge. Now you have a system that’s just sitting there idle, right? Ideally you want active active, you want everything to be loaded down automatically.

If you have a surge in traffic, let’s say there’s, uh, a hurricane or something that’s happening where all your employees at home. Uh, you want to be able to spin up, uh, more bandwidth, more access, uh, quickly. You don’t want to be limited and having to order and rack and stack. Um, and then also, good enough means, uh, some organizations have different solutions from different vendors based on the use case. So, they might have, like, a, uh, edge gateway that comes from their NDM for the mobile side, and then they have another solution for the desktop side. This is really, um, a poor end user experience, and it’s another thing you’re paying for and hoping that it doesn’t, uh, go down. Or, uh, something you have to maintain.

Misconfigurations are also possible. So, if you have 10 different appliances and they’re managed independently, uh, you can go in, make a- a update to nine of the configurations, and then you forgot about the 10 for one. So, that 10 for one might be the- the one where, uh, people go and access. Because any time there’s a decision to be made about business continuity versus security, uh, most admins will say, “Well, I can’t bring down the system while I figure this out. Let me just unconfigure things, let people in.” Uh, and let people in insecurely, um, just because, “I need my business to continue to run and be productive.”

Uh, another reason is when we look at how zero trust network access gets deployments, it really blurs the line of on-prem and off-prem. Because what happens is when your- when your users are on-prem and they’re not having to go through the ZTNA flow, a lot of times, um, it’s really easy to circumvent all of the controls you have. So you’ll see that when somebody goes on-prem, usually the wi-fi access is based on username and password rather than multifactor authentication. And a lot of times when you’re on-prem, uh, the device posture checks aren’t done. So, uh, you might require things like firewall, personal firewall to be enabled, antivirus to be enabled when they’re off-prem.

But they can turn all those things on on-prem, uh, and then they still gain access, so you want to really make sure that you have a consistent, uh, authentication, authorization, um, regardless of where they’re coming from. Uh, and then the last reason really is… There’s so many more deployment options, uh, for ZTNA, uh, especially when it comes to deploying on-prem in a data center and your private cloud and public clouds and CSPs. Uh, and then the ease of ZTNA, uh, is so much, uh, greater. Like, for me to go and deploy a Cisco ASA, I got to buy it, wait for it to ship, rack and stack, power it on, get it an IP address, start configuring by using something like, uh, Banyan’s, uh, ZTNA solution.

I can have an org, um, a tenant up and running, and I can have end users logging in within 15 minutes. Like, the ease of this stuff is… You can’t even compare it. All right, so- so these are reasons why you want to migrate. So, let’s- let’s assume now that you said, “Okay, great, I want to migrate. What do I do?” Let’s start talking about how you plan for this thing. Where to start? So, usually the easiest place to start is you pick a known user group. Uh, this could be, let’s say, your finance team or it could be third parties like contractors. Uh, and then you pick an application that you know that they mean. Right? So, if you have a finance team and the finance team should only be accessing two resources, that’s your policy right there.

Right? They don’t really need access to anything else, so you can go and create a policy that says anybody that’s in the finance org only has access to anything else. They could request access later but this is a good place to start, and you don’t have to turn off legacy VPN. Uh, you can keep that running, so if there’s something that they need today, uh, it doesn’t mean that they can’t do their job. They just have to go back and use, um, VPN. Um, looking at existing policies. Uh, if your policies today are only full layer three tunnels, we’ll look at how that’s handled.

A full layer three tunnel should be a very, very special use case. It might be for your IT team, it might be for your super admin, or it might be for, uh, one or two developers that are having to, uh, do some, uh, things that require integration into your, uh, existing infrastructure. So, uh, we have a customer that sells cars online. And this customer, um, they do special things with routing to do low bouncing. Uh, so they need access also to the access and, uh, routers and things like that.

So, they have some users that have full layer tunnels, but for the most part you want to give the least privileged access to every user. And the most privileged access to only a very small specific group of users, all right? And then in terms of existing integrations, uh, most of them can be configured to talk to, uh, more than one appliance. So you can… Oh, you can have your existing VPN integrated along with your ZTNA. Um, do I rack and stack or go virtual? You’ll want to go virtual, um, for a- a million reasons.

If you have a data center and you do have your own hypervisors, uh, you can, uh, go that route. But for us it really doesn’t matter, right? Our connectors and our access to here, uh, gets deployed on Linux infrastructure. It can be using Docker, uh, and we can migrate these things really quickly. So it’s really up to you, your preference. Uh, we have customers that go data center first and then expand out. They have disaster recovery sites on multiple cloud service providers, uh, and that migration is super quick and easy if you have multiple hypervisors everywhere. Or you’re using, like, VMware in, uh, AWS. You can use things like vMotion to- to move these without having to shut these down.

Um, and then what about resources that are in the cloud in CESS? Uh, with a solution like Banyan security ZTNA, all of that stuff will come together in one place, so you’ll provide on-prem access, cloud access, and CESS access. You’ll have a consistent, uh, authentication policy. Um, which is great for CESS, uh, because sometimes CESS won’t let you do certain things in terms of authentication. But then they also won’t let you do certain things, um, in terms of the vistras. Actually, most CESS applications don’t care about your device. As long as you authenticate, uh, they let you in. Uh, but we- what we like to say is, you should have a consistent authentication policy and device authorization policy everywhere.

It makes it easier for your end users, and you don’t want to, uh, compromise on security. So why should I, uh, have all of these checks when you’re coming on-prem but have almost no checks when you’re going to CESS? With that, let’s look at resources, right? So, to define resources, this can be something that’s manually done. And if you only have a few resources, manual is okay. Uh, but if you have a lot, in some cases we’ve worked with some organizations that had 2,000+ resources. Some of them were managed by IT, some of them were very, uh, line of business specific. So, the IT guy we work with doesn’t even know what’s there.

Um, we have a- a discover and publish functionality, which means we’ll go find everything that’s on your network that’s accessible. Right? This could be end user devices, this could be servers, these could be applications. These are also infrastructure devices like you’re switching, routing, wireless then controllers, access points. And the cool thing about that is even if you’re not planning to publish any of this stuff, um, as a- as a security enabler, we let you see what’s there so you can go and start shutting things down or moving things into the right subnet.

So if you see somebody’s deployed a printer, uh, in- in a subnet that’s meant for guess users, and you have another subnet that’s specifically for printers and other IOT, IP enabled devices, you can start discovering those and moving them. Uh, and creating policies where they can’t add those to whatever vLine they want. But if you want to publish them, we allow you to publish, uh, web applications. And these are internal HTTP and HTTPS. And by the way, if you do have, um, insecure HTTP that’s unencrypted, um, when it’s accessed remotely we’ll actually convert that to HTTPS so that people aren’t entering, um, plain text credentials, uh, when they’re remote. And they’re not sharing any unencrypted traffic.

So, we’ll encrypt it for you. Um, if you have HTTPS, uh, in the backend, we’ll double encrypt that stuff so it’s- it’s- it’s more secure. Uh, we also provide a method for SSH, uh, to get to the CLI. We have RDP and Kubernetes, and then also just genetic TCP services. So you can define the port, you can define, uh, the backend system. This is really useful when you’re doing things like, uh, databases or when you’re trying to VNC into, uh, systems that aren’t running RDP. Um, we also, uh, protect and authenticate to SAS applications. And then, one of the- the cool things we introduced, uh, earlier this year is service tunnels.

So, these are layer three, layer four tunnels. They can be super granular, they can be super specific to one particular user on one particular device in a certain, um, compliant state. So it’s not just everybody gets access to this stuff, it- it- it becomes super granular. Uh, and we can also inspect, uh, layer three tunnels. So if you do have somebody that’s getting a layer three, uh, tunnel, we can see where they’re going so that you can create, uh, even more granular policies. So, once we discover… Uh, once we discover resources, we give you a list. Um, you can choose to ignore some of this stuff if you already know what it is or you want to deal with it later, or you can publish it. And what publish means is you create a workflow. So, let’s- let’s take an example of that.

You- you found some… You- you found a jump box or you found a switch. Uh, and then access switch is something that only IT should be using. So once you find it, you can right click on it and say publish. Once you, uh, say publish, you start going through the access policy workflow. And what the access policy workflow is, is it’s a super flexible way for you to say, “These specific users should have access to these protected devices.” That access can be based on a user, it could be based on a group, this group could be fed in from your identity provider. So, if you’re already grouping people into, uh, like, IT finance executive or employees, third parties, um, you can create policies based on that.

It could be based on a role, and a role is something that we can define based on all sorts of perimeters. Uh, the policy could be based on device trust level and device identity, and the policy can also be based on the resource type and the resource trust level. So I’ll give you an example of resource type and different trust levels. So, um, you can have a web application, and the web application could be, um, uh, your internet site. Somebody wants to go into the internet site and see, um, what days are considered holidays. Right? It’s just something they’re gonna go and read. Uh, it’s a web application, but it’s kind of a low risk web application. Then you could also have a web application that’s… Let’s say it’s your internal CRM.

All your customer information, uh, is there. Your transactions are there, the financials are there. That should only be reserved for executives or, um, your finance team or your sales team. You don’t want engineering to be going to, you know, third parties there, so that high risk level’s going to be really high. Um, so you can create a policy based on that. So, we have templates that walk you through a lot of that stuff. Um, we have things that are permissive that just let everybody in, so if you have your internet site you can set that to permissive. And then we have the- the enforcing mode that says, “Based on all the authorization, uh, checks that I put in, only when everything is passed I will let you in.” Right? And then, policies can also be based on IPs and subnets, and we can whitelist and blacklist IPs and subnets.

So, let’s say you want people to access it, um, only when they’re on-prem. Um, we have organizations that do, uh, geolocation and they say, like, certain applications can only be reached when you’re in country. So, we can create policies, um, based on that. Uh, yeah, here’s… Uh, so that when we- we were just talking about policies based on device. Uh, in this case, we’re… We have a bunch of checks that we do, and these checks are coming from two different sources. One is the Banyan app itself. So, the Banyan app can go in and look at, um, do you have, like, auto updates enabled? Are you doing disc encryption, firewall, and things like that?

The other one is we integrate with your EDR. Um, so the EDR, like a cloud strike, will be inspecting your tra-… Your system. It’s seeing what applications are running. Is there any malware, is there a kinetic control traffic that’s running? That stuff gets fed in, and that gets calculated into your, uh, device score. Uh, and if- um, if you deem that the EDR information is, uh, highly critical. So, if the EDR finds a- uh, malware or something that’s running on your device, we can go in and we can say, uh, “Now my device score, uh, goes really low.” And then based on the policy, a low device score means you lose access to certain things.

So, we’re not like a legacy VPN where it’s very binary. Um, we can actually go and calculate scores based on, uh, however you- you deem fit, whatever the policy that you want to go deploy. And the other thing we can do is we can actually disable some of these checks, uh, so that they don’t really get enforced. So let’s say, um, you push out new firewall settings, and now, um, half of the systems… Uh, something happens. We know that, uh, these things happen when there’s, like, a major operating system upgrade. Uh, instead of, uh, not- not allowing access, we can say, “Okay, I’m gonna look into the firewall settings, but I’m not gonna enforce on it.” So that you can go and say, “I still have 10 users where their firewall would fail.”

You shoot ’em an email, or IT calls them and helps them fix their firewall settings. Uh, and then you can turn enforcement back on. So it’s really granular, um, and we do also provide custom remediation instruction so that the end user doesn’t have to call IT. We know every call to IT, uh, costs money, so we provide remediation instructions. It’s shared with the user so the user knows, “Hey, I no longer have access to some of this stuff I need.” Um, we- we tell ’em why, and then they can go in and fix whatever. It could be something like the person just, uh, disabled auto updates, and now because of that, uh, they’re losing access to some stuff.

So it’ll just tell them, “Go and enable auto update.” Uh, and then as soon as they do that, uh, our Banyan app pulls device information in real time. So, as soon as they disable auto updates, they lose access to whatever they, uh, had access to. And then as soon as they enable it, they have access again. All right, so now let’s look at… How do we enhance the end user experience? So, I talked about this decisionless, uh, access. Um, in some cases it’s decisionless, in some cases it’s minimal. Um, so like I said, uh, there’s ways for us to do, uh, access that’s proxied. So, we can proxy web applications and the end user never has to interact with our Banyan application.

Uh, when they do have to go to the Banyan application, uh, there’s only one button that says log in. They don’t have to figure out where they’re logging into, they don’t have to remember, um, where things live. So it’s really minimally… You know, a minimal amount of decisions. Um, the other thing is, we also provide a service catalog. So in the Banyan application, the user always sees what they have access to. So, they don’t have to guess, um, it makes it really simple, and from the app they can click, uh, connect. If they’re connecting to something like SSH they can, uh, click open if it’s something that’s browser based. Uh, so they- they really see everything they have access to. And as, uh, let’s say a device goes out of compliance, they lose access to certain things, that goes away from their service catalog.

Um, they can use existing fake applications. So, if your end user is used to using their RDP client, we’re not gonna tell them, like, “Hey, you need to now do an RDP search in a browser.” They can continue to use all their fake applications, including cell phone. So, the… So, the technology adapts to the user, the user isn’t asked to go and adapt to the technology. So again, it just fakes for a- a much better, uh, end user experience. And we talked about the stealth mode for web apps, this is where I have a, uh, bookmark, and I go to the bookmark and I get in. They don’t see what’s happening, but in the background what’s actually happening is the end user is being- being authenticated based on what’s a certificate. Uh, they’re being authorized, the device checks are happening, uh, all the time.

Even when an end user isn’t logged in, uh, to our Banyan app, uh, the Banyan app is still sending, uh, device posture and health and trust, uh, information back to the system. So for the end user, this makes it super easy. All right, and then let’s quickly talk about… You’re using something for identity today. Uh, you’re also probably using things like EDR, you have the CESS log, you might be archiving some of your CESS log information. So, we provide, uh, methods, uh, for you to continue to integrate into that stuff.

So for identity providers, we do SAML and OIDC, OpenID Connect. Which means if you have some of that stuff config- configured today… So, let’s say everybody logs in using Google, uh, G Suite. Right, you can continue to use all that stuff today, the end user’s not gonna see any difference. We also have APIs that we, uh, have, and these APIs can be pushed. Or, we’re pushing information into something like your SIM, or your CESS log, or your ELK stat. And then we also have pull, so we’re pulling from MDM. I need to- you know, I need to know, uh, about… Let’s say I need a country code from… For a mobile device, ’cause I have, uh, policies based on country. I can pull all that information from MDM, I can pull information from EDR so that I know what’s going on.

And that just means that, uh, we become more intelligent because we’re continuing to look at what you’ve invested in. And then we can also push information, uh, which means that all your reporting and things in your SIM and your CESS log, uh, just becomes better. So you can continue to use, uh, all your, uh, existing investment. So, once you have everything deployed, you have, um, device policies, what do you do with your legacy VPN? All right, so once you start seeing that your users are completely using Banyan’s ZTNA… Or just any ZTNA, uh, if we want to be generic. Uh, and they no longer need, uh, the VPN, you can start, um, removing the clients from the end devices.

Right? If you’ve deployed with an NDM or a unified end point manager, you can go and delete the client, you can delete the client profiles, you can delete any certificates that are specific to that client. Uh, just as- as a- as a good hygiene clean- cleanup of the end device, and again, minimize confusion. Now they don’t have that VPN, uh, client, so they’re not- they’re not gonna think about using it. Uh, and then you can power down the appliance. If you have, let’s say, 10 appliances, you can start moving, um, dev-… Access profiles to certain appliances, and then decommissioning the appliances that nobody’s pointed to anymore.

You can remove configuration from firewalls. This could be any [inaudible 00:31:08] rules you have. Uh, this could be ports that are open for those firewalls, and then if you’re using external IP addresses, you can also, um, put those back in the pool. So the Banyan connector, uh, doesn’t require any DNS updates, it doesn’t require any external firewalls. Uh, it doesn’t require any down traffic. Um, as long as, uh, there’s up out traffic, it can route out and it can do, like, DNS, uh, resolution. Uh, you should be good, so you can start… Every time you power off, uh, a VPN appliance, you can go to remove, uh, dozens of lines of configuration in your firewall.

Uh, and like I just mentioned, you can take back external IP addresses. These are getting harder and harder and more costly to get. In some cases we’ve heard of, um, uh, ISPs taking six months to get you a block of C addresses. Uh, you can put those all back in the pool and use ’em for something else, and then you can remove DNS entries. Uh, this makes the entire system actually more secure, uh, because we know people are doing DNS scraping. They’re looking at things that say remote access in VPN, and then they’re targeting those for text.

So just get rid of those, clean up your DNS entries, uh, because the Banyan connector, uh, doesn’t even need those. So, uh, again, we talk about minimizing the attack surface, and the less information I can provide to my, um… To, you know, public, uh, those are things that somebody’s not gonna use to try to attack, uh, and breach my network. So those are, um, recommendations based on, uh, the last few years of having customers move from legacy VPN to ZTNA. Uh, thank you so much, uh, for attending this webinar. Uh, if you do have any questions, please reach out to us.

If you’d like to see this stuff in action, um, we have the Banyan team edition. Uh, that’s good up to 20 users, and sometimes you have the motions and it’s been up to 50 years. You can deploy some of this stuff in less than 15 minutes, and you can start getting, uh, rid of and migrating away from your, uh, legacy VPN. And with that…

Jo:

Ashur, thank… (laughs) Ashur, thank you so much. This was super informative, I think, uh, everybody that was on the call learned a lot. I know I did. Thanks everybody for joining us and have a great day, we’ll see you soon.

Ashur Kanoon:

Thank you.

Jo:

Bye now.

Close Transcript