VPN vs SASE: Is VPN Going Away?

[deanwebb]

Seeing more and more on SASE vendors (Netskope, ZScaler, et al) pushing the line that the VPN needs to go away and get replaced by their product with SD-WAN.

Thoughts on that?

[kannies]

I've been working a bit around this so here's my take on it.
VPN is a perimeter based technology, and if you consume enough Zscaler content, they will convince you the perimeter is dead because the users and applications are all moving to the cloud. I kind of agree with them because if you think about it, its inefficient to backhaul your data back to your VPN concentrator only for it to go back out to the Internet again to consume the SAAS service.

Another point is VPN concentrators expose ports to the Internet. I know its secure and everything (IKE P1/2, PKI etc) but that is dependent on patching the OS against vulnerabilities and exploits. Heres an example:
https://www.fortinet.com/blog/psirt-blogs/malicious-actor-discloses-fortigate-ssl-vpn-credentials

Isn't it better not to expose the ports in the first place and instead negotiate the session though a CASB (ie; Zscaler, Netskope), therefore only permitting outbound initiated sessions through the firewall?

Then there is Zero Trust messaging which suggests we do not simply allow an authenticated VPN user access to entire network subnets, instead just give them access to the applications that are published to the users on a need to access basis.

[deanwebb]

Good points, and I'm partial to the idea of requiring everyone to go through some kind of broker to get access. Username/password + certs should not give one full run of the network.

The catch is that while the SASE vendors talk about 70million+ apps that work with their product, they don't mention the 89billion+++ apps that are homebrew affairs that have to be accessed in bypass mode. At that point, we're on a level playing field with the VPN solution and now it's a question of cost. And that's something I'm not really aware about - what are the licensing costs per person for a VPN vs per-person SASE?

And just as VPNs can have their communication chains broken, what do we do if some attacker pops a SASE client or communication flow? Same as with VPN, patch and pray that the damage wasn't too bad.

But that also brings up another thought in my mind - personal SASE. Many people subscribe to VPN services so as to mask their identity, communications, and location. Who's to say that the same couldn't be done with a consumer SASE service? Connect to an access point deliberately in another location, accept the latency, and then do whatever you want to do that you didn't want to do without that masking.

[kannies]

In terms of application support via SASE, its hard to define and guarantee all inhouse applications will work, because sure, there will be some quirks unique to specific environments. However, if as an organisation you come across issues with lack of support for certain applications with unique behavior, the level of support you purchase from the SASE provider must be enough to hold them to account so their TAC support will drive resolution. Good SLAs and good POC testing are some of the approaches I would use to mitigate this because I also share your concern.

And just as VPNs can have their communication chains broken, what do we do if some attacker pops a SASE client or communication flow? Same as with VPN, patch and pray that the damage wasn't too bad.

If the App connector that published the application to the CASB only does so via an outbound initiated SSL session, and the client connector does the same (establish SSL to the CASB), where will the attack vector be? Because no TCP/UDP ports get exposed or port forwarded. The SASE provider should use all of its capabilities to ensure an attacker does not compromise a client. This is where the other features of the SASE provider come into their own in terms of machine quarantine, posture assessment, Zero Day mitigation, TP, Sandboxing etc.

The other key is to ensure identity is not compromised, because this undermines the whole thing. So we have IdPs like Azure AD or Gemalto which take care of that with things like Multi-Factor authentication(MFA). And IDP/MFA also integrates with Remote VPN as well as SASE, but i'm finding SASE providers will prefer you integrate with a an IdP rather than an on-prem active directory/LDAP server.

[Otanx]

I have not had to deal with SASE yet. Had to look up what it was. So seems like a good topic here.

In terms of application support via SASE, its hard to define and guarantee all inhouse applications will work, because sure, there will be some quirks unique to specific environments. However, if as an organisation you come across issues with lack of support for certain applications with unique behavior, the level of support you purchase from the SASE provider must be enough to hold them to account so their TAC support will drive resolution. Good SLAs and good POC testing are some of the approaches I would use to mitigate this because I also share your concern.

So why would I want to use SASE when my VPN does work with my in house apps? Also sounds like if their product does not work with my stuff I should pay them more to make it work?

And just as VPNs can have their communication chains broken, what do we do if some attacker pops a SASE client or communication flow? Same as with VPN, patch and pray that the damage wasn't too bad.

If the App connector that published the application to the CASB only does so via an outbound initiated SSL session, and the client connector does the same (establish SSL to the CASB), where will the attack vector be? Because no TCP/UDP ports get exposed or port forwarded. The SASE provider should use all of its capabilities to ensure an attacker does not compromise a client. This is where the other features of the SASE provider come into their own in terms of machine quarantine, posture assessment, Zero Day mitigation, TP, Sandboxing etc.

How is this different than my on-prem load balancer that does auth offload and requires two factor before forwarding my users to the app? It sounds like I am just offloading that work to the SASE provider. At some point an end user has to send packets into my system. This is no different than the VPN. Somewhere is an IP listening for inbound traffic on some port.

The other key is to ensure identity is not compromised, because this undermines the whole thing. So we have IdPs like Azure AD or Gemalto which take care of that with things like Multi-Factor authentication(MFA). And IDP/MFA also integrates with Remote VPN as well as SASE, but i'm finding SASE providers will prefer you integrate with a an IdP rather than an on-prem active directory/LDAP server.

Agree with this. You have to authenticate everyone, but I don't see where doing it with an SASE is better than doing that myself.

I do think people will move to SASE over VPN, but I really don't understand it. I just put a third party in the middle of my trust chain. It used to be endpoint to my VPN then to my app. Now it is endpoint to CASB to my app.

