Have a remote access policy

The foundation of any remote access implementation is a comprehensive remote access policy. The policy should define the high-level requirements governing secure remote access, including acceptable use, and specify the potential consequences of violating any of those requirements. The policy should address the following topics, at minimum:

• The forms of remote access that the organization allows, such as VPNs.
• The types of devices that can use each remote access form -- for example, organization-issued laptops versus personally owned smartphones -- and any other requirements those devices must meet.
• The types of resources that can be used through remote access, with any limitations for particular remote access forms or device types.
• Any requirements for acceptable use of remote access technologies that are not already addressed in the organization's acceptable use policy.

Provide organization-issued devices for remote users whenever feasible

For years, BYOD -- where users brought their own computers and mobile devices to access the organization's resources -- was a huge trend. BYOD enabled telework for many users, but endpoint security suffered as a result. The organization could strictly control the security posture of its own devices, but had limited ability to control or even monitor the security of personally owned devices and other types of BYOD.

To avoid this gap in security, equip remote users with company devices whenever feasible. This should include contractors and, in some cases, business partners and vendors. Eliminate or strictly limit BYOD to users who need only access to low-risk, publicly accessible resources.

Require use of a remote access server for internal resources

VPNs have anchored remote access servers for decades. A VPN provides a single, well-secured and monitored point of entry that enforces security policies on the users and devices attempting to use it.

Most VPN technologies provide a range of cybersecurity features, from authenticating users and devices to assessing device security posture before permitting access to internal resources. This is highly convenient for both users and administrators. The alternative would be for users to access each internal resource directly and separately, with administrators having to manage and monitor every step in the process.

In recent years, VPN alternatives have emerged, including secure access service edge (SASE) and zero-trust network access (ZTNA). Most organizations need at least one of these remote access technologies implemented to safeguard access to internal resources. Using a single VPN, SASE or ZTNA instance to access all resources can be complicated because many resources are cloud-based and publicly accessible. A common example is using SaaS to host email services. If an employee only needs to access email remotely, forcing them to connect through an appliance at headquarters might be cumbersome and inefficient. Alternatives are to permit direct access to low-risk cloud-based resources or to use cloud-based remote access services in conjunction with, or instead of, on-premises remote access appliances and software.

Perform cyber health checks on user endpoints

One of the biggest risks posed by remote access is compromised user devices. Once exploited, these devices provide attackers with direct access to and control over the organization's internal networks and systems.

To combat this, check users' endpoints for any compromises before they are permitted to use internal resources. VPN, SASE and ZTNA automatically perform cyber health checks on organization-issued devices and, to a lesser extent, on some BYOD devices.

Cyber health checks should assess the following, depending on the endpoint's OS:

• If the endpoint is controlled by the organization or is approved for BYOD use.
• If the OS is up to date.
• If antimalware software is running and is up to date.

• If any other required security tools or configurations, such as host-based firewall rules, are enabled and properly configured.
• That there are no signs of malware, exploit kits or other attack tools on the endpoint.

Require MFA

Passwords alone are highly risky. An attacker can acquire a password through social engineering, phishing, guessing, performing brute-force attacks or reusing a compromised password from another account of the same user. Without verifying a second authentication factor that is not also "something you know," attackers who know any user's password could easily jump into the organization's internal network.

Require MFA for remote access to internal resources and, if feasible, require it for remote access to public-facing resources. MFA, especially when linked to single sign-on, simplifies the authentication process for users while also providing a much higher level of assurance that the user is who they claim to be. MFA doesn't have to include a password, and most users will be thrilled to reduce or minimize their use and management of passwords.

Encrypt all network communications from end to end

All remote access network traffic should be encrypted from end to end. VPN, SASE and ZTNA remote access technologies safeguard the confidentiality and integrity of network traffic transmitted between their platforms and user endpoints. Yet, these platforms don't necessarily protect the network traffic as it passes between remote access technologies and the systems and networks behind those frameworks.

Review network traffic flows associated with remote access, identify any communications passing unencrypted and determine which of those communications need protection. Ensure the necessary protection is put into place. This is most applicable to VPNs, which rarely extend protection past the VPN server itself. There are many options, including using proxy servers, to encrypt traffic between the VPN and internal resources, and encrypting internal network segments at a low level to perhaps eliminate the need for higher-level encryption.

Consider implementing a zero-trust architecture

Zero-trust architecture is the principle of restricting access as tightly as possible. As the name implies, zero trust verifies that people and devices are trustworthy instead of assuming they are.

Zero-trust architecture involves numerous technologies working closely together to enforce zero trust throughout the entire enterprise. ZTNA, although not required for a zero-trust architecture, is a helpful component, but many other pieces are also needed -- and they must be integrated and configured properly.

Transitioning to a zero-trust architecture generally takes years of planning and component rollouts before the entire architecture can be fully integrated and all policies enforced. Organizations considering using a zero-trust architecture to secure their remote access need to use other means to secure the remote access until the zero-trust architecture is completely deployed and operating in production.

Train all remote access users on secure remote access practices

Educate all remote access users about the importance of remote access security to reduce the likelihood of actions that could compromise the organization. Retrain users as remote access technologies and practices change. Offer periodic refreshers even when practices haven't changed substantially.

User training is not just for employees; it's also vital for contractors, business partners, vendors and anyone else who uses the organization's remote access technologies. Training should cover both physical and technical security practices. For example, advise users to never leave unlocked devices unattended in public areas, to deactivate personal assistants like Alexa and Siri during sensitive meetings and calls, and to never permit any household member to use the organization-issued computer or mobile device.

Restrict who can use remote access

It's generally not prudent to automatically give everyone in the organization remote access. Unless remote access is truly needed, making it available to extra people increases the risk without providing a benefit.

Only provide remote access to those users who need it to perform their duties, and only do so after they have been trained on secure remote access practices and have read and signed the organization's remote access policy.

If possible, assign a separate user account to each person instead of permitting shared remote access accounts. This could be particularly challenging for vendors and other third parties that need remote access but don't have a specific person or small group performing those tasks. Having a separate account for each person increases accountability.

Revoke remote access once it is no longer needed, especially if someone leaving the organization is under negative circumstances, such as termination for cause. Remote access is sometimes misused by disgruntled users after they leave the organization to exfiltrate data, damage resources and cause outages, among other consequences.

Continuously monitor all remote access activity

It doesn't matter if an organization adopts these secure remote best practices if it doesn't also continuously monitor all remote access servers and all the activity involving those servers. Because these servers are key entry points into the organization, they are obvious targets for attackers. Their security is paramount.

Always monitor all remote access servers using security technologies and ensure human analysts are available to intervene immediately in the event of a potential attack or suspicious activity. Carefully monitor and analyze the remote access activity itself to identify anomalies and other signs of compromise. For example, if a particular user attempts to connect from a far-flung corner of the world just a few hours after she was present at headquarters, this is a strong indication that the account might have been compromised. Or if a user starts downloading large volumes of files from internal servers onto his laptop, this could indicate an insider threat exfiltrating data or an attacker using a compromised laptop to harvest sensitive information from internal systems. Either way, unexpected activity requires further investigation so it can be stopped as soon as possible -- especially if it's malicious.

Karen Kent is the co-founder of Trusted Cyber Annex. She provides cybersecurity research and publication services to organizations and was formerly a senior computer scientist for NIST.