In-Depth

Planning Primer: Security

You need to plan for virtual safety just as thoroughly as for physical protection. Here's how to get started.

• By Brian Koerner
• 08/15/2008

Throw in the fact that management and security products for virtualization are still somewhat immature, and you can see why organizations have reason for concern. But with careful planning, you can make sure your organization isn't part of that 60 percent. Let's start by taking a look at some of the security issues caused by virtualization; then we'll guide you through steps you can take to keep the bad guys at bay.

Deployment and Management Issues
While virtualization allows quick server deployment, the downside is that it can also circumvent the kind of controls normally applied to physical devices. Even in an environment with tight deployment policies, VMs are difficult to track and manage-and it's easy to see why; they're essentially systems on the go. As they move through an organization they're often renamed, repurposed and relocated to another physical host and network. If an organization plans on tracking VMs by machine name, IP address and current host residency, it could be setting itself up for failure.

Given the often large number of VMs on a single host, a hacker with access could potentially deliver a denial of service attack against the physical host and every VM on it. But that's not the worst of it: If an attacker can compromise the hypervisor, he could subvert the controls of every VM it controls and gain access to any data the virtual system holds or processes. Though there are debates as to the likelihood of such a scenario, one thing is certain: One physical device hosting multiple systems and services presents a greater security risk to an organization.

Then there are the portability issues. Physical servers are hard to slip under a coat and walk out with. Not so in the virtual world, where a VM can easily be copied to an external storage device, neatly tucked away in a briefcase or pocket and taken out of the building with no one the wiser.

Compliance and Inventory Issues
When it comes to regulatory compliance or contractual obligations, VMs are no different than physical devices. According to Anil Desai, an independent consultant and virtualization expert, "An organization must be able to demonstrate that all of its data and systems adhere to guidelines for compliance. Auditors are likely to focus on the virtual space in the near future and IT departments must be ready."

Though virtualization is new to most organizations and auditors alike, organizations are likely to face future challenges as they relate to compliance with internal security standards, contractual obligations and regulatory mandates such as HIPAA, Sarbanes-Oxley, GLBA and others. It's a daunting list, and requires careful planning to secure your virtual environment. First off, you have to know what's on your network. That means making a thorough inventory.

When starting your inventory, don't assume that because you don't have an official virtualization effort underway there are no VMs running. Often departments will create some VMs, usually to "test out" virtualization and see what it can do. Other times, it may be research and development that does the experimenting. Without a rigorous process in place, VMs can easily get behind on patches and end up being improperly managed. It's critical to inventory your environment and document any and all VMs, whether sanctioned or not. You must know the status of your virtual environment before you can start planning, including the placement of controls for management.

Toward that end, develop a standard set of questions for managers to send down the chain of command. The questions should be aimed at discovering the existence of VMs, when they were created and by whom. Understand their purpose (such as developmental, departmental and so on), their current status and the types of virtualization software being used. Determine any established processes for creation, implementation and management, such as maintenance or decommissioning.

In addition to the human factor, it's critical to use a robust technical tool to provide a complete picture of your virtual environment. Although you can use a software inventory tool to scan for host virtualization software, you should use a quality virtualization-management tool that does more. Candidates here include Embotics V-Commander; Microsoft's Virtual Machine Manager; VMware's Virtual Center and Lab Manager; Novell's ZENworks Orchestrator, VM Builder and VM Warehouse; PlateSpin's PowerRecon (see Figure 1); and ManageIQ's Enterprise Virtualization Management Suite.

Develop a Plan
After documenting your network's virtual pieces, it's time to develop a plan for securing what's there, and what's likely to be on the horizon. Organizations often attempt to use the same processes and procedures to secure virtual systems that they use for physical systems. Although they share some similarities and can be integrated, there are notable differences.

For example, it's rare that a physical server appears without the proper support teams being notified. A physical system typically follows a procurement process, which includes engaging all the proper support personnel so that it has rack space, power and so on. Contrast that with a virtual system that can often be deployed without additional hardware, and may be put into production without engaging the proper support services. This usually results in poorly managed, unpatched and vulnerable systems lurking in your environment. To avoid this situation, your organization's plan should address a number of areas.

Put Processes in Place
Start with a standard, comprehensive governance and deployment approval process that includes these steps:

• Develop a written, official approval process for VMs. Require a governance committee (or at least the approval of the security administrator) to approve the deployment of a virtual system. Approval should be dependent on ensuring that the purpose of the system is understood and that all the appropriate support teams are engaged. Such a process will not only help limit unnecessary systems in the environment, but help you maintain the security in your virtual environment as it grows. You'll know who deployed the system, what was deployed, where it was deployed, when it was deployed and the purpose of the VM.
• Ensure deployed VMs are configured safely. Your process should include a checklist of approved configuration settings, similar to what's normally in place for a physical device. Make sure that your virtual deployments adhere to the security standards of your organization as they relate to OS hardening: the process should ensure that VMs follow the same standards and are not allowed to go live until securely configured.
• Implement procedures for dealing with unapproved VMs. Organizations should be aggressive in eliminating rogue VMs. Some of the tools mentioned earlier can help identify unapproved VMs and be configured to alert a security admin or even shut down the VM.

The Perils of Patching
Virtual systems, like their physical counterparts, must be patched or they, too, will present a security risk to the organization. Patching VMs can be difficult due to the lack of mature management tools, but there are some solid products to consider. VMware Update Manager can automate patch management and eliminate the painful manual patching of ESX hosts and VMs. Update Manager is an automated tool that scans the state of the physical ESX hosts, as well as select guest OSes and compares them with configuration baselines that are set by the security administrator. The tool then applies updates and patches to enforce compliance to your organization's mandated configuration setting. V-Commander and ZENworks Orchestrator provide similar capabilities.

[Click on image for larger view.]

Figure 1. PowerRecon from PlateSpin can show you a number of details about prospective server consolidation jobs, including security status.

Updating Security Policies
As organizations plan their virtual deployments, they often overlook the need to update their security policies with virtualization-specific standards. It seems that because their policies have effective security standards in place for physical devices, they make the assumption that nothing more needs to be done.

That's dangerous thinking, because virtualization's unique security challenges require new standards. For example, your organization may forbid certain types of data to be managed by a VM. As discussed previously, most organizations will need to update their policies with standards related to the deployment and decommissioning of virtual systems. In addition, your organization will have to develop the policies that will be used in your virtualization lifecycle management tool, including management tasks like dealing with unauthorized VMs. For instance, will a VM be taken offline immediately or a sys admin notified? How will the tool deal with a virtual system with patches that aren't up-to-date, or a VM that hasn't been used in the last 90 days?

The Right Tool for the Right Job
Many existing products have evolved to secure and manage virtual environments, and new ones are coming out every day. Here's a checklist of what your management product should be able to do:

• Discovery. It's critical to select a tool that can discover VMs in your environment. This allows you to monitor your virtual environment for authorized and unauthorized VMs.
• Security Policy Enforcement. The tool should provide the capability to configure customizable policies or baselines for virtual systems. Policies can enforce patch levels, configuration settings and proper authorization.
• Patching. Your tool should provide patch-management capabilities so that both the VM operating system and potential applications can be kept secure and up-to-date.
• History. You should be able to track a VM through its lifecycle with information such as past and current hosts, configuration standards, parents and siblings (lineage), relocation and re-purpose information.

Of course, there's more that goes into planning for the security of your virtual environment-for example, getting management buy-in, monitoring and post-deployment considerations. Hopefully, what's been presented here will give you a roadmap for getting started. Remember that security isn't merely an add-on to your virtual environment-it needs to be a central concern in order to do virtualization right.