Provide redundancy, because everything, including VPNs, can break. If your organization will rely on your VPN for remote access, encrypting and securing data, or providing a business partner access to your extranet, you will find out quickly how critical your VPN is—on the day that it breaks. Most commercial VPN products offer a failover or load-balancing capability so that in the event one device fails, the other will pick up the traffic.

Often, VPNs are provided via a cloud implementation. In this case, be sure that a level of redundancy is built in and that the redundancy is clearly spelled out, and guaranteed, in the contract or service level agreement (SLA); it will otherwise be out of your direct control. Although passing the burden for security in a cloud implementation may seem efficient, if the service provider does not actually provide the level of service and expertise needed, it can be disastrous. Corporate legal counsel should review all SLAs with the IT management and administrative staff to ensure that what is promised is the level of support required.

Alternatively, keep a spare VPN product on your shelf, configured and ready to go live in the event of a failure. Generally, waiting for tech support or ordering a spare part can take more time than your organization is willing to wait for restored service. This level of redundancy and preparedness is often referred to in the corporate disaster recovery plan. You will learn more about this later in the chapter.

Choosing the right VPN product is critical to the long-term success of your VPN deployment. Take your time, document your requirements, carefully evaluate the capabilities of each VPN product you review, check with peers if available, and review appropriate industry literature. A security magazine review of VPN products is a valuable tool for starting your search—or even narrowing the field once you have your requirements documented—but do not select your solution based solely on which product won last year’s Editor’s Choice award from your favorite industry magazine. The editors and reviewers at most industry magazines, websites, and blogs are technically capable and spend a lot of time looking at products, but they do not have to support the product in your environment. Ultimately, you will be responsible for meeting your organization’s requirements and maintaining support.

Avoid purchasing products based on promises rather than proven capabilities. Slideware, also sometimes known as vaporware, is any product that appears in a vendor’s PowerPoint presentation but is not yet available for sale. When possible, road-test a product in your environment before purchasing. It is always a good idea to see what a product can do firsthand.

Finally, when looking for a product, consider using resellers and consultants. A good reseller can do some of the legwork for you by narrowing the search to a smaller pool of products. Although some resellers work much like a standard department store, selling whatever is on the shelves, many will go the extra mile to ensure that you get a product that will work in your environment. This saves them the challenge of trying to support a poor product after they have sold it; if you like the solution, resellers have the opportunity to sell you additional products in the future.

A VPN policy (often referred to as a remote access policy) documents your organization’s rules for using the VPN. You will read about creating a VPN policy at length later in this chapter. Recognize, however, that proper policy framework is a key best practice when dealing with security technologies, especially those offering remote access to your computing environment.

Split tunneling is a configuration setting that allows simultaneous access to both an untrusted network (like a home network) and a secured VPN network connection. This may not sound like a bad idea at first—after all, why wouldn’t you want someone connected to the VPN to access the Internet or their home network (or another network) at the same time? The reason split tunneling is a bad idea is that it potentially opens a door into your network that you cannot control. This is known as hairpinning, because malicious code can enter from the nonsecure network, make a hairpin (or sharp) turn, and enter your secure network with little or no trouble because it is entering from a secure and verified endpoint.

If the client machine is compromised by a virus that permits remote control of the system by an attacker, and that client machine connects to the VPN, the attacker will have access to your internal network from anywhere on the Internet. If you prohibit split tunneling, however, then even if the attacker can compromise the client, the external connections terminate as soon as the VPN connects, ensuring that your network is secure (even if the client is not).

For the most part, VPN technology is both mature and secure. VPNs are subject to denial of service (DoS) attacks, but VPN servers are rarely hacked. In October 2019, the private VPN provider NordVPN confirmed rumors that it had suffered a hack. The vulnerability was due to the expiration of the internal private key, leaving the connection susceptible to spoofing by hackers spinning up their own servers to pretend to be NordVPN servers. Nevertheless, VPNs remain a viable vector for someone who wants to attack your network. The target of these attacks is typically the weakest link of the VPN chain—the client system.

One of the challenges of working with remote access VPNs is making sure that the client at the other end of the connection is secure. Remote access VPNs permit access to a secure network from a remote location across an untrustworthy network. If the client system is not secure, you run the risk of compromising your secure network. A typical VPN client runs an operating system (OS) that needs patching at least once a month; runs applications that may need patching almost as often; and is vulnerable to viruses, spyware, and other attacks. Be sure to install antivirus software, anti-malware software, and a software firewall on every client that will connect to your network through the VPN.

One school of thought is: If it does not belong to the company, it should not connect to the company’s network. Fortunately, you have some control over your organization’s computers. You can require antivirus, anti-malware, intrusion detection systems (IDSs), and firewall software on any computers your company owns. For systems not owned by the organization, you can require that the equipment meet specific security standards, including running an antivirus test prior to allowing access. This is a complicated process and may be beyond the scope of some system administrators. As a result, if you do not prohibit noncompany systems from connecting to the network, you cannot control whether those systems are secure; that is, you cannot ensure that your network remains secure. It is very easy for an end user to load a VPN client on a home PC and connect to your network. Although some VPN solutions offer techniques to prevent uncontrolled systems from successfully connecting, it is important that you lay the groundwork by prohibiting the practice.

