For many organizations, COVID-19 dramatically changed the risk calculation for remote work. In January 2020, many enterprises viewed remote work with skepticism; by March, the choice for many was to become a remote-first enterprise or to shut down.

As one might expect, embracing long-resisted technologies and practices has been chaotic for many, with actions dictated primarily by urgency. By now, most enterprises--to the surprise of some--have successfully adapted to the new environment. A few, such as Twitter and Slack, have even reinvented themselves by choosing to make their remote enterprises permanent.

As the urgent threat to business continuity has receded, some IT staff and other stakeholders are finding time to ask themselves other important questions: How has this change in the way we work altered our security posture? How has it changed our attack surface, and what should we be doing to defend it? In this blog post, I explore the answers to these questions.

Attackers have been aware of remote work as a threat vector for some time. Mandiant reported a 2015 trend of attackers hijacking VPN connections, even those protected with multi-factor authentication (MFA). Unsurprisingly, in 2020 attackers moved early to capitalize on the rapid shift to work from home at numerous organizations, including federal agencies, such as NASA.

The remote work environment is particularly appealing for attackers for several reasons. First, the home-network environment is not professionally managed. Most critically, this means that many more systems on home networks are not patched regularly, and a number of them are out of date with respect to vulnerability mitigation. Some may even be treated by their manufacturers as end-of-life (EOL) products, and will never receive mitigations even when serious vulnerabilities are found.

To persist on an enterprise network, an attacker who has exploited a system must avoid detection and resist remediation. Here too, the home network is friendlier to the attacker; threat detection is typically nearly absent, and remediation incidental, such as when a PC is reinstalled or retired because it is running slowly.

If you think this network environment sounds no different from the sort one might encounter on a public WiFi network, such as at a hotel, coffee shop, or airport, you're right. In fact, the foundation of zero-trust architecture, an emerging trend in enterprise and distributed networking, is the idea that one's network should be assumed hostile. The key to securing the remote work environment is to extend these zero-trust assumptions further. It isn't just the network that should be assumed hostile, but everything that is not under the enterprise's control. Interestingly, this may extend even to the endpoints that are used to access enterprise resources.

With these assumptions in mind, let's consider remote-access technologies and devices, and their properties, in the context of this threat environment.

One of the oldest and most familiar solutions to the problem of remote work is the virtual private network, or VPN. A VPN establishes an encrypted tunnel between the system running the VPN client and a VPN server that then proxies traffic through the tunnel to the rest of the enterprise network. The system running the VPN client becomes, effectively, an extension of the enterprise network, existing inside that network's perimeter with access to resources generally equivalent to any other system on the enterprise network.

VPNs defend against attack via authenticated access control and isolation. This approach can be effective only if the access control and isolation are effective. Unfortunately, fully maintaining this assumption is hard. Many VPNs are configured to prohibit a "split horizon"-that is, the ability to access the local physical network and the virtually connected enterprise network simultaneously. Many fewer VPNs, however, are configured to be "always on," meaning that the VPN endpoint effectively never interacts directly with the local network. If an attacker has persistence in that network, even brief access can expose the enterprise endpoint to compromise.

Another approach to remote access is to allow users to remotely control a system that already resides on the enterprise network. Systems used via remote desktops may be physical or virtual. Moreover, virtual systems may be persistent or may be destroyed and re-created frequently, sometimes existing only for the duration of a user's login session. Remote desktop systems utilizing virtualization are sometimes called virtual desktop infrastructure (VDI).

As with VPNs, remote desktops require authenticated access, but practice a more extreme form of isolation: the endpoint device is not a first-class participant in the enterprise network; instead it presents the user with a window into another system that is. Although this approach adds abstraction and difficulty to the job of an attacker looking to compromise the enterprise, it is still possible to observe and even manipulate the enterprise systems on the other side of the window.

