If you read the last part of my "VDI and TS are not more secure than physical desktops" series, I left off discussing the various ways of performing isolation and how each approach works. I spoke about some of the challenges with each of these isolation approaches, particularly around usability. To continue this conversation, it's important to discuss persistent vs non-persistent operating system instances. If you missed the first parts and need to catch up, check out the previous articles:
- Part 1: There's Only Two Types of Data
- Part 2: Centralization Helps in Other Ways
- Part 3: Mitigation Strategies for Data Security
- Part 4: Security by Isolation Methods
Before we dig into the details into the security ramifications of Persistent vs Non-Persistent VDI or Terminal Server, I think it's important to spend a bit of time describing what the difference is between Persistent and Non-Persistent operating systems. Keep in mind that the ideas behind persistent vs non-persistent applies equally well to VDI and Terminal Services and can even apply to physical desktops.
Persistent Desktops are desktop operating systems whereby the file system of the computer (the C: drive) is configured in a fully read/write supported model. This does not necessarily imply that the user of this system is an administrator, and in fact they should not be. Rather the model implies that the contents of the file system and the registry are persistent between reboots of the operating system.
There are several benefits of having a fully persistent disk model:
- If you need to install operating hot fixes, you deploy them using a tool like SCCM, LanDesk, Altiris, etc and the hot fixes install on the OS. When the OS is rebooted, those operating system hot fixes are still in place. If you A/V agent needs to update it's signature files (aka DAT files) it does so throughout the day and upon rebooting the PC, the most current DAT files are in place.
- If you need to have unique pieces of software on a per user or per working team basis, persistent disk images help. For example, if only 5 people in my organization need Adobe Creative Suite then I can push the installation package of Adobe Creative Suite to their 5 desktops (whether physical or virtual) and the software will exist only on the C: drive of their computers and not on any other system. Proponents of non-persistent images would argue that this could easily be accomplished through the use of Application Virtualization and/or OS Layering technologies. I would agree that this is true sometimes. However, Application Virtualization / Layering both have performance overhead and they won't necessarily work for all types of software (depending on the solution) and therefore they are not a 100% solution. Pushing software for direct installation is still the most broadly acceptable solution to support all needs.
- If you need to stagger deployments of software it's pretty easy to update machines within dynamic collections of systems and slowly complete the rollout of a new piece of software.
There are also several disadvantages to having a fully persistent disk model:
- Since each system has it's own persistent copy of it's C: drive contents, you can have a massive disk footprint within your data center. Think about it, if each VDI desktop is a 50GB disk image and you have hundreds or thousands of these, then you will require 10s or 100s of Terabytes of storage to support your VDI project on persistent disk images.
- As each system is built up of multiple software installs followed by uninstalls follows by new installs in various different patterns you can run into situations where individual desktops experience problems with failed software installations or failures in removing software cleanly.
- Deploying new software updates requires the software to be packaged and pushed to each machine individually. Depending on whether the machines are powered on when the distribution is to occur and various issues related to the health of the machines could result in less than 100% success in the rollouts.
Non-persistent desktops are desktop operating systems whereby the file system of the computer (the C: drive) is configured in a way such that writes to the file system are not preserved. This can be accomplished in a variety of ways, but generally speaking there is either a write filter within the VM that redirects writes to an alternate location where they are not preserved upon reboot, or this is done at the hypervisor level by creating a snapshot/clone/differential disk whereby the changes are discarded upon reboot. Non-persistent desktops are often associated with a term called Common Image where multiple non-persistent desktops are leveraging the exact same image file. In this circumstance, all desktops built from this template have the exact same file system contents and upon reboot they all revert back to this clean slate.
There are a few benefits of having a non-persistent disk model:
- Since each system reverts to clean slate each time it's powered on, you never have to worry about an end user breaking an application by deleting important files or removing important registry keys. Even things as simple as a user reconfiguring an application can be reset back to the application's proper configuration with a simple reboot.
- Since each system is leveraging the same disk image as it's starting point, you can save substantial amounts of storage space. In the persistent model above we talked about 10s or 100s of Terabytes of storage. In the event you had 1,000 desktops sharing the same non-persistent disk image, then you would only have 50GB of storage on the back end to support those 1,000 desktops. You can achieve massive storage space savings as well as IOPS reduction since the blocks of data that make up this disk image can be cached by the hypervisor or storage subsystem.
There are also several disadvantages of the non-persistent disk image model:
- If you deploy all desktops off of a common image, then all of those systems need to contain the exact same set of applications. You could theoretically include additional software and control access to the various executables using a Software Restriction Policy or AppLocker, but your software vendors may decide that the mere installation of the software in the disk image constitutes license consumption. If this is the case and you can't handle the one-off application needs via Application Virtualization or other technologies, then you will be forced to create multiple different images per permutation/combination of unique applications. In low complexity environments, it's very likely you can support 10s or 100s of users with 1-10 unique images. When you try to scale a solution like this to environments that contain thousands or tens of thousands of desktops and hundreds or thousands of applications, it will be extremely difficult to support these systems without having tens to hundreds of different unique desktop images that you need to maintain.
- Since non-persistent disk images revert to a clean slate with each reboot you'll need to be careful with respect to how you manage operating system hot fixes and anti-virus updates. If you revert to a two month old image, the OS will boot up with out of date OS hot fixes and A/V signatures. You may have processes to update the DAT files, but that won't work well for A/V software updates or OS hot fixes since those will typically require an OS reboot to apply. If your organization has audit requirements to report back on OS hot fixes an A/V updates you will be constantly updating your disk images to keep them currently. If you have many disk images to maintain this can be quite cumbersome.
- Since non-persistent disk images revert to a clean slate with each reboot, you'll also have to be concerned with any type of user-based preferences or user installed apps that will be lost each time the system reboots. There are methods to preserve some of this content, but those methods don't apply to a pure non-persistent desktop, but rather creates a new category of systems that are a hybrid persistent / non-persistent desktop.
NOTE: You don't need to implement VDI or Terminal Server to achieve non-persistent desktops. You can easily support non-persistent desktops by using a local Hypervisor with snapshot revert capabilities or even on a physical PC with a write-filter software solution or system restore solution like Deep Freeze.
Hybrid Persistent / Non-Persistent Desktops:
We've previously talked about the benefits of both persistent desktops and non-persistent desktops. Some of the weaknesses of non-persistent desktops can be reduced by implementing a limited form of persistence within the model.
Here's a few examples of how you can achieve a hybrid approach:
- Implement a profile management solution that allows you to backup and restore user settings for Microsoft Office, IE and other third party apps. This allows you to keep the benefits of a clean slate desktop while still preserving some basic application customizations to minimize user frustration.
- Implement a disk layering solution to provide the ability to support user installed applications. If the user wants to install their own copy of iTunes, Google Chrome, etc. these can all be supported by leveraging a disk layering solution because the user installed components get installed into a differential disk that is layered on top of the common disk image. Some would argue that this level of persistence destroys the benefits of single common image non-persistent images, but that isn't necessarily the case. You can still achieve storage savings, IOPS reduction and a common set of OS files that will make it easier to update the underlying OS across multiple systems.
Security in the Persistent vs Non-Persistent vs Hybrid world:
Many proponents of the non-persistent disk image model insist that it is a superior solution from an information security perspective because of the idea that if the operating system is exploited and ownership is established, the machine can be recovered simply by rebooting and the OS would be clean again. While I do agree with this statement, I think it places a thin veil of ignorance around the concept of what is truly secure.
Let's analyze this argument in a few ways:
Is it better than a persistent disk that would keep the malware / infection over a long term period?
Does it mean you're safe?
No. If a hacker compromises your system even for 8 hours your data can already be stolen in that time. While giving the hacker 24 months is certainly going to make it easier, make no mistake that the data could be siphoned in much shorter duration than that.
Is resetting a system an effective means of dealing with virus/malware/trojans?
No. There's plenty of people out there who have said "You don't need A/V software on this thin client OS because you just reboot it and the infection is gone." Tell that to someone who has suffered from an Internet worm like Nimda, SQL Slammer, Nachi, etc. By the time that you have rebooted the system, it is already reinfected by another node on the network. There are no arguments from me that having a non-persistent OS does in fact make it easier to recover, but I'm not willing to go as far as to say it's the right way to deal with things. In addition, when we talk about the hybrid model where we are persisting some forms of application data in order to balance clean slate reboots with usability we introduce possible attack vectors where allow re-infection. Take for example, Office document templates. If you were to backup/restore Office document templates to provide higher usability, you create a location where malware can infect a clean system upon reboot as it reads it's normal.dot in from the restored template folder. The hybrid model does provide a better security benefit over the persistent model as there will inevitably be less locations of persistence, but if there is any persistence at all then we open up holes.
Will I get clean desktops every single day with the non-persistent model?
That depends. Some organizations are very good about forcing users to log off daily. Other organizations allow users to disconnect from their desktop and leave applications in a running state. I've worked in some customer environments where a user remained logged into their virtual desktop for nearly four weeks. If you don't have tight controls over user's getting out of the environment then those non-persistent desktops are effectively persistent for weeks on end. Again, while this is still better than a desktop that is always persistent, it's a far cry from the "new PC every day" that vendors often tout.
In summary, there are many different technologies that can be used to improve desktop security. Hopefully this series has helped you understand what the different options are and what some of the pros and cons of each approach are. While I personally love the concept of non-persistent desktops it's also something that is incredibly difficult to achieve within large organizations where I spend most of my consulting time. Also, non-persistent desktops only solve part of the problem and really doesn't address the core problem of trust and protection from malicious code. When the Internet browser and/or email client can be run offsite, it provides a nice level of isolation and abstraction for an organization but it also introduces it's own set of usability issues.
Today there is no perfect solution. There's a bunch of different options. You need to look at all of the options and balance them against your organization's level of risk acceptance and usability impact to determine what the right solution is for you. Nothing is guaranteed to be secure. All we can do is strive to make it more difficult for the hackers. At the end of the day, time is money. The more difficult it is to hack something the less inclined a hacker will be to spend the time to do so (unless you are a REALLY attractive target - then you need to rely on your information security practices to help you). Good luck…you'll need it!