New! Listen to this post in our daily podcast.
I got an email from a reader last week asking a simple question: “With all this desktop virtualization, do you think we still need to keep paying $30 a seat for client security suites (antivirus, etc.)?” This is a great question which we’ll explore today.
Frequent visitors already know how I’m going to answer: “It depends!” In this case it depends on how you define both “desktop virtualization” and “client security suite.”
The desktop virtualization question is easier to define for us, since that’s what we do every day. We can look at this from the perspective of hosted virtual desktops (yeah, I said “HVD” instead of “VDI”—congrats Gartner, you win) and client-based desktops (client hypervisor, Type 2, or streamed).
But figuring out what exactly makes up a “client security suite” is a bit more complex. In the old days it was just antivirus. But now the vendors add-in client firewalls, anti-spyware and anti-adware, email scanning, rootkit detection, device control (to lock down ports and removable media) and even application control (to lock down specific applications). So what of this, if any, do we need to think about for virtual desktops?
Virtual desktops running in the datacenter
For virtual desktops running in the datacenter, we can probably do pretty much the same thing that we do for Terminal Server sessions.
We need this somewhere in our infrastructure. If we have a secure perimeter, we can probably get away without it on the actual Terminal Servers or within the actual VDI sessions.
Antispyware / malware
I’m kind of hoping that Terminal Server sessions are already locked down so that normal users can’t install anything, so I think this is moot there. For VDI, I guess this depends on whether you’re using persistent or non-persistent images. I would guess with non-persistent (where they’re blown away each night), you wouldn’t need it, because anything that’s installed will be lost on the next connection. (This is different from antivirus, which you would still need, since a virus that became active in a session could do damage even if it was lost on reboot. Check out Tim Mangan’s post from a few months ago about this.) But if you have persistent images, I assume this means that users can install their own apps, which means that some kind of antimalware capability would be nice.
I’m not sure this is specifically something that matters, although I guess your antivirus solution would catch anything here.
In a TS or VDI scenario, you get device control at the policy or remote protocol level, so I don’t think you’d specifically need any capability from a desktop security product.
Again this depends on your model and what exactly your users need to do, but I would assume that with a datacenter-based desktop you already have something in place (software restriction policies, etc.), so you wouldn’t need to pay extra for this. (If you’re using a user environment management product, like something from RES Software, AppSense, or triCerat, you already have this anyway.)
I don’t know.. what do people usually do here? I can’t imagine that it makes too much of a difference either way. My sense is that enabling it would just lead to more management headaches and helpdesk calls in the long run, and if we’re talking about users who are behind the corporate firewall anyway, then why bother? Then again, if one of the peer-to-peer viruses did get through, the firewall running in each VM would be nice. Of course Windows now has this built-in, so you can enable it for free without having to buy one of these tools.
The bottom line for datacenter-hosted desktops
Antivirus is a must at some level, but you can probably get away with not using anything else.
Virtual desktops running on client devices
When you move the virtual desktop out to the endpoint, now it becomes more important to get a grasp of the security. But even in this case I would say “it depends” on a few things. First and foremost, I think there’s going to be a big difference between how you secure a virtual desktop running on a desktop PC in an office versus on running on a laptop that could connect from anywhere.
I’d imagine that the office-based PCs would be secured in much the same way as datacenter-based virtual desktops (since both are behind the corporate firewall, etc.). But as for virtual machines running on portable laptops—now we’re getting more like the Wild West.
(Of course the irony is that a lot of people might be using desktop virtualization specifically to increase the security of the virtual desktops, so if you have to still buy all these extra security tools, you might be wondering about what’s the point?)
Let’s look at what specific security capabilities we might want for virtual desktops running locally on mobile clients.
Antispyware / malware
I’m not sure this matters, but I guess it couldn’t hurt. Really it would depend on what your use case was (Type 2 VM running on unsecured Windows versus a client hypervisor, for example.)
Again, you’d have to think about what you were actually protecting. I think every client VM scenario has built-in device control for the corporate VM that you’re concerned about. But do you care about random devices plugging into the host OS? Probably not. (After all, this is probably why you’re running a client-based VM in the first place—you can protect the VM and ignore the host.)
This is probably the same as with datacenter-hosted desktops. The application lockdown is really more of a desktop virtualization architecture decision, and something that would (hopefully) have been addressed in your core architecture before you think about security. (Yeah, yeah... security shouldn’t be an “afterthought,” I know.. but it’s true.)
I’d say this is mandatory for portable devices, although again you have some choice as to where it’s implemented depending on the specific type of architecture you choose. If you have a client hypervisor, then it’s going to own the NIC and handle your firewall duties. If you’re running a corporate VM in a Type 2 environment on an unmanaged host, then I’d say you want to enable the firewall in your Windows VM and/or at the VMM level and just sort of “assume” your host is insecure.
So yeah, that’s just a whole lot of “it depends,” but really it’s true. It looks like if you wanted to boil this all down into a tweet, it’s that AV is still critical and the rest can probably be designed around, but the real answer requires more than 140 characters.
I’d like to close by sharing a few random thoughts about virtual desktop client security:
- If you don’t plan on running antivirus software in your VMs, be sure to at least run a scan against your master image before you seal it up. (Actually that’s probably a good idea regardless.) Thanks to Gabe for that tip.
- Remember (as we learned from Tim) that non-persistent disk images can still suffer from the so-called “day zero” problems, so just because you can easily blow away and refresh an image doesn’t mean you can ignore security altogether. (As Gabe says, “Non-persistent is a good method for dealing with bad things once you’ve been screwed, but it does nothing to prevent you from being screwed in the first place.)
- We’re still hoping for some kind of VMSafe-like API so we can run these various security suites at the hypervisor level (either server for VDI or client), but for now this isn’t really there, so if you want AV in your VMs then you’re going to have to run it in each VM.
- Finally, remember that probably 99% of all security threats can be eliminated by (a) not letting your users run with admin rights, and (b) removing “execute” permissions from the users’ temp folders and home drives.
So what do you think? Did we cover everything, or are we missing something? Are you running any of these client security suites for your existing physical desktops? And if so, do you plan on porting them to your virtual environments?
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.