Locking Down Applications in a VDI and Session-Based Virtualization World

In previous blog posts we looked at various technologies to control applications running on desktop operating systems. The newest and most promising of these is application whitelisting, which provides the best protection while still allowing users the flexibility needed to run the applications they want.

Many people say we are in the post-PC era because workers are augmenting the PC – still the primary work tool in most organizations today – with other tools like mobile phones, tablets and the like. In addition, we are also seeing the effects of the “Consumerization of IT” where users are bringing their own devices to the workplace to perform their day-to-day duties. To enable these new scenarios, organizations have to either give users a complete remote desktop or just stream the necessary applications to these devices to enable remote access. Installing the applications on these devices is not normally an option, since either the devices can’t run the applications natively (e.g., Android and iOS type devices) or we simply don’t want to install corporate applications on non-corporate assets.

There are two solutions to enable remote access to applications: Virtual Desktop Infrastructure (VDI) and session-based virtualization (which many of us know as Terminal Services). Regardless of which way we go, we will need to provide the security afforded by application control. And there are several considerations when locking down our applications in either scenario; but let’s take the easy one first.

In a session-based virtualization scenario, we have a number of server operating system instances (such as Windows Server 2008 R2) and we enable the Remote Desktop Session Host role (formally known as Terminal Services). We may also add services such as Citrix and Quest to expand functionality. We install the applications that we want to offer on the server OS and then users connect — either getting a complete desktop or just the published application. The key here is that many users are connecting to the same OS instance and are isolated at a session level, so the users have to be highly restricted. The users cannot reboot the OS or change the OS in any way, which includes adding or removing applications.

Imagine a user on a Remote Desktop Session Host decides to change an application or just run some application from a file; this would affect everyone else on the server, so we can’t allow it. We therefore use policies to severely restrict users’ rights in any type of session-based virtualization – so they can only run the installed applications and that’s about it. In addition, in order to provide maximum protection, we should also use an application control or whitelisting solution. This prevents users from running applications that don’t require installation (like many types of malware today), which provides an additional layer of protection in case of an unintentional error (e.g., we missed some lock down steps while creating our session-based environment) or a deliberate attack.

The other option to give users a desktop and the necessary applications remotely is Virtual Desktop Infrastructure (VDI). With VDI, each user actually has their own instance of the corporate client operating system running inside a virtual machine (VM), which is not shared. Normally users have more privileges in these VDI environments, since they tend to be power users and since they have their own OS (meaning they can’t affect other users). However, we still need to treat these VDI environments like desktop machines. We need application whitelisting in place to prevent users from installing and running applications that are not appropriate – or outright dangerous – for the corporate environment, while still giving them flexibility to run necessary and approved applications.

Hopefully we see a trend here. Whether the operating system is physical or virtual, shared or personal, we can and should use application whitelisting technologies to keep our environment and users safe.