vSentry and the Art of VDI Security

http://blogs.bromium.com/2013/04/26/vsentry-and-the-art-of-vdi-security/

Friday, April 26, 2013 12:59 PMvSentry and the Art of VDI SecurityA Collection of Bromides on InfrastructureTal Klein

Much has been written about whether VDI itself is inherently "secure". This blog will not attempt to answer that question. Instead I want to focus on how we, at Bromium, view VDI security, and how we can help protect companies that are deploying VDI.

Any VDI security discussion should be two pronged:

1. Protecting the VDI desktop
2. Protecting the endpoint connected to the VDI desktop

Protecting the VDI desktop

Both non-persistent and persistent VDI desktops are susceptible to zero-day attacks that users unwittingly allow in through e-mail attachments and web browsing.  Some may believe that non-persistent desktop infections are easier to remediate in the event of a virus outbreak or security breach because the desktop can be refreshed or rebooted to resume its original state, but there is already evidence that advanced malware is targeting user profiles, which persist even after the desktop has been refreshed or rebooted.

Security-conscious organizations have long used screen scraping as a mechanism to abstract sensitive applications using RDS or XenApp to publish those applications to physical desktops. Those of you who recall theIE6 quandary will remember that publishing an IE6 browser from Windows Server 2003 onto Windows 7 VDI desktops for the sake of legacy web application compatibility was not an uncommon practice. More recently, while developing our product strategy, I encountered several VDI shops that continue to publish an RDS-delivered browser (albeit a current one these days) to their VDI desktops. Why?

In the context of defense-in-depth, there are interesting benefits to publishing a browser running on Windows Server onto a Windows 7 Desktop:

First, most malware is not designed to target Windows Server, or more specifically most malware is written to attack 32 bit Windows. That's not to say you can count on this as a defense mechanism, especially if the attack is targeted,

Second, if the published browser is compromised, the attack does not propagate to the client. However, it creates a sticky situation: Depending on the malware, it could mean that while connecting endpoints aren't compromised, their browsing sessions may be.

When I asked these enterprises why they would publish a browser given that it is already a built-in component of the desktop, I received mixed answers:

In the case of persistent virtual desktops, doing so was a nearly universal practice in my admittedly small sample set (three large financial companies, a healthcare provider, and a state agency), because it was easier to abstract the browser away from the desktop image. Simply enough: the browser package needed to be refreshed more often than the desktop image.

If we add non-persistent desktops to the mix, the answer often came back that the published browser was pre-configured with optimal settings to access enterprise web applications.

In any case, short of disabling user access to the internet from a VDI desktop (see "Protecting the endpoint connecting to the VDI desktop" below) , even a perfectly patched and configured browser remains susceptible to zero-day exploits, just as a perfectly patched and configured image of Windows cannot protect itself from zero-days.

vSentry for RDS is designed to protect both VDI desktops and published browsers from APTs and  zero-day attacks. It's the only solution that can protect a published browser not only from malware, but also from cross-site-scripting and man-in-the-browser attacks. Our architecture decouples each browsing activity not only from the desktop, but also from every other browsing activity, such that no site can persist or propagate an attack onto another site. The same goes for document-based attacks: One bad apple cannot spoil the bunch.

Protecting the endpoint connected to the VDI desktop

If it is the case that less than 100% of your users are accessing their VDI desktops from thin clients, then this section is for you. If your users are accessing their VDI desktops exclusively from laptops, then this section isespecially for you.

The employee laptop is the primary attack vector into your enterprise infrastructure. A compromised laptop puts an attacker within easy range of your virtual desktop infrastructure. Again, referring back to my days at Citrix – nearly all VDI implementations consisted of at least some (and in many cases mostly) employee laptop access to virtual desktops. If the attacker has compromised the employee desktop accessing the employee virtual desktop, then it is safe to assume that a compromise of the virtual desktop is within reach.

By ensuring that malware cannot ever persist to either local or virtual desktops, vSentry is also protecting the rest of your sensitive information and infrastructure.

Thus it is our position that vSentry and vSentry for RDS together are a comprehensive defense-in-depth security solution for VDI.

But… what about nesting?

While not a new concept, VT nesting is still very much in its infancy. I recently recorded a webinar with Steve Poitras from Nutanix about why VT nesting was an inevitable component of desktop computing. While we currently have vSentry running on vSphere (ESXi 5.1) desktops through VMware's Virtual Hardware-Assisted Virtualization as a POC – hardware support for nesting is imminent, and so is installed deployment of vSentry directly on VDI desktops.