User experience drives virtual desktop deployments and can either make or break them. If the user experience is awful, users will find other, often less secure methods for doing their jobs. VDI sits at an interesting crossroads where storage, memory, networking, CPUs, and GPUs must be properly tuned. Any adverse impact from any one of these resources could spell the doom of a virtual desktop user experience. The ProjectVRC team and others have taken a comprehensive look at potential adverse impacts, but they have only examined security from the viewpoint of those who implement antivirus and anti-malware solutions. While this is valuable, they do not cover the grander picture of security around virtual desktops. Even today, many years and versions after virtual desktops were first implemented, there are still fundamental functions missing in the realm of security. 

What Is Missing?

  • A method for achieving active per-user policy enforcement: None of today’s virtual desktop management tools currently integrates with security tools so that we know when a user logs in, when they disconnect, and when they log out, so that a per-user, per-device security policy could be applied to the desktop.
  • A measurement of the impact of security, logging, and auditing when placed into the VDI environment: There have been limited tests showing how certain antivirus/anti-malware solutions work, but none for other security tools or approaches such as data loss prevention (DLP), intrusion detection systems/intrusion prevention systems (IDS/IPS), encryption, in-VM firewalls, external firewalls, next-gen firewalls that understand user context, etc. Each one of these tools could impact overall user experience as well as density of desktops per host.

Where We Are Today

The state of the art for securing virtual desktops today is to place like desktops (based not just on user, but on applications) into containers that are protected by different firewalls and security tools. For example, you may have a container for external web browsing and other internet-facing technologies. In this container,  applications are delivered as seamless remote sessions using something like XenApp, while a second container is for accessing standard applications that do not use or access data that could be considered classified. Other containers  allow access to data that has a higher classification. The containers are around inside-out desktops (desktops used to access the Internet), outside-in virtual desktops (desktops used and accessed from the Internet), and inside-in desktops (desktops used to access applications within your environment). When you use containers of these types, you must realize that anything outside a container is considered the wild, regardless of where that container lives (in your data center or outside of it).

  • With inside-out virtual desktops, the desktops themselves live within a DMZ container. These desktops are locked down so that no new code can execute using GPOs or other tools. Anything going out of that container goes into the wild, and we do not want “infected” data going from there deeper “inside.” There are, however, cases where going further inside is required. This is, in effect, changing from a lower level of classification to a higher level of classification, and as such, it needs to be a one-way communication of well-vetted data. “Well-vetted” could include active scanning and removal of any executable parts.
  • With outside-in virtual desktops, the desktops themselves live within a DMZ, where they are also locked down so that no new tools can be installed and no data coming in or data further inside can live. Once more, we need to move further inside to use the applications that are deeper inside. This is the normal behavior for road warriors, so the applications must exist.
  • Inside-in virtual desktops are in higher classification level trust zones, which are either full desktops or applications streamed or presented to outside-in or other inside-in desktops. In general, these desktops are what replace standard physical desktops. They could have access to external devices or they could even access other types of virtual desktops.
  • Presentation/application servers are generally accessed by inside-in virtual desktops. These are the servers where the data interacts with the application and where the application interacts with the user.
    These containers can live locally or in the cloud, or can be a combination of elements. This is why we must follow the user to the application and to the data the application manipulates. In some areas, it is possible to govern that path, but in the secure hybrid cloud, this can become very difficult. The best way to secure a virtual desktop environment is to understand how the users access the applications and, therefore, the data.

Closing Thoughts

Containerization is a well-known security construct for wrapping items that are either too difficult or old to secure or cannot be secured for other reasons, with a security context that provides control, separation, and segregation based on classification levels, types of users, data accessed, and applications in use. When we scale this across the secure hybrid cloud, we must place security at the intersection of the user, application, and data. When we place containers around virtual desktops, we can do just that, as long as we know how those applications are accessed and which direction we are going: inside-out, outside-in, or inside-in.