Implementing Zero Trust with DaaS

03.01.23 11:11 AM
Desktop-as-a-Service (DaaS) allows your company to provide access to virtual desktops, a move that reduces risk, supports scalability, and saves money. However, remote solutions do come with their own security challenges. As a result, it’s critical to mitigate the risks whenever possible. One option is to implement zero trust in conjunction with DaaS. 

Zero trust essentially involves treating no user, device, or connection as inherently permitted. Instead, verifications are required every time a connected system is accessed. By doing so, you can harness the power of access controls to limit the likelihood of unauthorized intrusions, all while supporting the remote work needs of a workforce. Generally, zero-trust implementations involve a few key validation points. Here’s a look at the areas that need addressing when implementing zero trust with DaaS.

How to Implement Zero Trust with DaaS

Default to Restricting Access

With a zero-trust strategy, the default is to assume that access isn’t required unless a request for access is thoroughly vetted and approved. Essentially, access controls determine that no individual or device is inherently allowed to connect, regardless of their position or location. By using that strategy, you essentially begin with blacklisting and shift accounts or devices to whitelists as needed, limiting the likelihood of access being granted to a person or device that doesn’t require it.

User Authentication

With zero trust, users must authenticate every time they connect to their virtual desktop through DaaS. It can also extend further, requiring reauthentication when accessing specific internal resources, even if they’re requesting access through their DaaS connection. Generally, multifactor authentication is preferred. With that, simply acquiring a user’s login credentials is insufficient for establishing a connection, heightening security.

Device Whitelisting

Device whitelisting essentially involves preventing access to a virtual desktop or other connected applications if the device used isn’t approved in advance. With this strategy, only whitelisted devices are allowed to connect, preventing compromised credentials from being able to access systems through any other devices.

In most cases, whitelisting devices is simplest if employees are only allowed to use company-provided computers, smartphones, and tablets. For Bring Your Own Device (BYOD) programs, it’s critical to have a review process before granting access. Along with getting the relevant device data, BYOD programs often require specific security-oriented measures. With formal reviews, it’s easier to ensure that such steps take place.

Additionally, updating the access controls as BYOD or company-issued devices are no longer used for the previously approved purpose is a must. That ensures access doesn’t continue if a device is repurposed or an employee leaves the organization.

Location Restrictions

Often, location restrictions serve as safeguards in situations where user credentials and devices are compromised. If a connection attempt occurs outside of an approved region – the size of which can vary – access isn’t granted. That provides a final layer of control, as stolen credentials and devices won’t connect if they’re outside of an approved location.

Having a set process for establishing approved locations is essential. Additionally, ongoing adjustments are often necessary, ensuring areas that are no longer serving as workplaces are blacklisted once again.

Ongoing Monitoring

Even with a zero-trust implementation, there’s always a chance an authorized connection may occur. As a result, ongoing monitoring is essential. Make sure all access and activities are logged and reviewed for odd behavior or unauthorized actions. With that, it’s possible to take switch action if a non-approved activity occurs, limiting overall risk.

Derek Roush