With so many variables coming into play when allowing remote access to the corporate network, there are several best practices that should be followed to elevate security.
Let’s start by putting aside exactly how much of an organizations workforce is and isn’t working remotely and zero in on the fact that, regardless of where an org is in the mix between completely being remote and everyone already returning to the office, 94% of today’s organizations allow remote access to corporate apps and assets, according to security vendor Check Point. This has the potential to create a lot of risks, so let’s spend some time looking at a few aspects of a remote worker’s connection to a corporate resource, and discuss some best practices to ensure the organization remains as secure as possible.
Assuming that some of the corporate resources exist within the organization’s internal network, it’s safe to also assume that some or all of the remote workers connect to the corporate network, which potentially puts the organization at risk based on the following three factors:
- The remote worker’s device
- The remote worker’s method of connecting to the corporate network
- The remote worker’s method of authentication
In this article, I’ll look at each one, discuss the risk they pose, and make some suggestions on how to facilitate secure remote access.
The remote worker’s device
According to the Check Point data, only 17% of organizations restrict remote access to company-managed laptops. That means that there are a ton of personal devices in use, with varying levels of security implemented – likely none of which meet corporate security standards. The operating system probably doesn’t have a hardened configuration, there’s probably no antivirus (at a minimum) – let alone a business-level endpoint protection solution, and the use of the personal device tends to put the user at ease, making them far more susceptible to social engineering-based attacks.
So, between the user and the device, what you have is a completely insecure working environment where it’s relatively easy for attackers to compromise the device – particularly when it’s a non-mobile operating system.
Securing the Device
Assuming we’re talking about personal devices here, there are only a few options organizations have. The first option is conceivable whereby the remote worker is asked to allow the organization to manage the configuration of the personal device in order to harden its configuration and possibly install some form of endpoint protection. But that’s not entirely probable. The more likely solution is to not have the worker perform their work activity (logically speaking) on the personal device but to instead remotely access an internal device and perform their work via a remote session.
The remote worker’s method of connecting to the corporate network
According to the Check Point data, 73% of remote workers connect via VPN. Using a VPN does provide some additional levels of security. For one, most VPNs require the user or the device to authenticate prior to use. Secondly, the VPN does encrypt the communication across the channel. But there’s still the issue of the (probably) insecure personal device; should a threat actor gain access to the device (waiting on the actual user to connect to the VPN) and/or the user’s credentials (through, say, a credential harvesting phishing attack and use them to authenticate through the VPN), it’s conceivable that an attacker could find themselves having access to corporate resources despite having a VPN in place.
Securing the Connection
According to IBM, the exploitation of external remote services is one of the top initial attack vectors in cyberattacks, demonstrating how imperative it is that organizations not just look for a way to securely connect the user to the corporate network but to find a method that decreases the risk introduced by the insecure device and network. VPNs are a great means of connection, but it’s likely necessary to logically connect the user remotely to an internal device where there’s no ability to introduce malware, exfiltrate data, etc. And, depending on the remote access solution used, there may be no need for the VPN at all.
The remote worker’s method of authentication
Let’s start with something we can all agree upon – username/password credentials alone most definitely aren’t enough. Any organization that uses a VPN or any other type of connectivity from a remote device to the corporate network using only standard user credentials is a cyberattack time bomb waiting to go off. VPNs can leverage multi-factor authentication, but then you’re still left with the previously mentioned problems the insecure device introduces.
Securing the Authentication
I’ve already mentioned remotely-accessed sessions as a potential solution to address the insecurities found in the device and connection, but remote access only works if the solution being used also supports multi-factor authentication at a minimum. Additional controls, such as policies that define which users or devices can utilize a remote access session – or even potentially moving towards Zero Trust Network Access – is likely necessary to ensure any remote access to the corporate network is as secure as possible and minimizes the risk of being misused as an attack vector as is possible.
Attaining True Secure Remote Access
Creating a state of secure access for remote workers isn’t just a matter of implementing some form of secure session between the worker, the corporate network, and its resources. No; secure remote access is about assessing the risk introduced by each facet of the working environment, cross-referencing the threat actions taken by cybercriminals, and finding security solutions that address both the business needs of said remote access and the security requirements established based on your risk assessment.
Secure remote access, when implemented properly, can provide remote workers with a secure and productive working environment where the organization can rest assured that despite an attacker’s best efforts, their ability to take advantage of that environment is minimized, if not mitigated.
