Once upon a time, virtual private networks (VPNs) were king in the world of remote security. Road warriors and remote workers alike would all start their workday by logging into the company network via a VPN. Many of us used our RSA Hard Tokens (think USB Keys with a tiny LCD Screen of ever-changing numbers) for authentication. We patiently waited for the VPN client to connect while sitting in airports and train terminals so our email would sync and we could grab the latest copy of the presentation we were supposed to be pitching to clients later that same day. And on another level, VPNs were also used to connect company sites into one giant seamless network. Users at corporate headquarters could easily access resources at remote sites, and vice versa. All was right in the world.
But now, many would have you believe the kings have been dethroned and a new ruler sits atop the ivory tower. It’s cloaked in secrecy and goes by many different names, including zero trust network access (ZTNA), secure access service edge (SASE), software defined perimeter (SDP), and many more. The networking experts will quickly point out that that technically ZTNA and SDP are components of SASE. But, for the purposes of this primer, it’s sufficient to say that they are closely related to each other and work very differently than a VPN. So, is the VPN really dead? And if so, why? Or is this just vendor marketing hype from snake oil salesmen trying to hawk their wares amidst a myriad of confusing and conflicting cyber security news?
To unravel the truth, let’s first understand what a VPN is and why they were (are?) so important in the world of security. A VPN is a novel way to securely connect two remote points across an untrusted public network, usually the public Internet. The security inherent in a VPN is used to create a virtual encrypted tunnel between the two points, preventing spying eyes from monitoring the network traffic flowing between the two locations. These two points could be the remote user and a corporate data center, or they could be two remote company sites. In some cases, there might be a third-party VPN server between the user and the desired destination. But in all cases, the traffic is encrypted, to protect it from unauthorized access. What’s important to understand is that this private encrypted tunnel is especially useful for businesses. It means they do not have to build dedicated and expensive hard line circuits between two points to provide a secure connection. This is particularly cost effective for two geographically distant sites such as New York and Los Angeles. It is even more effective factoring in the globalization of large companies. It is impractical to buy or lease a dedicated line between sites such as Tokyo and Paris, for example. But the VPN smashed these distance and economic barriers, such that even the smallest of companies could now afford to have remote sites without compromising data privacy or security requirements. What’s more, VPNs also offered disparate groups of remote users low-cost access to company networks to utilize internal company applications and services.
It’s important to understand, there are two different types of VPNs, Secure Sockets Layer (SSL) and Internet Protocol Security (IPSec). They operate at different levels of the network tech stack, commonly defined by the Open Systems Interconnection (OSI) network model. Demystifying the OSI model is beyond the scope of this article. But it nicely defines how a network operates at a conceptual level. In the OSI there are seven layers, ordered and numbered from bottom to top. The hardware is at the bottom and network aware applications are at the top. Various protocols and translations lie in between to ensure interconnection between systems and provide the ability to move data from the hardware into the operating system and up to individual applications.
SSL VPNs operate at the top of the OSI network stack, at the application layer (layer seven). With the advent of Transport Layer Security (TLS), some experts will argue that SSL VPNs now technically operate at or between layer six, presentation, in the OSI model. Keeping in mind, it’s a conceptual model. For primer purposes, just understand the SSL VPN is near the top of the stack. This means it’s primarily intended for application-to-application access. This might be from your web browser to a specific application or point on the private network. SSL VPNs are not well suited for handling low level network traffic because they operate so high on the stack. IPSec VPNS operate lower in the network stack at layer three (the network layer) of the OSI model. This makes them more suitable to handle a variety of types of network traffic and protocols. For many companies, users will leverage SSL VPNs for remote access, while the network gurus will use IPSec vpns to connect remote company sites. To a user, either remote or at any company site, it feels like one big network. Everyone has the ability to access any application from anywhere, whether sitting at a company site or working remotely.
So far, VPNs sound like a great solution to solve complex real-world problems associated with globalization and remote work forces. And this big single network sounds great too. So why all the negativity about VPNs? What changed to make the security community sour on them? In a word, the cloud.
With the advent of cloud computing, companies no longer need to maintain large data centers with big network pipes at company sites. Many apps have moved from on premise (on prem) data centers to the cloud. This has greatly altered the flow of network traffic. Before the cloud, remote users would use the public Internet to connect to the company network, and leverage on prem applications. This flow was pretty efficient, since apps were housed on the company network. But under the cloud model, user traffic is coming in through the Internet via VPN, only to turn around and go right back out to the public Internet and access a cloud hosted or Software as a Service (SaaS) application. This makes it very inefficient for the user. Traffic can be slow because of the unnecessary long traversal time, creating a poor user experience. It would be much more efficient for the user to go directly to the cloud application over the Internet, cutting the traversal in half or more in most cases. Ok, so it’s clear the SSL VPN model may not be the best anymore when applications are hosted all over the public Internet. But what about site-to-site connectivity with IPSec VPNs? Don’t companies still have remote sites that need to talk to each other? The simple answer here is yes. But what’s changed here is the increased need for security.
Increasingly, threats like ransomware put the company at risk by trying to move laterally through the company network. Remember the earlier discussion where we said VPNs make the company look like one really big network? Turns out this can be a field day for malware, ransomware and malicious actors. Once they compromise a single system, either remotely connected through SSL VPN, or on prem, they can begin to move throughout the network, and across VPN tunnels to reach other segments of the company and infect far distant assets.
The zero trust model is different. It assumes that no devices or users can be trusted. This is true for remote users and on-site users. It’s also true for both cloud hosted servers and applications as well as on prem servers and data centers. Zero trust requires very granular access policies to be defined between users and specific applications. In addition, zero trust leverages frequent verification of the user and allowed access. It also relies heavily on network segmentation, where systems must be explicitly allowed to talk to each other, and only for the necessary services required for applications to function. For example, under zero trust, user Sarah may be granted access to remotely access the finance application, which is a web application hosted on prem. In turn, the finance application web server may need granular access to its database server. Sarah can’t access the database server directly, thanks to network segmentation. Only the finance web server can talk to the database server, and only on specific network ports, using predefined protocols.
Because a zero trust model is essentially a deny all default policy, it requires a significant amount of planning, oversight, and administration. Many rules may need to be defined to grant the necessary access to specific users in order for them to do their jobs or for specific servers or applications to be able to talk to each other and share data for legitimate business purposes. This is where zero trust technologies are struggling. Although companies like ZScaler claim widespread adoption in their recent whitepaper, management of all the necessary access has quickly become a burden. As such, according to Gartner, only about 1% of companies adopting the zero trust model are actually fully implemented today. As these tools mature, it is expected that this will become easier, and the user experience will improve. But for now, the transition away from VPNs has been fairly bumpy for most.
For this reason, companies should not plan a big bang approach to move away from VPNs and into a zero trust model. A rapid-fire approach will almost assuredly guarantee a poor user experience and a high degree of application availability issues due to the large number of access rules that will inevitably be missed in the haste to get the solution up and running quickly. Watch for more about zero trust and the migration journey in future posts from Black Kilt Security.
In conclusion, VPNs are indeed going the way of the horse and buggy. They are rapidly being displaced by the young upstart technology called zero trust. Zero trust is still relatively new, and is likely to have some growing pains for a while, though for business owners, IT leaders, and network administrators, if you are still relying on VPN technologies, it may be time to rethink that strategy. Although the administration burden may climb, if planned and implemented correctly, the user experience, productivity, and security gains could far outweigh the drawbacks.
