If my CIO had his way, he would move the entire company to a virtual desktop environment. In his mind, it would be a cure-all for the costs of supporting thousands of PCs and the headaches caused by software distribution, security patching and configuration management.
It may do all of that, but naturally, as a security professional, I'm focused on how a virtual desktop infrastructure would affect our security posture. Thus, I spent the week developing security requirements for a VDI deployment.
Our VDI deployment would involve installing a small software plug-in on each PC. When such a PC is connected to our internal network, a virtual desktop environment will run on top of the PC -- a Windows desktop displayed within Windows.
So, how does that affect security? That's what I pondered as I set up my requirements, and my conclusion was that our security posture should be unaffected, and possibly enhanced, but only if VDI is properly implemented.
My first and most important requirement is that data can't be allowed to move in either direction between the virtual desktop and the host PC or any external devices.
Next is the question of the integrity of the host PCs. No one should think that VDI will free us from the headaches associated with configuration management, patch distribution and anti-malware software updates. That's because in our deployment, VDI is simply an application that runs on a PC. The PC still boots up into a Windows operating system and may or may not be attached to our company's network. Yes, VDI deployed in this way will allow for centralized configuration management, but it will do nothing for the host PCs. Security patches and antivirus updates will still have to be applied to the host PCs.
And speaking of centralized configuration, one size should not fit all. The virtual desktop environment of a general employee shouldn't be the same as the virtual desktop environment set up for a contractor, partner, supplier, vendor or other affiliate. I don't want to require a plethora of profiles, but some high-level order will need to be in place to satisfy my "rule of least privilege" requirement so that we don't expose critical applications and data to unauthorized people.
Another consideration for me involves the log-on banners that users must read before clicking "accept" and logging in. We can't lose this feature, since we have a legal requirement to let users know about their responsibilities and our practice of monitoring activity.
More Worries
We also can't compromise our remote access policy, which calls for two-factor authentication and the use of a VPN. This is necessary because I can't vouch for the integrity of, say, the Internet kiosk in Moscow. I have to assume that every PC is compromised and that keystroke-capture software and a sniffer is installed. Two-factor authentication and a VPN are our current means of reducing that risk.
The same goes for application and screen timeouts. With employees all over the world, we can't ensure that someone won't walk away from his PC from time to time, leaving some sensitive data exposed in a running application. For that reason, we force a timeout, and the user has to log back in with two-factor authentication upon his return.
Finally, we need the ability to identify the relationship between each user and his issued VDI, as well as exception alerting to keep us informed about any suspicious activity (such as a user launching an excessive number of VDI environments, logging in from a location inconsistent with his profile, or making multiple access attempts).
Did I miss anything? Let me know.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.