Frankly Speaking 7/19/22 - Companies should stop using VPNs!

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

I’m coming back from vacation, so this article should be a bit more coherent than others since I’m more mentally rested :). Anyway, I’m starting to go to more local events and dinners to meet up with other security professionals. If there are any cool events, let me know! I would also love an invite!

LET’S BE FRANK

This week’s newsletter is going to talk about everyone’s favorite topic: VPNs. I feel like it’s one of those things where people want to get rid of it but never do. It’s never clear to me why. I wonder if they feel like it gives them a (false) sense of security. Security teams like it because they need something to do. It’s just a burden on infrastructure teams, to be honest. I’ve talked about how network security is dead in the past, and VPNs should honestly die with it.

Anyway, in this post, I’m going to cover the following:

• Why VPNs are an outdated technology

• Some potential solutions

• Benefits of those solutions

I honestly think this is probably one of my least controversial posts in recent history. Maybe, the solutions are hot takes, but getting rid of a VPN should be a no-brainer.

VPNs maybe made sense back in the day when everyone went into the office. Everyone had desktops, and there was a corporate network. There were no SaaS apps, just internal apps, and apps installed in datacenters. Everything was centralized in a set of datacenters, like a castle with a moat where the moat was the corporate network. Once in a while, someone would need to access the corporate network, or maybe an important engineer was on vacation and needed to be pulled into an emergency. However, times have changed…

Most companies don’t even build their own internal applications or have any installed in their data centers (for those that still even have data centers). Now, most important applications like email, video conferences, payroll, etc. are now SaaS, and they usually people access them through some SSO, e.g. Okta, or use the login/password and MFA provided by the SaaS provider. The perimeter is even blurred when you use cloud infrastructure, such as AWS and Azure, because you don’t control it directly.

In my mind, VPNs have two real purposes: to provide anonymity and allow access to a private network. The first purpose is not relevant to a company because it’s important for them to know your identity so that the company can ensure you have the proper access. The second reason only makes sense if you don’t have complicated permissions or have strong application-level access control. The reason is that VPNs are an all-or-nothing type of access, i.e. you can either access the VPN or not. Once you have access, the VPN allows you to access the whole private network. It’s possible to put in more fine-grained access control, but that’s not available “out of the box” for the VPN.

Moreover, most VPNs require a client. These clients and their certificates are painful for IT to keep up to date. Many times, they require forced updates, and there is always the worry that someone will down the wrong certificates. It’s a huge pain and another moving part that opens another attack vector for bad actors.

Finally, it’s well-known that VPNs don’t perform or scale well. The reason is that they weren’t designed for regular usage! As I described above, they were meant for occasional usage in a tightly regulated corporate environment. Environments like this still exist, and it probably doesn’t make sense for the organization to change this unless they plan to undergo a digital transformation and/or shift toward more remote and hybrid work. If they do, the VPN will not scale and end up being costly.

So what are some solutions? Well, a company can always ask everyone to go back into the office and go back to the way things were before. However, as we learned from the pandemic, the companies that underwent digital transformation had more robust businesses that were lower in cost. It’s clear even if we were to “go back,” many companies’ infrastructure will not go back. They will go toward the cloud, and as part of that journey, many companies will first go toward SaaS, which will reduce the number of applications behind the VPN.

At the start, it might make sense to keep the VPN since the load will be reduced, and as employees go back into the office, this might still work. However, if a company wants to go into hybrid and remote work, VPNs will not scale. Moreover, as the company moves toward a more zero-trust architecture where they realize having their own datacenters and a corporate perimeter is not strategic, the VPN doesn’t make any sense.

It’s complicated to set up private networks, so it’s better to just assume that all traffic is malicious in a cloud and SaaS environment. This means that VPN traffic is just as much of a threat as regular internet traffic. However, a company might still want to maintain some access control. There are two main ways to do this in a zero-trust environment.

You can use a zero-trust reverse proxy, e.g. Cloudflare Access, Netskope Private Access, or Zscaler Private Access, to check for device posture and identity before allowing access. This works if you have an on-premise private network, public cloud, or SaaS. It allows for more granular access control, and most of these tools don’t require a client. They can handle large amounts of transactions and can provide you additional benefits, such as making it easier for you to segment users. Unfortunately, some of these products require the installation of a client, but these clients are a lot lighter weight and easier to manage than traditional VPN clients.

The real question is why bother keeping internal/private applications in a private network. If you are assuming a zero-trust environment, why not expose your internal application to the internet? Web application firewalls and application load balancers have become widespread and sophisticated enough to prevent unwanted traffic from passing through. To manage access, just require an IdP session, like Okta, from your application load balancer. You can have granular access by setting application-specific access with your IdP or another mechanism to relate SSO groups to application access. This makes all your applications easier to inventory, and you don’t have to worry about “accidentally” exposing your application to the internet because well… it’ll already be exposed. When an application existed internally, it already required a session, such as VPN, which was probably authenticated using some IdP. This isn’t that different. This requires more engineering and DevOps work to implement, so my impression is that many companies don’t want to do this because it requires the transference of ownership from IT to DevOps.

We should be getting rid of VPNs. They are an outdated technology that reduces engineering velocity and doesn’t align with modern tech stacks.

Some open questions in my mind:

• I described an approach that proposes to expose all applications publicly. Does that scale when an organization has a ton of internal applications? What breaks down? Will it break down the IdP or application load balancer? Is it better to use a VPN in that case?

• Will organizations have to shift ownership of applications and their security when VPNs go away? How will that change the organizational structure?

• Does this give an opportunity for IdPs, such as Okta, to expand into application management more aggressively?