The COVID-19 pandemic has greatly increased remote work among enterprise employees. Home-network environments are not professionally managed, so they are an appealing target for attackers. These attackers are aware that systems on home networks are not patched regularly and a number of them are out of date with respect to vulnerability mitigation. Threat detection is typically nearly absent on home systems, and remediation is often incidental at best.

In Remote Work: Vulnerabilities and Threats to the Enterprise, we laid out the architecture and threat landscape for remote workers in a home network. Non-professionally managed endpoints connecting to enterprise services have significantly increased the risk for many enterprises that are pivoting to remote work in response to the pandemic. Fortunately, there are tools available that can make that risk manageable and even put the enterprise on the road to more flexible, yet still secure, end-user access.

In this post, we advise how to mitigate these risks to regain a security footing. We describe some of the capabilities available in modern endpoint-management solutions and formulate a template for baseline security policies required for remote access. You can achieve these policies using basic endpoint-management capabilities. This post also reviews additional features that can advance your ability to monitor and manage the risk of endpoint compromise.

Endpoint-management solutions bring together technologies from mobile-device management, data-loss prevention (DLP), and system orchestration, with the goal of letting enterprises monitor activity and enforce policies on the configuration and use of endpoint systems. Many people are familiar with endpoint management as it is applied to mobile devices, such as smartphones and tablets. In the modern enterprise, however, most personal computers are also mobile devices, so unified endpoint management (UEM) solutions from multiple vendors exist for both mobile devices and the major personal-computer operating systems, such as Windows and iOS.

The core of an endpoint-management solution is an agent that runs on the endpoint and reports to an enterprise-maintained server. Most importantly, endpoint-management solutions ensure that the system is configured according to enterprise policy. The enterprise can choose, on a per-configuration basis, whether the endpoint-management agent only reports violations of policy (audit mode) or prevents them (enforcement mode).

This foundational capability can be applied in a number of ways to ensure that endpoints are secured before they access enterprise services. Some examples:

• Configure the system to use the enterprise web proxy and DNS servers. Disable user changes to proxy configuration to ensure that they are always used.
• Ensure that antivirus or other security software is installed, enabled, and up to date, or that unwanted software, such as proxy-avoidance tools, is not. The enterprise can provide this software by means of a self-service portal and use the endpoint-management tool to report versions of the software for licensing and updating purposes.
• UEM software with DLP capabilities can ensure that sensitive information cannot be transmitted in unauthorized ways. For example, information copied out of an enterprise Microsoft Word document can be prevented from being pasted into an email or text file, but could be pasted into authorized locations, such as a spreadsheet checked out from enterprise storage.
• Enterprise-sensitive data on the managed machine can be securely deleted at the enterprise's discretion (such as when a user leaves the organization or a machine is lost or stolen).

Policies can be more exhaustive on enterprise-owned devices than on bring-your-own devices (BYOD), which are almost always intended for both enterprise and personal use. For this reason, usability for purposes other than the enterprise mission should be considered when designing BYOD endpoint policies.

You can, however, mitigate more risk than you may think without improperly degrading device usability, especially on mobile devices.

For organizations adapting to their newly distributed workforce, the first priority should be establishing a minimal security baseline. What is the minimum set of guarantees that must be met before users can access enterprise services? These guarantees will differ somewhat among enterprises, but as a starting point, we recommend the following:

• The endpoint connecting to enterprise services must be running an authorized operating system at a recent patch level. Ideally, this is the most recent patch level, but accommodations should be made to ensure that users are not locked out during the patch-rollout process when some systems will be upgraded and others will not be. There may be other specific exceptions as well; if a critical business application does not work with the most recent patch, for instance, a decision must be made that balances the availability of that application with the security value of the upgrade. In these cases, it is especially important to have additional layers of security, such as a host-based intrusion-protection system (IPS), that you can use to introduce additional mitigations.
• Enterprise security software should be installed on the endpoint and running at a recent (again, ideally most recent) upgrade level.
• User and access control should be configured safely. For instance, the current user accessing the enterprise service should not have administrator privileges. Enterprise standards for password quality (e.g., complexity, length, and expiration) should be, at a minimum, enforced for the accessing user, and ideally enforced universally on the system.
• An enterprise should be requiring multi-factor authentication (MFA) to authenticate to any remote access or other services. Therefore, any configuration on the endpoint to support the second factor should be validated and kept up to date. If a mobile device is used for authentication, the device endpoint manager may need to download the authenticator app onto the device, or configure an app that provides authentication over a standard, such as a one-time password (OTP).
• The enterprise should be able to remotely and securely delete any critical enterprise data on the system, such as server certificates or authentication tokens, in the event that the device is lost or stolen or the user leaves the organization. If the remote-access method permits users to download sensitive enterprise documents to the local system, it should be possible to delete these as well. As always, remember that following the principles of least privilege and least access will prevent sensitive enterprise documents from being on the system in the first place, making their deletion from the system unnecessary.