-Otanx

[deanwebb]

On the part about a third party in the trust chain... the VPN manufacturer is as much a third party as the SASE provider, in my view. And it's a roll of the dice as to whether or not company staff / outsourcers / vendor staff will be more or less competent in managing that element. In the case of SASE, a large part of it is out-of-the-box-automated, eliminating the risk of a human making errors in those areas of deployment.

[kannies]

SASE is a bit of a marketing term and comes from Gartner. Like anything from Gartner, its quite ambiguous. In some thought camps it was perceived to be closely related to SD-WAN, but I feel it further separated itself from SD-WAN when Covid lockdowns happened and pretty much the entire corporate office workforce (certainly in my country the UK) was working from home. If your branch offices are empty, why do you need an SD-WAN (infact why do you need a WAN?).
But you still need your workforce to access its applications. As Remote VPN is tried and tested, most people used this, and the Internet became the new Corporate WAN.

But as more applications move to the Cloud & SAAS, the amount of traffic needing to traverse the VPN tunnel reduces. Think Office365, then Workday for HR stuff, Box, Salesforce etc. And then Microsoft best practice for MS Teams traffic to employ split tunneling for better performance undermines the VPN model slightly. Why not do this for your other SAAS applications for better performance also? But, that also undermines the VPN model again.
Carry on in this direction and what do you end up with? Just a handful of in-house applications in your DC that warrant the use of VPN. How financially viable will it be to keep the VPN running just for these applications? Perhaps if its for Manufacturing/Retail industry, the axe will fall in its favor. But you'll likely be considering or POC testing these applications using a SASE private access solution or at least the question will arise.

When it comes to financials, my experience so far is the premium SASE provider products (ie; Zscaler ZIA & ZPA) are expensive compared to Remote Access with central Firewall/Concentrator if comparing line item against line item. But you have to accept you generally pay a premium to have the provider host and manage the infrastructure vs using your own rack space/power etc.

I agree its an interesting area. A paradigm shift in the way we think about network security. Its a fast emerging IT strategy and will be interesting to see where it goes over the next few years. It will take a cataclysmic event to push the direction of travel the other way, (ie; a global CASB outage), then maybe we will be glad to have VPN as a backup 

[deanwebb]

Wintermute had an article on LinkedIn some time ago about everything going to the edge, routing included. This is definitely part of that trend. I know when I worked at Forescout, we were able to be 100% remote without needing a VPN, except to change our passwords or access Confluence/Jira. I'm 100% remote right now, but I have a VPN connection because I work with an on-prem lab.

[deanwebb]

There are also IPSEC and GRE components in SASE solutions, so it's not like they're 100% non-VPN... there's still a chunk of VPN inside of SASE solutions.

[Otanx]

On the part about a third party in the trust chain... the VPN manufacturer is as much a third party as the SASE provider, in my view. And it's a roll of the dice as to whether or not company staff / outsourcers / vendor staff will be more or less competent in managing that element. In the case of SASE, a large part of it is out-of-the-box-automated, eliminating the risk of a human making errors in those areas of deployment.

It isn't necessarily the hardware / software that is a concern because you can say that about any system in IT. It is more the employees of the third party that have access to those systems. We actually had an incident recently where we were troubleshooting with one of our cloud providers, and the help desk guy was able to add himself as an admin to our portal so he could see what we were looking at. That caused an uproar in our cyber department. This is more of what I am looking at for trust chain. Depending on how you authenticate that third party is a man in the middle.

SASE is a bit of a marketing term and comes from Gartner. Like anything from Gartner, its quite ambiguous.

This is probably my biggest issue with it. Lets make up new terms, and make them broad and ambiguous so everyone can say they do it. Same with SDWAN, and many other buzzwords in IT.

But as more applications move to the Cloud & SAAS, the amount of traffic needing to traverse the VPN tunnel reduces. Think Office365, then Workday for HR stuff, Box, Salesforce etc. And then Microsoft best practice for MS Teams traffic to employ split tunneling for better performance undermines the VPN model slightly. Why not do this for your other SAAS applications for better performance also? But, that also undermines the VPN model again.
Carry on in this direction and what do you end up with? Just a handful of in-house applications in your DC that warrant the use of VPN. How financially viable will it be to keep the VPN running just for these applications? Perhaps if its for Manufacturing/Retail industry, the axe will fall in its favor. But you'll likely be considering or POC testing these applications using a SASE private access solution or at least the question will arise.

So the direction we have gone is to expose our in house apps behind a MFA portal. If you connect to one of our apps you get an ugly very simple auth page. Once logged in you are sent to the app. The only reason a normal user needs VPN is for patching, monitoring, and maintenance of the laptops. We will probably find a solution for that as well, and then VPN will just be for engineers that need to fix things.

When it comes to financials, my experience so far is the premium SASE provider products (ie; Zscaler ZIA & ZPA) are expensive compared to Remote Access with central Firewall/Concentrator if comparing line item against line item. But you have to accept you generally pay a premium to have the provider host and manage the infrastructure vs using your own rack space/power etc.

In this case I can see them liking the SASE solutions because they can move all the expense to OPEX, and base it on employee count. No need to buy a VPN box that can handle 500 users when you only have 125. Company downsizes and they can immediately cut costs. So will SASE replace VPN? Probably in most instances. In all honesty I think you will see more and more in house apps going to the cloud as well anyway. Instead of some giant COBOL application it will be a docker container you can run in any of the cloud providers anyway. Then you won't even had a data center to install the VPN stuff anyway.

-Otanx