In the new work from home paradigm, zero trust and SASE should take the place of the traditional sledgehammer VPN approach
The security world was already changing ahead of the global work from home (WFH) phenomenon. VPNs don’t go far enough for application security and delivery in connecting the modern enterprise world, which includes users, teleworkers and even IoT networks of devices.
VPNs took hold in the late 1990s to provide encrypted tunnels for all applications, looping them back to a corporate network and then out to the cloud. However, the IT world—especially workloads and applications—has vastly changed and VPNs are no longer able to keep up.
Let’s call this the VPN sledgehammer approach and it creates three definable problems:
- The VPN tunnel is a broad attack surface to both the home network and corporate network. The alternative is zero trust, least privileged access solutions. These solutions are like scalpels compared to VPN sledgehammers—precisely matching authenticated users with only the apps they have access to, reducing the attack surface.
- Speed—Most apps are better taking a direct flight with no diversion to a corporate site for a stopover. This is why Microsoft recommends not using a VPN or MPLS with Office 365. The app is already secure so, if anything, forcing the user to open a VPN only adds a potential attack surface.
- Untrusted Parties—What if the VPN user is a software developer working on software deployed in a customer network? The customer doesn’t want to open up a broad VPN for each vendor (potentially compromising its network and other vendors connected to that network). In this case, the organization would be much better served with a zero trust, least privileged access solution. This way, the partnering organization (software developer/supplier/vendor) only gets access to the specific services it needs access to—and can be further limited to specific times or locations.
How VPNs Break Down With Remote Connectivity Spikes
To further examine the problems presented in the sledgehammer VPN method above, we explain why concentrators become a bottleneck. Most enterprises still have a hub-and-spoke network. For example, their apps are hosted in both (1) a private data center and (2) a public cloud. Often, there will be one MPLS WAN link to each, and often it will be from one site—let’s say from HQ, due to the MPLS expense.
Now, with work from home, a user will need to log on to the VPN to the nearest corporate VPN concentrator. That connection then follows a spoke to HQ. From there, the connection uses the MPLS WAN links from HQ to the private data center and cloud, creating a path of:
Home -> VPN concentrator -> HQ -> Destination (private DC or public cloud)
There are clear problems here…
In the best case, VPNs are adding latency to each and every transaction. Think of the productivity inefficiency alone in this scenario.
In worst-case scenarios, we may have:
- Created a bandwidth problem on one of those links.
- Introduced security vulnerabilities (an insecure VPN backdoor, giving access to the corporate network).
- Added failure points (extra links).
And that’s a simple example, Multiply it times many data centers, clouds and users … and you see the nightmare IT is facing with the sledgehammer VPN approach.
Fortunately, IT has recently started to implement zero trust networking and SASE architectures. Fancy tech terminology aside, it eliminates insecure VPNs and results in direct routing between user/app and destination—no more extra latency and failure points, and no provisioning of concentrators or even MPLS links.