Security in Context: The BeyondTrust Blog

Welcome to Security in Context

Bringing you news and commentary on solutions and strategies for protecting critical IT infrastructure in the context of your business.

Is VDI More Secure Than Regular Desktops? I Think Not!

Posted December 29, 2011    Peter McCalister

I’ve made the argument in the past that VDI has a far greater potential for damage than normal desktops, in fact making them less secure in point of fact.

If effective security is defined as (security profile) x (risk profile) = (effective operational risk), then the same exact same security profile applied to a standard desktop and a VDI desktop leaves one term to be scrutinized: risk profile. To illustrate the issue, consider the “context” of a VDI desktop vs. a normal one. A normal desktop sits on the edge of your network, protected by things like network access control, layers of filtering and user access control, potential network intrusion detection, and even firewalls that protect the core of your network from the edge, or the entire outside network from your data center.

Now ask, how often are these controls effectively replicated for VDI? It’s nearly impossible to do so. VDI desktops effectively live inside your data center. Often right next to (or even in the same rack) as your virtual server cluster. Is there a hardware firewall or IDS/IPS box in between those two clusters? Not likely. So the risk profile of a VDI box is actually MUCH greater than the risk profile of a desktop box, because if security is compromised, the available attack surface is now exponentially greater. Even if you can’t escape the “jail” of the VDI cluster (say there is a firewall in place), you can now not only attack “horizontally” machines in the same virtual subnet, but you can also attack “vertically” down against the hypervisor. Compromising a hypervisor means instant and very difficult to detect access to every machine running on that physical box—effectively allowing you to own “swaths” of machines instead of one at a time. How long before someone with privileged access to critical data or server resources logs in on one of those VDI sessions? Now you’re really screwed, since breaking out of the VDI jail/cluster is much easier, and when you do you aren’t just “somewhere else in the network”, you’re smack in the middle of the crown jewels, inside the data center.

So, in short, even with identical security profiles applied to external or VDI boxes, the effective operational risk of VDI is much higher. Basically, VDI is less secure, inherently, by virtue of context, than that same non-VDI user desktop. So perhaps we can change the conversation in the future to how we can make VDI desktops at least as secure as their traditional brethren, including at a minimum some sort of privilege management solution.

Leave a Reply

Additional articles


A Quick Look at MS14-068

Posted November 20, 2014    BeyondTrust Research Team

Microsoft recently released an out of band patch for Kerberos.  Taking a look at the Microsoft security bulletin, it seems like there is some kind of issue with Kerberos signatures related to tickets. Further information is available in the Microsoft SRD Blogpost So it looks like there is an issue with PAC signatures.  But what…

, , , ,
Password Game Show

Managing Shared Accounts for Privileged Users: 5 Best Practices for Achieving Control and Accountability

Posted November 20, 2014    Scott Lang

How do organizations ensure accountability of shared privileged accounts to meet compliance and security requirements without impacting administrator productivity? Consider these five best practices…

, , , , , ,
Triggering MS14-066

Triggering MS14-066

Posted November 17, 2014    BeyondTrust Research Team

Microsoft addressed CVE-2014-6321 this Patch Tuesday, which has been hyped as the next Heartbleed.  This vulnerability (actually at least 2 vulnerabilities) promises remote code execution in applications that use the SChannel Security Service Provider, such as Microsoft Internet Information Services (IIS). The details have been scarce.  Lets fix that. Looking at the bindiff of schannel.dll, we see a…

, , , , ,