Extending Zero Trust to the Endpoint

by Tal Zamir on September 1, 2020

What is Zero Trust?

Zero trust is a security model based on maintaining strict access control. It has risen in popularity since Forrester coined the term in 2010.

Initially, Zero trust referred to an enterprise security architecture that relied on a trusted internal network protected by firewalls that enforce perimeter security. However, with enterprises adopting mobile and cloud technologies, the perimeter is becoming increasingly difficult to enforce. In addition, attackers have a variety of ways to get into the internal network. One of the main methods is breaching a user’s device that is allowed to connect to the enterprise network. Another flaw in the perimeter-based security model is the risk of insiders who act within the corporate perimeter.

As a result, enterprises are starting to move away from network perimeters into a Zero-Trust Architecture (ZTA). With ZTA, access is granted based on device/user credentials and not on the user’s presence in the corporate network. Based on the user’s credentials, the enterprise can grant access to a subset of enterprise resources and employees can work from any network without relying on a VPN connection. The architecture is called “Zero Trust” because the enterprise doesn’t automatically trust devices within the corporate perimeter. Instead, it verifies all devices/users.

User Devices: The Zero Trust “Achilles Heel”

ZTA is definitely a great step in the right direction but it has a fundamental design flaw that is the result of a wrong assumption. ZTA’s underlying assumption is that the network can check the health of user devices and then trust them with access to enterprise resources. This might be true for some extremely locked-down devices. However, most enterprise user devices run operating systems like Windows and have a huge vulnerable code base, a wide variety of legacy applications/middleware, and access to risky malicious networks or internet resources. These devices can easily get compromised by determined attackers. Once a device gets compromised, the operating system can no longer be trusted as malware resides in the same operating system kernel and can tamper with operating system health checks.

This means that many enterprises that adopt ZTA still mistakenly trust user devices. This is a critical ZTA flaw as it allows attackers to breach a user’s device and then ride the authenticated user’s session to do harm.

Sponsorships Available

Furthermore, as ZTA creates a false sense of security, it encourages enterprises to allow access to corporate resources from personal/unmanaged/BYOD devices, relying only on basic health checks to prevent malware from getting in. This makes things worse, as personal/unmanaged devices have a higher probability of getting infected.

Fixing the Weakest Link in the Zero Trust Concept

To close this gap in ZTA — and make ZTA a dramatically more secure architecture — enterprises must ensure employees use trusted devices. By re-establishing trust in user devices, it is possible to let users access corporate resources anywhere. However, this is a challenging task, as enterprises still rely heavily on Windows (or other monolithic operating systems) and legacy applications that are vulnerable and untrusted. Making devices trusted again must also support the migration of existing devices, as solutions that require a fresh start with a new operating system or new devices would fail in any realistic enterprise environment.

One way to increase trust in user access is by requiring that enterprise access is always done through a secure trusted OS, e.g. through a VDI desktop or through a jump box. Even if the OS on the physical device is compromised, having enterprise access run on a separate trusted and isolated OS eliminates a lot of common threats. However, setting up, configuring, and maintaining a whole separate OS image on VDI/jump box is expensive, complicated, and error prone. Furthermore, it degrades the user experience, as it requires users to go through another hop in the network for every interaction they do with every app on that remote OS. In the era of remote work/COVID-19, this becomes even worse, as connectivity may vary for people in different locations, in different home networks, etc.

There’s a better way. At Hysolate, we achieve this new ZTA architecture by splitting a user’s device into two segregated zones, each running in its own OS, leveraging the latest hypervisor and virtualization-based security technologies. One OS is the user’s unmanaged/untrusted/personal OS and another is an instantly-provisioned trusted corporate OS running in a VM – this VM is magically spun up without any infrastructure cost/image building work, etc. The corporate VM runs a locked-down operating system and can contain an inaccessible client certificate that vouches for the integrity of the VM. The ZTA broker would only allow that corporate VM running on Hysolate to have access to sensitive enterprise applications. It’s impossible for the end-user to access these applications from any other untrusted environment/device. Furthermore, our solution lets IT isolate this corporate VM from the user’s personal OS, including fine-grained cloud-managed controls over clipboard, USB, network, applications, etc. With this architecture in place, the Zero Trust puzzle can now be complete and enterprises can really move to a secure-by-design architecture.