By now, you’ve probably come across at least a couple articles highlighting the benefits of migrating to a zero trust (or an SDP zero-trust) architecture. These articles are correct— you should be looking to migrate to some form of zero-trust in your environment, if you aren’t already. But the reality is it takes time to plan, deploy, test, and document a zero-trust implementation, and to train your employees on how to use it.
So, while you may already be somewhere along your journey in migrating to zero-trust, you’re most likely stuck with your existing Virtual Private Network (VPN) infrastructure for a period of time. You need to secure your VPN as well as possible until the transition to zero trust is complete. But with the high number of people working from home these days, you can not afford for your VPN to go down.
The question is, how can you sufficiently secure your VPN for the time being without:
- causing disruption for your end users, or
- spending a lot of money (since you’re ultimately going to migrate away)?
This post describes one relatively simple approach you can take that your existing VPN likely already supports. We then expand on this approach with a more advanced configuration for those looking for an even higher level of security.
High-Level Threat Model
Outside of encrypting data in transit, a core goal of securing remote employee access— typically at least partially handled by your VPN— is authentication and authorization. At the highest level, this means your VPN is one of the core technologies responsible for preventing the following:
- an attacker gaining access to a resource.
- a resource being accessed from an untrusted device.
- a valid user accessing an unauthorized resource.
These attacks are usually performed after one or more of the following occurs:
- Stolen Authentication Credentials – The user’s first form of authentication is compromised. This usually translates to the user’s password but can also mean a stolen client certificate and private key.
- Stolen Device – The user’s device is physically stolen.
- Compromised Device – The user’s device has been hacked but is still in the user’s possession.
- Pivoting In Network – The user is granted access to one resource but then tries to pivot and access a different resource that isn’t permitted.
The following are security controls commonly used to thwart these attacks, although not all are necessarily employed by all VPNs:
- Multi-Factor Authentication (MFA) – Strongly authenticate the user through multiple forms (e.g., what the user knows, what the user has, what the user is, etc.).
- Device Authentication – Authenticate the device the user is using (e.g., work-issued laptop, home desktop, personal phone, etc.).
- Resource Access Control List (ACL) – A list that says which resources the user is allowed to access.
- Threat Analysis – A general term for analyzing the threat of the overall environment and the user-specific threats. Threat analysis includes, but is not limited to, analyzing user behavior patterns, geolocation, time of day, etc.
Comparing VPN To Zero Trust
Assuming a standard VPN with basic configuration (e.g., no MFA in place), the security comparison between a VPN and Zero Trust implementation is shown below:
Enhancing VPN Security
Since the VPN is only a perimeter defense, it is not practical to implement resource ACLs purely from your VPN. However, it is possible to achieve MFA, device authentication, and in an advanced case, threat analysis, through proper configuration. The obvious solution is to alter the authentication configuration of your VPN and possibly plug a third party MFA provider in. While this method will work, it is likely to be both costly and have a potential for hindering your users from accessing the network if misconfigured.
Luckily, there is another approach that is free and very likely doesn’t require any changes to your existing server-side VPN configuration because it is based on an authentication method that all (or nearly all) VPNs support: client-certificate authentication.
Client-certificate authentication on its own does not provide MFA or device authentication, but when you combine it with a secure cryptoprocessor, it can. A cryptoprocessor provides a high degree of protection (physical and logical) for the client private key. If you’re familiar with hardware security modules (HSM), it may be helpful to think of a cryptoprocessor as a miniature HSM within a physical device.
Many of the devices we use today come with these processors readily available. Modern Windows and Linux machines come with a Trusted Platform Module (TPM), newer macOS systems come with a T2 chip, and smart phones and tablets have their own versions (e.g., Android’s Hardware-backed Keystore and iPhone’s Secure Enclave).
Since the cryptoprocessor is embedded on the client device and the private key is non-exportable within the cryptoprocessor, the client private key is uniquely tied to the device. Thus, client-certificate authentication provides a form of device authentication. Furthermore, since most of these cryptoprocessors require a PIN to use the private key, MFA is achieved with the device being “something you have” and the PIN being “something you know.”
It may seem inconsistent that MFA counts as a security control against a compromised device for Zero Trust but not for VPN with a cryptoprocessor. The reason for this is that the PIN required by the cryptoprocessor is almost always static. As a result, once the device is compromised the PIN can easily be compromised and used in future attacks. This stands in contrast to other MFA techniques such as TOTP, FIDO2, etc., where compromising the device typically doesn’t compromise the MFA credentials, as they are usually non-static and generated on a separate device. Since these other techniques are more likely to be used in a Zero Trust deployment, MFA is shown as a security control under the Zero Trust column.
Even though the MFA is not as strong as more modern techniques, by simply moving the client private key into the secure cryptoprocessor, we have added real security value to our VPN infrastructure, all without having to change any server-side configuration of the VPN. As an added bonus, we have taken advantage of hardware and software that is already available on most client devices today.
However, there are certain situations where the client device may not have a hardware cryptoprocessor onboard. The two most common scenarios where there may not be a cryptoprocessor available are when the client is using a virtual machine or a legacy device.
In some cases, the virtual machine will have a virtual TPM (vTPM), which is a software cryptoprocessor that protects the keys from the guest operating systems. For clients using virtual machines that don’t have vTPM capabilities and for clients using legacy devices, external cryptoprocessors are an option. Examples of external cryptoprocessors include smart cards and security keys. While these external devices are not free, they are generally considered to be affordable and have some additional security benefits.
Advanced Configuration
For additional security, the deployment model described above can be advanced by storing the client private keys in a centrally-managed hardware security module (HSM). Then, by way of a secure HSM-proxy like GaraSign, end-users get proxied access to their client-certificate authentication keys, instead of having direct possession of them.
Since GaraSign supports very advanced authentication including (non-static) MFA, device authentication, approval workflows, behavior analysis, and more, your VPN automatically reaps the security benefits without any change to your VPN configuration.
If your company hasn’t yet started or completed its transition to zero trust and you’d like some assistance in enhancing the security of your VPN, the Garantir team can help. Get in touch with our professional services team to help d shore up your VPN’s security while you migrate to zero trust.
If you’d like to maximize security throughout your environment, storing private keys in your company’s HSMs is essential. HSMs provide a superior level of security that should be taken advantage of at every opportunity. GaraSign helps you do just that by providing fast, proxied key access to all end-users and providing a plethora of native client integrations that ensures GaraSign will fit directly into your environment without any major adjustments.
Contact the Garantir team to set up a demo or schedule a proof of concept.
