The most recent Virtualization Security Podcast was on the subject of virtualization security for the SMB. Specifically covering the case where the customer wanting virtualization security could afford to purchase a hypervisor and perhaps one other security product. In the end the panelists came up with a list of suggestions for virtualization security for the SMB that are applicable to all levels of Virtualization. The panel looked at SMB security with an eye towards Availability, Integrity, and Confidentiality.
The list follows:
- Download/create a Security and Incident Response Policy: It is very important to have a policy as this will not only let you know your responsibility and legal coverage but will also contain what you need to do if there is a security incident we respect to your data and environment.
- Segregated your virtualization networks from production networks: Virtualizition Networks are not virtual networks but those networks required by the hypervisor functionality such as Management Appliance, Fault Tolerance, High Availability, LiveMigration/vMotion, and Storage virtual networks.
- Choose Hypervisor with minimal security toggles, etc. (less moving parts so to speak): Choose a hypervisor with less moving parts, such as VMware ESXi or Microsoft Server Core, however, this may just be a false sense of security given the END-402 talk at RSA Conference 2010.
- Follow any Hardening and Security Guidance from the Vendor specific to the Hypervisor chosen: This is an absolute must, also investigate CISecurity and the DISA hardening guidelines.
- Determine if you need LiveMigration/vMotion based on downtime requirements: In some cases if after hours downtime is allowed, then LiveMigration/vMotion/Storage vMotion, may not be applicable. This is a question of availability. If you cannot afford downtime, then you may want these technologies.
- Choose High Availability solutions to handle failed host situations: This is an availability concern solution.
- Make a Backup using normal in VM backups or virtual disk backups. External virtual disk backups are easier to recover and Backup off site: It is far easier to restore a entire virtual disk than it is to restore a traditional backup. Not only does this preserve the integrity of the data within the VM but also improves recovery time.
- Keep log files for 2-4 weeks unless regulatory compliance states otherwise (in case there is an incident): Also, invest the time or money in a log file analyzer that understands virtualization. This will aid in quickly discovering problems.
- Understand how vNetworking works: Many people have misunderstood how vNetworks work and integrate with the physical network, which can cause misconfiguration, and bad security choices. There are several good references on vNetworks provided by the vendor, third party books, or on this site.
- Keep your VMs and hosts up-to-date: In other words, apply any applicable security patches to your virtualization hosts and to your VMs.
However, the question was asked, how is this different than any other security recommendations? And the answer is only in one area, which is the ability for the VMs to Escape and possibly control a hypervisor directly. This has been the biggest fear by almost all security practitioners and for the Type 1 hypervisors used within the data center it is a major concern. So what can we do about this? First we need to understand the current attacks of which there are 3.
- Amazon EC2 attack (Xen) which inspected the virtual CPU cache to determine which other VMs were on the same host. This worked because the vCPU cache was the physical CPU cache.
- VMware Server Type-2 attack which allowed a VM to run ‘notepad’ from with the Host. Granted this host did not enable NX/XD (No-eXecute/eXecute-Disable) bits within the processor and did not use Address space layout randomization (ASLR) which most modern Type-1 hypervisors now require, these are not sureties, but will reduce some of the possible attacks
- VMware ESX paravirtualized driver was corrupted which caused the attacking VM to crash
So the current solution to the VM Escape issues is to use NX/ASLR enabled hypervisors to make things even more difficult for such an attack and to not use para-virtualized drivers unless absolutely required or be picky about installing them. For example, if your VM is not a desktop, is the paravirtualized VGA driver (the one most attacked) absolutely necessary?
In the end, Virtualization Security for the SMB is vigilance. Be vigilant and understand your environment. This sound advice also applies to all businesses.
Comments are closed.