CISOs split on how to enable remote work

CISOs are conflicted about how their companies can best reposition themselves to address the sudden and rapid shift to remote work caused by the pandemic, a Hysolate research reveals.

CISOs enable remote work

The story emerging from the data in the study is clear:

  • COVID-19 has accelerated the arrival of the remote-first era.
  • Legacy remote access solutions such as virtual desktop infrastructure (VDI), desktop-as-a-service (DaaS), and virtual private networks (VPN), among others, leave much to be desired in the eyes of CISOs and are not well suited to handle many of the new demands of the remote-first era.
  • Half of CISOs believe that security measures are impacting productivity when scaling remote-first policies.
  • Bring-your-own-PC (BYOPC) policies further complicate organizations’ approaches to secure remote access.

Remote work becoming a permanent workflow

Beyond the overwhelming consensus that work-from-home is here to stay (87 percent of respondents believe remote work has become a permanent workflow in their companies’ operations), the study reveals that there is no singular best practice or market-leading approach to enabling workers in the remote-first era.

There is no prevailing solution in place to provide secure remote access to corporate assets:

  • 24 percent of survey respondents utilize VPN, and more than half of these also employ split tunneling, a practice that allows users to access dissimilar security domains at the same time, to reduce the organization’s VPN loads and traffic backhauling. However, of those that use split tunneling, two-thirds of CISOs express concerns about the security of the split tunneling approach.
  • 36 percent deploy VDI or DaaS. However, of those CISOs that utilize VDI or DaaS, only 18 percent say their employees are happy with their company’s VDI or DaaS solution. Further, dissatisfaction with these legacy remote access solutions isn’t limited to user experience; more than three-quarters of CISOs feel that their return on investment in VDI or DaaS has been medium to low.

Remote security policies issues

CISOs are also grappling with what their remote security policies should be in the new remote-first era:

  • 26 percent of CISOs surveyed have introduced more stringent endpoint security and corporate access measures since the arrival of the pandemic.
  • 35 percent have relaxed their security policies in order to foster greater productivity among remote workers.
  • 39 percent have left their security policies the same.

More than 60 percent of companies felt that they weren’t ready for the changes that the proliferation of the pandemic forced. What is uncertain is whether the other 39 percent who have made no changes are standing pat because they are comfortable with their company’s security posture or because they don’t know what changes to make.

CISOs enable remote work

CISOs scramble to enable remote work and maintain security

“Worker productivity and enterprise endpoint security have historically been pitted as competing priorities,” said Hysolate CEO Marc Gaffan.

“But when we surveyed CISOs who were scrambling to scale their remote workforce IT operations in light of the pandemic, it became clear how important worker productivity has now become and that legacy solutions like VPN, VDI and DaaS just can’t handle the demands of the new remote-first reality.”

Web browsing restrictions and BYOPC policies further muddy the remote-first waters. Sixty-two percent of CISOs said their companies restrict access to certain websites on corporate devices, while 22 percent say their companies do not allow access to corporate networks or applications from a non-corporate device.

The confusion indicated by the mixed results of the survey report is enough to cause many CISOs a sleepless night. In fact, the varied response trend carried over to the one unconventional question asked in the study regarding pandemic indulgences: 20 percent of CISOs report drinking more wine during the COVID-19 crisis; 32 percent drink more coffee; 8 percent choose whiskey; and, perhaps in what should come as a surprise to no one, 40 percent chose “All of the Above.”

Using virtualization to isolate risky applications and other endpoint threats

More and more security professionals are realizing that it’s impossible to fully secure a Windows machine – with all its legacy components and millions of potentially vulnerable lines of code – from within the OS. With attacks becoming more sophisticated than ever, hypervisor-based security, from below the OS, becomes a necessity.

Unlike modern OS kernels, hypervisors are designed for a very specific task. Their code is usually very small, well-reviewed and tested, making them very hard to exploit. Because of that, the world trusts modern hypervisors to run servers, containers, and other workloads in the cloud, which sometimes run side-by-side on the same physical server with complete separation and isolation. Because of that, companies are leveraging the same trusted technology to bring hardware-enforced isolation to the endpoint.

Microsoft Defender Application Guard

Microsoft Defender Application Guard (previously known as Windows Defender Application Guard, or just WDAG), brings hypervisor-based isolation to Microsoft Edge and Microsoft Office applications.

It allows administrators to apply policies that force untrusted web sites and documents to be opened in isolated Hyper-V containers, completely separating potential malware from the host OS. Malware running in such containers won’t be able to access and exfiltrate sensitive files such as corporate documents or the users’ corporate credentials, cookies, or tokens.

With Application Guard for Edge, when a user opens a web site that was not added to the allow-list, he is automatically redirected to a new isolated instance of Edge, continuing the session there. This isolated instance of Edge provides another, much stronger, sandboxing layer to cope with web threats. If allowed by the administrator, files downloaded during that session can be accessed later from the host OS.

isolate risky applications

With Application Guard for Office, when a user opens an unknown document, maybe downloaded from the internet or opened as an email attachment, the document is automatically opened in an isolated instance of Office.

Until now, such documents would be opened in “protected view”, a special mode that eliminates the threat from scripts and macros by disabling embedded code execution. Unfortunately, this mode sometimes breaks legit files, such as spreadsheets that contain harmless macros. It also prevents users from editing documents.

