Positioning Zscaler Private Access Relative to VDI: Part 1

What are some of the most common concerns heard from customers about virtual desktop infrastructure (VDI)? They are often related to cost, complexity, management, upkeep, and security. How can Zscaler solve these challenges?

VDI is an undoubtedly complex environment, and having a clear picture of the organization’s needs, and positioning the right solution to improve security, reduce complexity, and improve the user experience is not always easy. Zscaler Private Access (ZPA) has evolved in the past few years and become a direct replacement of VDI, whether on-premises or cloud-delivered. It is, however, not yet possible to map all the use cases supported by a VDI implementation and, in general, is not a trivial task. Sometimes Zscaler can play a role by simply integrating solutions and providing the right level of security. To be able to understand which role ZPA can play to replace VDI, it is crucial to first understand why the customer is using a VDI. 

Organisations leverage VDI for various reasons. The most common use cases are:

1. Access granularity – restrict users’ access to only authorized applications

2. Traffic inspection – VDI as a choke point to run all traffic through on-premises security stacks

3. Data residency restriction

a) Ensure data stays within corporate boundary and/or

b) Ensure data is never stored on an end user's device

4. Traffic localization – minimize latency for heavyweight client-server interactions (e.g. database calls)

5. Desktop or software license management / reduction

a) Clean desktop experience

b) Persistent desktop that the user can access from multiple devices

c) Software deployed to a limited pool of virtual desktops, rather than to all user devices

6. Legacy app support – enable access to apps that require an older OS

VDIs are expensive, cumbersome to manage, and often hinder user experience. But there is much more to think about: we are witnessing profound changes in the EUC (End User Computing) market. Considering most applications are now web-based, you could potentially replace a VDI with an isolated browser access and provide secure access to these web applications. Applications requiring access via protocols, such as SSH and RDP, can be easily addressed using the Zscaler Privileged Remote Access (PRA).

However, organisations probably still need to depend on VDIs in certain scenarios, like if they have applications requiring thick clients. In this case, they would be able to significantly reduce the size of their VDI deployment by using browser isolation. Whenever Zscaler can’t replace VDI, it can still be integrated. Zscaler can secure Internet/SaaS access of VDI instances, and additionally can protect access to VDI infrastructure. Whenever there is a VDI environment, ZIA and ZPA capabilities can play a role and improve an environment.

Major use cases in detail 

1. Access granularity 

This use case is fully supported and can be deployed by leveraging multiple capabilities of the Zscaler Zero Trust Exchange platform, like Browser Isolation. It allows you to leverage a web browser for user authentication and application access over ZPA, without requiring users to install Zscaler Client Connector on their devices. In certain cases, it might not be feasible or desirable to install Client Connector on all devices. For example, you might want to provide third-party access to applications on devices that might not be owned or managed by your company (e.g., contractor or partner-owned devices) or control user access to applications on devices with operating systems that are not currently supported by Zscaler Client Connector.

Browser Isolation (BI) enhances the ZPA experience by making applications accessible for users from any web browser without requiring Zscaler Client Connector or browser plugins and configurations. Additionally, the existing Identity Provider (IdP) can be used to provide access to current users, contractors, and other third-party users without managing an internet footprint.

BI is a feature that addresses needs in both cyberthreat protection and data loss prevention and can be leveraged for both internet/SaaS apps and private apps. BI policies can dictate if a site should be run within isolation, and if so, whether you allow cut/paste and download capabilities for the user. An isolation container is instantiated for each user in the cloud and only pixels are transmitted to the user’s browser. Sites may be isolated due to a configured URL category, cloud app control policy, or suspicious destinations (if Smart Browser Isolation is enabled).

Last, but not least, is worthwhile to mention the recent capabilities introduced by the User Portal 2.0, that allows unmanaged devices to SaaS & private web apps. With this feature enabled, unmanaged devices will be able to use ZPA user portal to access both sanctioned SaaS/private web apps AND have their internet facing traffic routed through ZIA while in Isolation mode. Organisations can provide access to sanctioned SaaS applications from unmanaged devices to enforce policies using the isolation policies defined on ZPA. The isolation containers that are created as a result of a ZPA Isolation Policy can forward non-ZPA defined application traffic and internet traffic generated to ZIA for further processing and enforcement of necessary policies. Any traffic generated for applications defined on ZPA will continue to be forwarded via ZPA’s ZTNA service.

2. Traffic inspection

Although this use case is rare, traffic inspection is still fully supported, leveraging the inspection capability provided by the Zero Trust Exchange platform. We can use Zscaler Private Access (ZPA) AppProtection (formerly Inspection), that provides high-performance, inline security inspection of the entire application payload to expose threats. 

It identifies and blocks known web security risks, such as the OWASP Top 10, and emerging zero-day vulnerabilities that can bypass traditional network security controls. It can help to protect internal applications from all types of attacks in the OWASP predefined controls with SQL injection, cross-site scripting (XSS), and more. Additionally, it helps to understand the severity, description, and recommended default action for each type of attack related to OWASP predefined controls. Each OWASP predefined control is identified with a unique number, defining how the control operates, and is associated with the level of concern. The predefined controls are organized into various categories:

- Preprocessors 

- Environment and Port Scanners

- Protocol Issues

- Request Smuggling or Response Split or Header Injection

- Local File Inclusion

- Remote File Inclusion

- Remote Code Execution

- PHP Injection

- Cross-Site Scripting (XSS)

- SQL Injection

- Session Fixation

- Deserialization

- Issues Anomalies

Additionally, Zscaler recently introduced support for inspecting ZPA application segment traffic. A predefined forwarding rule, ZIA Inspected ZPA Apps, is available on the Policy > Forwarding Control page to inspect the Microtunnel traffic of a ZPA application segment using ZIA. This rule is applied automatically to the traffic from ZPA application segments with the Inspect Traffic with ZIA field enabled in the ZPA Admin Portal. As part of this feature, a predefined Auto ZPA Gateway is available on the Administration > Zscaler Private Access Gateway page. This new gateway is the default for the predefined ZIA Inspected ZPA Apps forwarding rule.

We can minimize data exfiltration concerns with ZPA AppProtection, by utilizing Cloud Browser Isolation (CBI) where unmanaged devices are prevented from downloading sensitive content to the local host. For corporately managed devices, organisations can leverage DLP with Source IP Anchoring (SIPA) utilizing the ZIA cloud. AppProtection customers can craft custom signatures to detect and block bulk data downloads and use those in conjunction with other validation methods such as ZPA posture control.

Organisations can rely on Zscaler Internet Access (ZIA) SSL Inspection best practices for configuring and deploying in an organization's network environment, for example, while accessing SaaS applications. Encrypting communications helps maintain the privacy and security of information passed between sender and receiver communications. Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), are protocols designed for the privacy and security of internet services. While these protocols do a great job of keeping information private from prying eyes, these security tools also conceal threats to the user, device, and organization. This is where the inspection of SSL and TLS encrypted traffic becomes a necessity.

Inspecting encrypted SSL and TLS traffic via SSL Inspection is done by the Zero Trust Exchange at scale, allowing organizations to control risk and enforce policy. Enabling SSL Inspection is a required first step towards:

- Controlling risk

- Inspecting traffic (malware, data loss)

- Adaptive control

- Enforcing policy

- Per-session policy decision and enforcement

- Allowing, blocking, and restricting tenants environment.

Use cases 3 to 6 will be covered in part two of this series.