On enterprise-provided systems, we can go somewhat farther. For instance, user and group configuration on an enterprise-provided system should be fully aligned with the enterprise's identity and access management (IDAM) policy. Moreover, all users on the system should be defined in and configured appropriately to the enterprise's directory services. MFA should also be required for logging on to an enterprise-provided system. It is worth considering whether to require that user-provided systems be configured with these features as a condition of remote access, as well.

Use this set of policies as a blueprint, customizing it to the needs of your enterprise. You determine your own minimum baseline, however, and check any proposed solution against it first. This baseline is a powerful tool for filtering the set of options to those that meet your needs.

With a security baseline that has been formulated based on organizational needs and risk profile, a natural next step is to compare it to the current remote user base and assess the gap. To do this, you will need to collect current user data, ideally in parallel with the formulation of your initial security baseline. There are a few ways to go about this:

• User-reported data is subject to misreporting bias, but it can be collected without additional technology and can answer some questions that automatically collected data can't (for example, what systems users think they could acquire or use for work if the ones they used were to be unavailable). User surveys are also a good way to gauge satisfaction with the current system.
• Connection logs for the enterprise's remote-access solutions may log data about operating system and version. This data can be used to measure the number of operating systems that must be supported and to learn how many out-of-date or end-of-life systems are being used to connect to the enterprise.
• If an endpoint manager has already been acquired, you can deploy it in audit mode to collect a wealth of information on the user-endpoint population. If a full rollout would be impractical, consider installing the manager on a sampled subset of endpoints.

Use this data to answer questions such as

• How many systems are currently in use that cannot be brought up to the baseline? For instance, how many systems connecting via remote access are running end-of-life operating systems? How many of those lack hardware support for an actively maintained operating system? Users of these systems will need to find other solutions, which will likely entail cost for the enterprise.
• What remote-access solutions are being used by which systems? BYOD systems connecting via VPN usually represent a high risk, even with an endpoint manager enforcing policy; these systems would be good candidates to migrate to a more restricted solution such as remote desktop.
• What about the system-access statistics is surprising or violates assumptions made while producing the security baseline? It is much less expensive to change the baseline now to account for discrepancies than it would be later.

The data itself will, no doubt, suggest additional questions, as well. Checking your baseline against current usage builds confidence that your security requirements are realistic and can be implemented in your environment.

The sample baseline described above should be possible to implement with almost any of the major endpoint-management solutions. It is now possible to use the information provided by endpoint monitoring to improve the organization's security posture beyond what is possible with approaches such as network-based monitoring and response.

First, because endpoint monitoring never utilizes the network, it provides a wealth of behavioral information that is not accessible through network monitoring. In particular, the lifecycle information of files, processes, and user sessions (including failed logins) can be useful in identifying malware on a host even before it begins to seek out its command and control or act on network objectives.

Another advantage of endpoint-based events is that they exist at several levels of abstraction. High-level events, such as sending emails or requesting webpages, can be reconstructed from network-traffic data (if it is available and unencrypted), but that process is inefficient and prone to error; network monitoring lives naturally at the transport and session layers of the Open Systems Interconnection (OSI) model. Applications, on the other hand, can usually log events at many levels of abstraction. Thus, an endpoint monitor can note that a process opened and spawned a shell, which ran an executable, which executed a web request resulting in 10 responses sent over one network connection.

After endpoint information is integrated into your security operations, you will be well positioned from a security standpoint to move to a zero-trust architecture for providing services to your users. At that point, you will have many options. You could still maintain an enterprise network, if you found it to be convenient to stage services there. Alternately, you could move all your operations to cloud service providers. The users won't care; they will be accessing services directly via the Internet, no matter where those services are hosted. Moreover, by defending your users and services rather than their network communications, you don't need to care either.

The last year has been stressful. A lot of things have had to happen quickly. Now is the time to go back over and do it right. If you do, you may look back on this transition not just as a scary, stressful time, but as the transition to an enterprise that is both agile and secure.