Virtual Security: Combating Actual Threats

Securing your guests may be the easiest part of the process. You can use many of the same practices to secure your guests as you would a physical box. These practices include regular patching, using an antivirus, implementing host- (guest-) based firewalls and locking down unneeded services. If deploying a large number of VMs at once, consider using a common template to deploy your VMs. This standardizes your builds and makes securing and managing them easier. If you are deploying a specific application with its own set of security best practices (for example, Apache or MySQL) to a guest, follow those as well. Next, determine the criticalness and/or sensitivity of your guests, and, if necessary, place them in different security domains. It is quite possible to mix guests in different domains on a single host. It's also possible to segment your guests onto different host-specific or physical networks (more on this in the next section of this article).

In addition to any application controls, consider using some form of mandatory access control at the guest level, such as sVirt for KVM. sVirt uniquely labels guest processes running on the host to identify them to the hypervisor. This provides a framework for admins to determine which guests and/or processes are authorized to communicate with the hypervisor (see the sVirt sidebar). If you plan to provide remote access to your guests' OS, determine how your clients and/or admins will do so. Will they use SSH, VNC or remote desktop? Once you have settled on a remote access method, be sure to use a least-privilege model and follow any best practices for locking down your specific solution, such as using nonstandard ports and using certificates.

Once your hosts and guests are in place, regularly monitor your virtual environment. Doing so minimizes incidents of configuration errors or host/guest failures, unauthorized creation of new guests. There are many ways to monitor your virtual environment, but the best is to combine the internal OS logging on your guests with tools provided by your virtualization product (Figure 5). There is also a budding market of third-party products, such as Reflex Systems vWatch, which has extended monitoring capabilities, such as the ability to monitor for change controls and guest software/asset inventorying.

Figure 5. Viewing Events in XenCenter

Also keep an eye on performance. Even with resource allocation in place, hosts can spike due to overpopulation or hardware failures. Most vendors' management GUIs have some form of performance monitoring. Open-source users can use virt-manager for KVM or Convirt to monitor performance on KVM and Xen systems (Figure 6). With reliable knowledge of your host utilization, you can plan future hosts better and improve your ability to consolidate, which in many cases, means improving ROI.

Figure 6. Viewing a KVM Host's Performance Data in Convirt

It always is good practice to automate your systems to alert you to failures or outages. This logic extends to virtual environments as well. Redundancy is great, but if a failure is not acted on in a timely fashion, it can cost you further time and money. Alerts also may help you with any service level agreements (SLAs) and compliance issues (such as PCI, Sarbanes-Oxley and so on). A number of management tools have alerting built into them, but it also is easy to integrate SNMP and other monitoring protocols with a solution like Zenoss to keep an eye on your virtual environment.