Many users blindly disable the “protected view” mode to enable editing, thereby allowing malware to execute on the device. With Application Guard for Office, users don’t compromise security (the malware is trapped inside the isolated container) nor productivity )the document is fully functional and editable inside the container).

In both cases, the container is spawned instantly, with minimal CPU, memory, and disk footprints. Unlike traditional virtual machines, IT administrators don’t need to manage the underlying OS inside the container. Instead, it’s built out of existing Windows system binaries that remain patched as long as the host OS is up to date. Microsoft has also introduced new virtual GPU capabilities, allowing software running inside the container to be hardware-GPU accelerated. With all these optimizations, Edge and Office running inside the container feel fast and responsive, almost as if they were running without an additional virtualization layer.

The missing compatibility

While Application Guard works well with Edge and Office, it doesn’t support other applications. Edge will always be the browser running inside the container. That means, for example, no Google accounts synchronization, something that many users probably want.

What about downloaded applications? Applications are not allowed to run inside the container. (The container hardening contains some WDAC policies that allow only specific apps to execute.) That means that users can execute those potentially malicious applications on the host OS only.

Administrators who don’t allow unknown apps on the host OS might reduce users’ productivity and increase frustration. This is probably more prominent today, with so many people working from home and using a new wave of modern collaboration tools and video conferencing applications.

Users who are invited to external meetings sometimes need to download and run a client that may be blocked by the organization on the host OS. Unfortunately, it’s not possible to run the client inside the container either, and the users need to look for other solutions.

And what about non-Office documents? Though Office documents are protected, non-Office documents aren’t. Users sometimes use various other applications to create and edit documents, such as Adobe Acrobat and Photoshop, Autodesk AutoCAD, and many others. Application Guard won’t help to protect the host OS from such documents that are received over email or downloaded from the internet.

Even with Office alone, there might be problems. Many organizations use Office add-ons to customize and streamline the end-user experience. These add-ons may integrate with other local or online applications to provide additional functionality. As Application Guard runs a vanilla Office without any customizations, these add-ons won’t be able to run inside the container.

The missing manageability

Configuring Application Guard is not easy. First, while Application Guard for Edge technically works on both Windows Pro and Windows Enterprise, only on Windows Enterprise is it possible to configure it to kick-in automatically for untrusted websites. For non-technical users, that makes Application Guard almost useless in the eyes of their IT administrators, as those users have to launch it manually every time they consider a website to be untrusted. That’s a lot of room for human error. Even if all the devices are running Windows Enterprise, it’s not a walk in the park for administrators.

For the networking isolation configuration, administrators have to provide a manual list of comma-separated IPs and domain names. It’s not possible to integrate with your already fully configured web-proxy. It’s also not possible to integrate with category-based filtering systems that you might also have. Aside from the additional system to manage, there is no convenient UI or advanced capabilities (such as automatic filtering based on categories) to use. To make it work with Chrome or Firefox, administrators also need to perform additional configurations, such as delivering browser extensions.

This is not a turnkey solution for administrators and it requires messing with multiple configurations and GPOs until it works.
In addition, other management capabilities are very limited. For example, while admins can define whether clipboard operations (copy+paste) are allowed between the host and the container, it’s not possible to allow these operations only one way and not the other. It’s also not possible to allow certain content types such as text and images, while blocking others, such as binary files.
OS customizations and additional software bundlings such as Edge extensions and Office add-ins are not available either.

While Office files are opened automatically in Application Guard, other file types aren’t. Administrators that would like to use Edge as a secure and isolated PDF viewer, for example, can’t configure that.

The missing security

As stated before, Application Guard doesn’t protect against malicious files that were mistakenly categorized to be safe by the user. The user might securely download a malicious file on his isolated Edge but then choose to execute it on the host OS. He might also mistakenly categorize an untrusted document as a corporate one, to have it opened on the host OS. Malware could easily infect the host due to user errors.

Another potential threat comes from the networking side. While malware getting into the container is isolated in some aspects such as memory (it can’t inject itself into processes running on the host) and filesystem (it can’t replace files on the host with infected copies), it’s not fully isolated on the networking side.

Application Guard containers leverage the Windows Internet Connection Sharing (ICS) feature, to fully share networking with the host. That means that malware running inside the container might be able to attack some sensitive corporate resources that are accessible by the host (e.g., databases and data centers) by exploiting network vulnerabilities.

While Application Guard tries to isolate web and document threats, it doesn’t provide isolation in other areas. As mentioned before, Application Guard can’t isolate non-Microsoft applications that the organization chooses to use but not trust. Video conferencing applications, for example, have been exploited in the past and usually don’t require access to corporate data – it’s much safer to execute these in an isolated container.

External device handling is another risky area. Think of CVE-2016-0133, which allowed attackers to execute malicious code in the Windows kernel simply by plugging a USB thumb drive into the victim’s laptop. Isolating unknown USB devices can stop such attacks.

The missing holistic solution

Wouldn’t it be great if users could easily open any risky document in an isolated environment, e.g., through a context menu? Or if administrators could configure any risky website, document, or application to be automatically transferred and opened in an isolated environment? And maybe also to have corporate websites to be automatically opened back on the host OS, to avoid mixing sensitive information and corporate credentials with non-corporate work?

How about automatically attaching risky USB devices to the container, e.g., personal thumb drives, to reduce chances of infecting the host OS? And what if all that could be easy for administrators to deploy and manage, as a turn-key solution in the cloud?