With the recent sudden and rushed deployment of virtual private network (VPN) services to support an onslaught of newly remote workers, many companies are discovering firsthand the nuances to VPNs that can lead to higher risk.
This article looks at those risks, moving from inside the enterprise outward, starting with impacts to the local network, overall network architecture, access control concerns, issues of scaling and load challenges, authentication concerns, and, finally, endpoint protection.
Throughout, we will identify four major risk areas: overall network architecture, access control, denial-of-service, and endpoints.
Network Architecture and Topology Concerns
Even in companies with successful VPN deployments, only a small subset of staff, such as remote salespeople and IT operations staff, use the VPN. This leads to the first immediate concern—the pool of IP addresses that VPNs use to connect users to the local network. Usually these pools are relatively small, just a few moderately sized netblocks, especially compared to the IP addresses used on the local network proper. In order to provide for nearly 100% remote workforces, companies need to assign thousands or even hundreds of thousands more IP addresses to VPN pools and, depending on their internal network topology, may have to scavenge IP addresses from former locally assigned blocks.
Secondly, while connecting to a VPN at a central company location (such as a company headquarters) may work well enough for operations staff or salespeople, shifting large populations of users who usually work in remote offices may introduce unacceptable network latency. The large jump in the number of active users will place an increased load on centralized VPN systems. Ideally, a company can provide VPN points of presence close to where staff live, leveraging existing backbone connections to the headquarters’ systems, but this is not always possible.
Finally, many network access policies assume that users are accessing corporate systems attached to the local network. Traditional network segmentation uses firewalls to prevent users on one network segment from accessing services on another. If, for example, a connection comes from a device on the subnet used for finance, then a firewall rule may block access to the servers in the human resources subnet. When all those workers are remote, coming in from a common pool of VPN-assigned IP addresses, every user appears to be on one subnet. This causes some of those access controls to fail, either restricting legitimate users from accessing necessary systems, or allowing anyone on the VPN full access to reach systems they should not have access to. If possible, configure the VPN to assign users IP pool addresses specific to their roles and needed resources. For example, have all remote developers drop into a different subnet than the accounting team. Not only does this make access control easier but it also makes internal routing to systems easier as well.
It is critically important to remember that unless you take additional steps to provide strong authentication, your employees may not be your only VPN users—opportunistic attackers may use your VPN as well.
Authentication Risks
Key to any VPN strategy is providing extremely strong authentication of any users and their devices attempting to connect. In a simplistic deployment at least, anyone able to connect and authenticate to a VPN endpoint is the same as someone walking into your headquarters and plugging in their computer. You can authenticate VPN users in a variety of ways, ranging from authenticating the username and password against Microsoft’s Active Directory or utilizing a system such as RADIUS to more complex setups, including multifactor authentication with things like client certificates or hardware tokens. Ensuring the use of strong passwords and multifactor authentication of some kind is a minimum requirement for all systems that support it. You can provide multifactor authentication through a number of mechanisms, including a mobile authenticator app, text message, hardware token, or some other system.
Companies should monitor authentication systems closely for evidence of brute force and credential stuffing attacks. Exposing a corporate login to the entire Internet is likely to draw such attacks. The threat of these attacks can include overloading the VPN servers, deliberate user account lockout, and even full network access.
If possible, deploy hardened company-provided devices to remote workers, complete with client certificates and endpoint protection. However, given the speed of deployments in the current situation, this may not be feasible. In these situations, adopt a risk-based approach: base access on role, need, and risk to key services. If a user connects using a corporate device and is coming from a known location, then grant full access. However, if the user is connecting from an unknown device, then provide limited access to only those systems the user needs to do their job. If you haven’t explored Google’s BeyondCorp zero-trust security model, now is the time. It is an excellent paradigm for these situations.
VPN Appliance Risks
Companies need to monitor the VPN appliances closely, both for CPU and memory usage as well as configuration changes and evidence of denial-of-service attacks. In these unusual times, these devices may now be the only way into the company. Companies must watch, protect, and provision these devices to withstand attack, as the alternative is turning them off. In normal times, perhaps, this might be an inconvenience; now this means the whole company could lose critical functions. Ideally, deploy VPNs in high-availability configurations for the same reason.
VPNs can handle traffic in different ways. Most provide both a split-tunnel option and a full-tunnel option. In split-tunnel configurations, only traffic destined for the corporate network is directed through the VPN. If full tunneling is enabled, all client traffic is routed through the corporate environment. This is generally accepted as the most secure deployment but obviously increases network usage of the company’s WAN links. It may also cause inappropriate traffic to flow through systems, which could violate your company’s acceptable-use policies.
Finally, it’s important to use robust encryption with the VPN. VPNs are, at their root, devices designed to prevent malicious actors from inspecting traffic on an unsecured link. To do this, they use encryption—and this encryption must be resistant to attack and free of known vulnerabilities. Even so, many VPNs provide less-than-secure ciphers for interoperability or compatibility, so take care when configuring secure defaults.
Remote Worker Bandwidth and Network Concerns
Not all workers have high-speed Internet at home. Further, as more and more of the population shelters in place, evidence shows that service providers are struggling with the increased load on their networks. VPNs are not cheap in terms of bandwidth and can be quite sensitive to network quality when it comes to performance. Tradeoffs in the specific VPN forms can be critical for delivering acceptable performance to remote users. For example, a TLS VPN uses TCP as the underlying transport and ensures data delivery, but at some performance overhead. DTLS, on the other hand, uses UDP, which provides better throughput characteristics, at the cost of some possible losses. DTLS works well for streaming media and audio but may not be the right choice for other forms of traffic. Companies may also need to limit remote workers to only those systems necessary to do their jobs and to encourage them to avoid heavy movement of data with those systems to preserve network bandwidth for others.
Endpoint Risks
As noted earlier, endpoint security is critical for securing deployments. Ideally, the devices allowed to connect to the VPNs are corporate-managed, fully patched systems, with certificates for authentication, strong passwords, and endpoint protection software installed. These can be managed remotely just as when they are on the LAN, and many VPNs offer facilities for detecting if the machines connecting to them meet specific security policies in terms of patch level or installed software.
However, in rapid deployments such as we’re currently seeing, remote worker endpoints may have to use whatever computers they have at home. These may be underpowered and unpatched older machines. Companies will have limited visibility into their configuration and no guarantees about their security. These computers may already be infected with malware, which can use the connection opportunity to a VPN to infect other machines, including critical systems within the enterprise. If the endpoint is part of a botnet or has a remote access trojan installed, attackers can use the endpoint as a pivot into the corporate network. Given what we indicated about the lack of access control in a hasty deployment, this could be disastrous. Best practice is to assume that any unknown device connecting is already breached and to institute appropriate monitoring and controls to detect any malicious activities.
Some Possible Alternatives
Depending on the access required for new remote workers, companies can reduce some of these risks by limiting access only to explicitly needed systems. For example, if the employee works mostly locally on their device and needs access to email to communicate and to send and receive files, consider providing access only to a webmail service instead of full VPN connectivity.
Remote desktops can also be a good tool, if available. Users connect to a virtual computer that is safely within the confines of the company network. This virtual desktop allows all data and apps to remain within the company network—only the visual representation is sent to the user’s screen. This means that the IT department can monitor, manage, and maintain these virtual desktops like any other computer in the corporate network.
Third-party services such as SaaS email, file sharing, chat, and especially cloud services, may be useful—quick deployment to a large user population is easier if someone else handles the registrations and provides the bandwidth and servers. While the idea of lifting and shifting whole sections of network services like file sharing, chat, email, or groupware to a cloud provider, especially in a time of enormous pressure, may seem a step too far, it may in fact be exactly the right moment to think about leveraging at least some of these services. Just be clear on your cloud strategy and understand the risks.
Final Thoughts
Widespread, quick deployments of VPNs into environments that weren’t designed for remote workers introduces new risks. Managing these risks requires a thoughtful, step-by-step approach that thoroughly assesses opening up your network to remote access. Proper configuration, intensive monitoring, tightly controlled access controls, and some creative thinking about how to deploy endpoints can go a long way toward making this less risky in the long run.
