Enterprise desktop virtualization offers the promise of providing a more cost effective and manageable solution to the current scenario that most organizations deploy: a physical system per user. The ability to have "desktops" that can be created, dismantled, reconfigured, patched and managed in a dynamic manner is very attractive. As companies look to deploy this technology, they will need help in understanding the nuances that will ensure the security is equal to or better than their current physical deployments. In this tip, we'll look at the most common security issues that solution providers run into when deploying virtual desktops for customers. Then, we'll explore a desktop virtualization deployment strategy that offers practical ways to solve them.
What are the desktop virtualization threats?
In this new virtual world, the loss of the physical boundary creates three main vulnerabilities that you, as a service provider, must address:
Authentication: In a traditional desktop environment, a username with a reusable, sufficiently strong password is considered adequate for authenticating a user onto that system. In a virtualized environment, the additional mitigating control of physical possession is no longer present. Authentication mechanisms must take this into account.
Transport protection: The loss of the physical system places increased responsibility for protecting information as it moves through the network. Information previously stored within the system that wouldn't be seen outside the system boundary, now traverses the network.
Data protection (specifically confidentiality, integrity and non-repudiation): In a physical system, it's easy to ensure no one has access to information that they shouldn't. Think of it in terms of a chain-of-custody: If a network is unplugged and a system is locked in a safe, for example, it's fair to say that any critical information is in a secure place that can easily be verified. This is not the case in many virtual desktop scenarios. Hypervisor administrators, for example, will have access to the "system" even when it is powered off and disconnected from the network. This new paradigm must be accounted for.
There are many other issues, but these three concerns are critical not only to real security, but in meeting compliance and regulatory requirements as well. For example, the Payment Card Data Security Standard (PCI DSS) requires that cardholder data be protected while in transit. If a desktop application uses cardholder data, and the communication link between the thin client and the virtual desktop is not protected, you would be in violation of that requirement.
What are the best solutions?
So what are the best desktop virtualization solutions you can offer as a service provider? The answer, as always, really depends on the deployment and the customer. Are you using VMware? XenDesktop? Microsoft RDP into a virtual machine? Individual blades or multiple VMs on a system? All of these will have specific implementation differences, but there are some general guidelines that you can use for your customers that should work regardless of their specific implementation.
From a service provider's standpoint, you first need to determine if the connections between the thin client and virtual desktop are over a trusted network (i.e., internal network) or if ANY part of the traffic passes over an untrusted (i.e., public) network. For service providers' purposes, all public networks are untrusted, and some private networks may be untrusted as well. You should ensure the authentication mechanism has appropriate strength for the type of network the credentials traverse. Ideally, you would deploy a two-factor authentication solution for anything passing over an untrusted network.
Other items you will likely encounter include:
- Heterogeneous desktops that require different authentication solutions.
- A customized "single sign-on" environment that requires physical system access.
- Customers who desire a single sign-on environment with their virtual desktops, but currently have separate authentication sources.
As a solution provider, it is imperative to fully understand your potential customer's environment: What authentication sources do they currently have, what do they want, and will their implementations involve customized code? Then, once you know what you have to work with, you can determine an action plan for meeting their needs. Can you modify your solution to meet all of their needs? If not, what can you do to get as close as possible? After you have the plan, you can propose it to the client. Since every installation is different, I cannot provide specifics, but you will need to answer the following questions at a minimum:
- What type of virtual desktop s will be deployed?
- What are all the authentication sources?
- What are the compliance requirements for authentication?
- Is there any custom code written for authentication? If so, get details.
The second challenge you will need to address is protecting the network traffic. As a service provider, your customers will be looking to you for guidance. My recommendation is to point them to Secure Sockets Layer (SSL), Transport Layer Security (TLS), or IPSec as the preferred mechanisms to provide this protection. Do not rely on "home grown" encryption products. Publically vetted crypto is best.
Two defenses come to mind: key management and intrusion detection. You will have to provide your customers with a mechanism that allows them to easily and securely manage the encryption keys for the solution you propose or deploy. This includes how they will recover those keys for disaster recovery or business continuity. Secondly, because you have now protected all the traffic, most intrusion detection deployments will be of little use. You will need to consider how you can integrate with their current IDS (i.e., provide decryption keys to the IDS sensor) or propose an alternative (such as host -based IDS on the virtual desktop). Not addressing this would be a disservice to your customers.
One last piece of advice: Strongly suggest the use of transport-layer protection regardless of whether you trust the network or not. I guarantee that your customers' users will not be thinking that all of their key strokes are passing over a network; do them a favor and make sure they don't pass over it in the clear!
The final piece is protecting the data in the "system." It's important to provide a mechanism that will assure users the data they leave on their desktop is only accessed by them. An example of this would be using something like PGPdisk, where the user's information is encrypted and after a user logs in, he or she would have to enter a password to open the encrypted "disk."
As a service provider, you should provide an offering that allows users to secure their data from any prying eyes. As stated earlier in key management, you will need to provide an option that allows the user or business to recover that protected data in the event of a disaster. For example, you may suggest using Windows Encrypting File System (EFS) as that mechanism, so part of your process would be to back up the EFS key or configure a recovery agent key. Further, any design that stores keys on smart cards or USB keys would give a level of assurance that does not typically exist in the virtual desktop deployments I have seen.
The security needs that customers will look for during a desktop virtualization deployment typically revolve around:
- Integrating authentication sources.
- Ensuring that once local, now remote data is adequately protected.
- User actions being protected.
- Customers' ability to comply with contracts and compliance regulations.
Customers usually have a handle on the whole user experience, as well as performance issues, but they tend to not have in-depth knowledge of the technology to adequately address those security concerns. Help your clients with these, and you will put them in a good position to be secure and compliant.
About the author:
Phil Cox is a principal consultant of SystemExperts Corporation, a consulting firm that specializes in system security and management. He is a well-known authority in the areas of system integration and security.
His experience includes Windows, UNIX, and IP-based networks integration, firewall design and implementation and ISO 17799 and PCI compliance. Phil frequently writes and lectures on issues dealing with heterogeneous system integration and compliance with PCI-DSS. He is the lead author of Windows 2000 Security Handbook Second Edition (Osborne McGraw-Hill) and contributing author for Windows NT/2000 Network Security (Macmillan Technical Publishing).
Join our SearchSecurityChannel.com LinkedIn group, and share your expertise with your peers.