For many employees, the morning work routine looks a lot different than it used to. Instead of heading to the office, they make their coffee, “commute” to their home workspace and connect to a Virtual Private Network (VPN) to access corporate resources and applications.
The VPN is one of the most time-tested, albeit a bit risky, solution out there for secure remote access. I call it risky because, if not properly implemented and maintained, attackers might be able to exploit weaknesses to gain privileged access to sensitive systems and data. In fact, some organizations are opting for new ways to connect their remote workforces that eliminate the need for VPNs or agents and help streamline operations and user workflows.
For organizations using VPNs, it’s important that the VPN stack is properly patched, using the right encryption, and continuously monitoring traffic patterns and usage. Even more important is working to ensure that users logging on to the VPN are verified to a high degree of assurance, the devices are validated and related privileges and entitlements are in line with the principle of least privilege…isn’t this sounding like the founding principles of Zero Trust security?
Let’s examine five best practices for implementing VPN in the context of these three pillars of Zero Trust security.
Rule # 1: Verifying Users: Make sure the VPN solution supports Multi-factor Authentication (MFA) through RADIUS and/or SAML.
Most VPN solutions support different types of authentication mechanisms, depending on the type of VPN (site-to-site, remote user). One type that supports MFA is the use of RADIUS, in which the VPN server becomes a RADIUS client to a RADIUS server, which in turn is able to perform a Multi-factor Authentication. For example, CyberArk Idaptive connector software can serve as a RADIUS server as well as an AD proxy to perform the AD authentication as well as present a second factor in the form of a mobile authenticator, OATH OTP, email, for the second factor.
The following figure shows the various steps involved in the RADIUS-based authentication between the RADIUS client and CyberArk Idaptive Connector, which serves as the RADIUS server (among other things).
Another way to integrate a VPN with an external IDP for authentication is through SAML. This is not supported by all the VPN vendors out there, but if supported, then there is no need to install a desktop VPN client on the endpoints. Below is an illustration on how this works with Palo Alto Network’s Global Protect solution.
So, as you are looking for a VPN solution ask yourself the questions:
- Does it support MFA?
- Does the solution require a VPN client to be installed on the endpoints? If so, which authentication mechanisms is it able to support? For example, some mechanisms are pushed directly to the authentication provider (AP) for verification from the mechanism, and some require the end-user to interact with the VPN client to enter a code (e.g. OATH OTP code), which is then sent to the AP for verification.
- Does the solution support a client-less VPN authentication mechanism such as SAML? This is especially convenient since then the IT administrator does not have to ensure that each client is installed with the right version of the client and thus is able to embrace a wider range of endpoints in a secure fashion. Some clients (Cisco’s Anyconnect is an example) do have support for embedded browsers, which can then support SAML.
Rule # 2: Limiting Access: Make sure the RADIUS server is able work with specific attributes to limit access and authorization.
The vendor-specific attributes are necessary if you want to give users permission for more than one type of access. For example, based on the user role, the user may be granted a particular privilege level, thereby limiting access. The VSAs may be used in combination with RADIUS-defined attributes. For example, this link shows Ciscos’s VSAs.
Rule # 3: Verifying Users: The authentication provider (CyberArk Idaptive in our case) solution is able to support a heterogenous VPN environment.
Many a time an organization may have multiple VPN vendors with a mix of protocol support for authentication and access control. The RADIUS server/IDP must be able to support different authentication profiles, for instance, for the different VPN servers (RADIUS clients). For example, if more sensitive types of resources are accessed from one VPN server then an authentication profile with stronger authentication can be applied vs. that for a different VPN server fronting less critical resources.
Rule # 4: Intelligently Limit Access: IDP solution is able to offer an adaptive, risk aware, solution.
Even for a single VPN server, the authentication provider must be able to provide a way to detect user behavioral anomalies and present different challenges based on the user’s risk. This is especially critical in the current scenario where most, if not all, workers are going to be remote for the foreseeable future.
Rule #5: Validating Device: The endpoint itself is protected by MFA and Conditional Access.
With users being remote, and possibly also using their own devices (BYOD), it is important to only grant access to those devices with users who were verified by MFA as part of logging into the device itself.
For more information on securing your remote workforce, visit our Risk Distancing Resource Center.
