Does VDI protect against data leaks? 

The short answer is simply no.

Read more to find out why and to get some tips on how to fix things and get real security while keeping VDI in place (if you have to).

In this post, when we use the term VDI, we refer to many different variants of remote desktops/apps, of any vendor (VMware / Citrix / Microsoft / …), including:

  • On-prem VDI desktops
  • Desktop-as-a-service (DaaS)
  • Published apps 
  • Jump boxes / jump hosts / bastion hosts

There are some misconceptions and myths in the security industry regarding VDI and its ability to protect against data leaks and malicious insiders. For example:

  • “Malware can’t leak data out of VDI apps/desktops”
  • “Malware can’t control the VDI apps/desktop“
  • “No corporate data is stored on physical endpoints”
  • “Multi-factor authentication makes VDI secure enough”
  • “Endpoint OS health checks make VDI secure enough”

Let’s explain why this is not the case and VDI is not really a security solution that can help against these threats:

  1. VDI desktops/apps are often accessed from unmanaged devices (e.g. users working from home, bring-your-own-laptop programs, etc). This means that the physical laptop/desktop accessing VDI has a high likelihood of eventually getting infected with malware. That malware will see whatever the user sees and can interact with the remote desktop/apps in the user’s name after he authenticates and connects.
  2. VDI clipboard controls don’t prevent attackers from running commands on the remote desktop or leaking data out. We even created a quick demo showing how easy it is to leak any arbitrary file from a remote locked-down VDI desktop (e.g. with no clipboard allowed) in a stealthy way. Important to notice: there’s no need for any software vulnerability to do this, it’s a security design flaw of the VDI architecture. Any persistent attacker will be able to pull this off with little investment.
  3. It doesn’t matter how many authentication factors you use to authenticate to VDI. The attacker would just wait for you to complete the authentication and then ride your session to do harm.
  4. It doesn’t matter if you check the physical laptop by running all kinds of OS health checks as part of a “conditional access” model. Just like a drunk man can’t tell if he’s drunk, the OS can’t tell it’s infected with malware if it’s infected with malware. OS health checks are good basic hygiene but don’t count on these to really detect any serious malware that got to the user’s personal laptop.
  5. The VDI desktop is typically an internet-connected Windows OS (e.g. it has access to email, some internet browsing, cloud applications, etc). This means that the VDI desktop can and will also be infected unless the OS is completely locked down. If the VDI desktop is infected, malware can just extract any data out of it or do harm. If you’re hosting VDI desktops in your data center, malware on the VDI desktop can now spread in your data center too by moving laterally.
  6. Specifically for published apps (as opposed to full VDI desktops) – if one of these apps has a software vulnerability, leveraging that vulnerability can lead to malware running in a single server OS that co-hosts multiple user sessions/apps. Malware now has access to all of those user sessions and to a whole lot of sensitive data in just one shot.

A Simple VDI Attack (No Zero-Days required)

It’s not all bad news.

If you can stick to all of the following guidelines, you can still build a VDI setup that really protects against data leaks or sabotage:

  • Make sure VDI is exclusively done from physical thin clients or other extremely locked-down operating systems that are only used for accessing the VDI desktop / published apps. The physical device should never mix VDI access with other usages, such as internet browsing or email. 
  • If you’re providing users with a VDI desktop, remember that this VDI desktop is still a Windows desktop mixing lots of different usages/apps (and most likely it has internet access too). To really secure it, you’ll need to lock down that remote VDI desktop with techniques like app whitelisting, least privilege principles and limited network access, if possible. Alternatively, you can provide users with just a few published apps and not a full desktop OS (but make sure to frequently patch those published apps and the underlying software).
  • If you must provide users with a VDI desktop (and can’t do with just a few published apps), you could get real security by providing each user with two VDI desktops: one for day-to-day usage and another for privileged usage. However, users will need to constantly switch between these desktops and having two VDI desktops per user might be too expensive for most enterprises.

There is another option.

With Hysolate, a user’s normal physical laptop can be split into two operating systems, each one running in its own local VM – one for general day-to-day usage (including internet browsing, email and other risky business) and another strictly for accessing the corporate crown jewels via VDI. This provides users with local productivity where they need it while strictly protecting the VDI desktop/apps. Malware on the general VM cannot see or interact with the VDI resources as they are accessed on a separate sibling VM.  

To sum up, VDI has all kinds of benefits, but most VDI setups simply wouldn’t stop persistent cybercriminals from getting your data or sabotaging your business. If you deployed VDI to get better security, we highly recommend trying to apply some of the practices above to move from security theater to real security.

The post Does VDI protect against data leaks?  appeared first on Hysolate.

*** This is a Security Bloggers Network syndicated blog from Blog – Hysolate authored by Tal Zamir. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)