This is a problem that must be dealt with if the organization has a Bring Your Own Device (BYOD) policy and a virtual private network. How should BYO devices be admitted to the VPN, and what are the policy and technical guidelines for connection? How much security is the organization willing to give up to gain the financial and operational benefits of BYOD? In many cases, cloud-based providers will offer support for a wider variety of client OS types and versions than a traditional VPN product. Maybe it is time to consider a cloud-based solution. These are all factors your organization must consider when considering your VPN and the security, or insecurity, of your information.

Effective vulnerability management can help manage your remote clients. These are the technology and business processes used to identify, track, and mitigate known weaknesses on hosts or applications within a computing environment.

Remember, everything is vulnerable to attack. UNIX, Windows, routers, network printers—and even your VPN solution—will have vulnerabilities. Examples of vulnerabilities include software coding errors, improper configurations, and poor password choices. The danger with a VPN is that it expands your network from systems you can closely control to include systems in a home office, a branch office, a hotel, a coffee shop, or even a business partner’s network.

Vulnerability management is a combination of tools and processes that allow you to reduce risk in your computing environment, including VPN-connected systems and networks. Use tools that periodically test your environment, including the VPN systems, for missing patches, configuration issues, known exploits, and other vulnerabilities. This will ensure that your remote systems as well as your local systems are secure. Scan often and address issues when found.

Your VPN is only as secure as your authentication method. One of the easiest ways to compromise a VPN is by compromising the authentication credentials. All it takes is one user with a password of “password” to open a direct connection to your network. A best practice is to use multifactor authentication for VPN access. This is a method of proving identity using several different authentication factors. Authentication factors are something you know, something you have, or something you are. Examples include a smart card (something you have) with a PIN (something you know); a biometric device (something you are) coupled with a password (something you know); or a proximity card (something you have) that activates a fingerprint reader (something you are). The most common form of multifactor authentication is two-factor authentication, which uses two authenticators (most commonly the user ID/password and a texted number or code to be entered). Each additional factor added increases the security exponentially but also increases cost and complexity.

If you fail to plan, you plan to fail. Document your implementation plan. You cannot simply find an open rack in the data center, run a cable, plug in a device, and keep your fingers crossed that it will work. Document your implementation and support plans. You will learn more about this later in the chapter.

Monitoring the availability of the VPN can save time and aggravation. The typical (and worst) method to discover issues with your VPN is when users start calling for help. This can be particularly challenging when the callers include members of your organization’s senior management team. A corollary of Murphy’s Law may be, “The likelihood that a senior management team member will try to access the network over the VPN is directly proportional to the likelihood that the VPN will fail.” It is far better to alert senior management to temporary problems than for them to tell you that something is not working. Because VPNs are network components, you can generally use the same monitoring equipment that you use to monitor routers, switches, and other network gear.

Once you have your VPN deployed, review usage regularly. If you notice there are employees who do not use the VPN, you may want to remove their access. If you see employees who have multiple concurrent connections, you may have a security issue and should investigate further. Suspend access for anyone who will be unavailable or not allowed to access the VPN due to corporate travel outside the country or vacation.

Back up your VPN configuration regularly. This is a good practice for any network equipment, but in the event that your VPN hardware fails and needs replacement, you will need to be able to restore your last known working configuration quickly. Rebuilding a VPN configuration from the default settings can be a long and challenging task—not to mention making post-incident review meetings an unpleasant experience.

Patch regularly. Vendors typically release patches and updates to VPN code throughout the life of the product. These patches address security issues, fix bugs, or provide additional functionality. In an ideal environment, you will have a development VPN that you can use to test patches and updates. In most environments, however, you will not have the luxury of a development VPN and will have to test when you implement in production. In either circumstance, work closely with your vendor to make sure that you receive prompt notice of patches and updates. Establish an operational process and maintenance window to apply patches and updates in a timely fashion.

Your VPN solution may end up being a critical component of the organization’s business-continuity planning and disaster-recovery planning. In the event of an incident that prevents employees from getting to their work location, a VPN that provides work-from-home support is a key component of many recovery plans. Events such as earthquakes, snowstorms, tornadoes, floods, pandemics, and other natural disasters can make working remotely a viable alternative to standard operations.

This collection of VPN management best practices is meant to serve as the starting point for your successful VPN deployment. It is not meant to be comprehensive, but instead to offer some common practices and processes to help you with your VPN deployment. Depending on your VPN solution—as well as your environment, business requirements, and experiences—you may use every one of these suggestions or only a few of them. The key is to ensure that you are doing what works in your environment. If you need help, do not be afraid to reach out to your peers for advice and suggestions. Over time, you will develop your own set of best practices as you gain more experience as a security practitioner, and soon others may be asking you for advice.