Enterprise networks were traditionally accessed only on enterprise-provided equipment. This arrangement has permitted enterprises unrestricted access to monitor and configure the device precisely according to their risk profiles and mitigation strategies. It also has required the enterprise to purchase and maintain equipment. This has sometimes frustrated end users when the enterprise was unwilling to buy newer equipment, a problem that became particularly pronounced when smartphones and tablet devices entered the market.

The alternative is to permit access to enterprise resources over user-provided devices--the so-called bring-your-own-device (BYOD) model. BYOD can represent substantial cost savings to the enterprise over issuing enterprise-owned devices, and users are often happier because they can use familiar devices to get work done. Moreover, a device the user already has can be used immediately, without having to procure and ship the device to the user. For many organizations, the BYOD model has been essential to the speed and effectiveness of their pivot to remote work.

With all these advantages comes one significant risk: a diminished ability to control the configuration of user-supplied devices. For a long time, this risk was enough to make many organizations reject BYOD. However, an ecosystem of endpoint-management solutions has emerged to meet this need. This ecosystem is often referred to as unified endpoint management (UEM) solutions as they grew to include laptops and other devices beyond phones and tablets. One component of a UEM solution is an application on the end-user device that monitors information of interest to the enterprise, such as installed software and versions. UEM software may also enforce some configuration options, such as the configuration of a strong firewall or the use of an enterprise proxy for web browsing. The end-user device applications usually communicate with server-side processes that verify that device configurations are appropriate for enterprise access and push out configuration or software updates.

UEM solutions allow an enterprise to project its policies outward onto all devices that connect to enterprise resources, whether or not they are enterprise-provided. It is now common practice to deploy EM solutions to both enterprise- and user-owned devices, using EM as a single tool for managing the software baseline of all end-user devices.

The main drawback of device-management solutions is that they reintroduce some of the cost, in time and money, saved by allowing users to furnish their own devices. A solution must be chosen, paid for, and deployed to every device.

Supporting a remote workforce requires giving remote workers access to enterprise applications, data, and services. Workers also require equipment for accessing those services. Furnishing enterprise equipment is costly and takes time. Using devices that the user already has on hand can save considerable time and money, but introduces risk, especially vulnerability to well-known exploits due to lack of patch discipline. UEM solutions can be used to mitigate that risk.

For the past nine months, many organizations have had to make unexpected, high-stakes decisions in this tradespace, with sharp limitations on time and budget. In such an environment, it's understandable to look for ways to do more with less. Availability is a security property, and few things threaten availability more than insolvency.

Unfortunately, expenses are easier to quantify than risk. One example of this, in the context of the pivot to remote work during the pandemic, is the choice to rely exclusively on a remote-access solution's security to isolate the enterprise from potential security issues on end-user equipment. In other words, some enterprises look at the multi-factor authentication (MFA) required to log on to a VPN or the ephemeral nature of a VDI workspace as sufficient security, even if it is deployed on a vulnerable end-user device.

MFA and ephemeral virtual machines form useful layers of a defense-in-depth security strategy. They are not, however, the end of that strategy. Techniques exist to circumvent them. For instance, an attacker with persistence on a device used for remote access could

• attempt to exploit a user's phone, assuming it is on the same network, and subvert the user's MFA-authentication app
• use keylogging and screen scraping to surveil user interactions on the network
• intercept an attempt to log in via remote access to collect password and MFA credentials, using them to gain attacker access.

Remote-access security mechanisms, such as MFA, significantly mitigate some types of attacks, such as account hijacks using compromised or reused passwords. Similarly, tools such as VDI using ephemeral virtual machines can mitigate against some types of attacker persistence. They are not, nor are they intended to be, robust defenses against all kinds of attack, particularly when a client is running on an untrusted system.

MFA and tools such as VDI are not a complete solution. It is therefore critical that any system with enterprise remote-access software also be at least partially managed by the enterprise. The good news is that numerous tools exist for this purpose. In a future post, I will discuss how to use UEM and planning to ensure that the risks of remote-endpoint access are managed comprehensively.