Zscaler Blog

Get the latest Zscaler blog updates in your inbox

News & Announcements

It’s not the printer…it’s the ink

April 06, 2017 - 5 min read

Everyone knows the adage: while printer manufacturers might make a little money on their hardware, it’s the ink that brings in the big profits. The same concept applies to razors and razorblades. And, it turns out it’s also true for something as ubiquitous and seemingly well understood as the virtual private network.

Practically every company today has a VPN, and most enterprises have many. And just like the printers and the razors, many companies may think of the VPN appliance, often included in the firewall, as representing the solution in its entirety. But even if you consider the client-side agents, you’ll still only be scratching the surface of the VPN’s reach and its costs.

Part of the problem lies in the fundamental task that VPNs were designed to perform –connecting authorized users to well-guarded networks in order to access the private, internal applications housed there. There are a number of issues packed into that statement. The first issue is getting the user to the data center that will offer the best performance. If your enterprise is operating at scale, that usually means regionally dispersed data centers. But what if a data center goes down or becomes overloaded? That requires a global server load balancer (GSLB). One could argue that the need for a GSLB is not only due to the VPN, but the fact is that regionally deployed data centers often don’t work well without them, but they certainly front the large deployments required for VPN access. And that’s not all.


The biggest issue with VPNs stems from the fact that just like any other Internet-facing device, they must be listening for an inbound request. That simple fact opens up a host of security issues. Just like any other outward-facing device, the VPN is vulnerable to Distributed Denial of Service (DDoS) attacks, so many security-minded enterprises place DDoS protection in front of the VPN. Next comes firewalls. Many enterprises sandwich their VPN between external firewalls, which take all the traffic from the Internet, and an internal firewall to manage access control lists. Then the enterprise may employ another set of load balancers for the resources themselves. 

Not only is the price tag high for this stack of devices, but there are additional considerations that must be thought through. Just like any stack of disparate appliances, each device views the world through the lens of its specific purpose. That can make service chaining extremely difficult. And each data center must be synched with all the others, multiplying the effort required to maintain a consistent user experience. And the problems only grow as your applications move to the cloud.

There are costs outside the data center as well. The operating costs for deploying and maintaining VPNs, as well as parts of the components in front of and behind them in the stack, can be considerable. Managing the access control lists in the firewalls, for example, has been difficult enough to keep enterprises from realizing the goal of network segmentation, despite acknowledging the need to do so. There are challenges on the client side, as well; in fact, much of the move from IPsec to SSL-based VPNs almost 20 years ago was driven by the difficulties that end users faced in installing and operating VPN clients. Not only was there downtime associated with getting users up and running, but there was a very real pricetag for the associated helpdesk costs. SSL VPNs solved some problems, but many enterprises have returned to a failover IPsec model to ensure application connectivity.

The largest potential costs, however, come from the security risks posed by your users themselves, who are being placed on your data center network to get application access. Most users don’t understand the implications of such access, and unless they are actually in IT, it’s not reasonable to expect that they ever will. Users will not understand, for example, the dangers posed by split tunneling; all they know is that the VPN is slow and if they can avoid using it, they will. Users do not understand, and should not be expected to understand, the ramifications of placing an infected device on an internal network. Most are completely unaware of damage that could be done if their VPN password fell into the wrong hands. The notion of lateral movement within the data center from the application users are seeking to access to other apps that are reachable has almost certainly never occurred them. The problem only multiplies when your users are actually business partners or contractors, who many need to access applications owned by a number of their customers.

Can a VPN actually be secured? Theoretically, yes, and enterprises have spent vast sums over the years attempting to do so. In practicality, however, the rise in press-worthy data breaches that can be directly traced to VPN use says no. The new Software Defined Perimeter (SDP) spec, which originated with the Department of Defense “Black Cloud” initiative and is under development by the Cloud Security Alliance, seeks to develop a usable alternative to the VPN. SDPs grant authenticated users access to authorized applications at Layer 7, instead of the Layer 3 network connection utilized by VPNs. The specification includes provisions for strong authentication and zero trust, as well as ensuring that traffic cannot move laterally from the selected apps to others in the data center.

As the specification evolves, it may appear to require that the enterprise walk away from an infrastructure investment that has already been made. Such investment may be perceived as a “sunk” cost, making a new option seem unrealistically costly. In reality, however, the price tags associated with operating VPNs is often much higher than they appear on the surface. In comparing the solutions, it may be useful to bear in mind the additional hardware required to secure what is essentially an open Internet port in the form of a VPN. Such hardware must typically be deployed in a redundant configuration for failover. Operating costs should be considered, particularly as users proliferate and applications move to the cloud. Helpdesk costs are also a factor. And, of course, as we’ve seen from many high profile cases in the last few years, the cost of a security breach given well-documented VPN vectors must be acknowledged.

In other words, it’s not just the cost of the printer; one must factor in the ongoing cost of the ink.

form submtited
Thank you for reading

Was this post useful?

dots pattern

Get the latest Zscaler blog updates in your inbox

By submitting the form, you are agreeing to our privacy policy.