The Virtualization Security Podcast on 10/7 was the second in a series of Virtual Desktop Security discussions we are having. The special guest panelist was Simon Graham of Virtual Computer, the makers of NxTop a client side hypervisor based on Xen. On this podcast, we went into the details of NxTop.
The engineers at Virtual Computer have thought about nearly everything when it comes to a Client Hypervisor. NxTop operates as a standalone or as a centrally managed client hypervisor. The difference is fairly stark. I feel that most people in the Enterprise would want to use the managed client hypervisor they have a one off situation. NxTop provides the following security features:
- Encryption of the local hard disks
- No local access to the Xen Dom-0 (Domain Zero).
- Automatic backup of critical data
- Centralized patching
- Policy controls for local and remote actions
- Snapback to a previous golden image
Let us look at each of these features in turn.
Encryption
Virtual Computer’s NxTop allows you to encrypt the entire local disk drive(s) in use but requires the user to enter a password on boot. This is a step in the proper direction and provides an added layer of security to mobile users. Unfortunately, this is a single factor of authentication. When a password is sufficiently complex most people will choose something easy to figure out or will write down the password. What needs to be used is a Pass Phrase and multiple factors of authentication such as RSA SecureID, Common Access Cards, finger print scans, etc. Perhaps all three methods of authentication.
The other concern about NxTop’s encryption mechanism is that it is not centrally managed – each user when they install NxTop onto the platform chooses their own password. A centrally installed computer could be the the same for all equipment, providing for improved password management capabilities.
No Local Access to Dom-0
There is no local access to Dom-0 which implies that the user of NxTop cannot interact with the management component of Xen, however, if they have the encryption password, described previously, then they could gain that access to Dom-0 and make modifications. Granted this is a task most users will not know how to do, but it is possible.
Dom-0 or Domain Zero is the domain in which all the magic of a hypervisor happens. VMs run in Dom-Us or Domain User(s). Access to Dom-0 is like giving the keys to your datacenter to everyone. So this being locked down and unavailable locally is a very good thing.
Ontop of this, there are no open ports or services running within Dom-0. Instead Dom-0 polls the Centralized Management Server as needed (if a CMS is in use). This further limits Dom-0’s contact to the outside world.
TPM/TXT support does not exist yet, to further limit which hypervisor can actually be run on the client. When opensource Xen’s TPM/TXT is implemented within NxTop, the NxTop CMS needs to handle updates to the trusted launch environment for patches to NxTop.
Automatic Backup of Critical Data
NxTop furthermore knows what part of the Window’s Guest Operating system is user data and which part is system data. Virtual Computer has built a rules engine to determine what part of a Window’s Guest Operating System is what. They use this rules engine to periodically backup the Guest’s user data to the central management server. This way if a laptop or desktop running NxTop crashes catastrophically, the user data is not lost.
Centralized patching
Perhaps not unique to NxTop, but just as important is there way of using “chained” virtual hard disks (VHDs) to allow patching of the NxTop windows VMs from the CMS. To do this, the NxTop CMS uses a local Hyper-V server to create the VHDs and then to chain them. These chained VHDs are then sent to the client. On next boot of the VM uses the new chained VHDs. This is very similar in notion to how VMware snapshots work. What I find interesting is that NxTop runs XenServer but to use the CMS to do centralized patching and VM creation it makes use of a Hyper-V server. Now if you add in a VMware View client within one of the NxTop VMs you have VMware vSphere also involved and you will have to secure and audit all three hypervisor’s appropriately.
Policy controls for local and remote actions
NxTop includes policy controls for whether or not a local VM can access CDROM, USB, and Serial Port devices. If the Policy is enabled you an make use of the devices. If the policy is disabled the devices are not seen by the VM. However, denial will also require BIOS changes to ensure a reboot of the local desktop does not allow someone to boot from an external device.
Snapback to a previous golden image
NxTop also has the ability to Snapback to the well known golden image on reboot of the VM. This allows a VM to download and make any necessary changes. Once the VM is rebooted all those changes are discarded. This is a very interesting technique to recover from accidentally deleted files, or from malware being installed on a NxTop VM.
Conclusion
All in all NxTop provides a total solution (if you include the CMS) to the problem of maintained client hypervisors. However, there is still more work to be done:
- Support for SecureID, CAC, and other 2-Factor authentication devices
- Support for TPM/TXT to ensure there is a trusted launch of the appropriate hypervisor
- Appropriate hardening guides for the full environment, not just the XenServer aspect but BIOS and other necessary settings.
- There is a mix of hypervisors in use: Perhaps all three of the major players.
Policy controls, snapback, use of Application Virtualization are all useful security features. I look forward to seeing NxTop improvements to add some of these missing features. Even so, it is a good start.