Top Ten Virtualization Risks Hiding in Your Company

What are the management risks and problems hiding inside your virtualization effort? That’s a question that David Lynch, VP of marketing for Embotics, tries to help IT groups answer. Embotics, part of CIO’s recent list of 10 virtualization vendors to watch, provides what it calls VM lifecycle management. The company’s V-Commander software (which integrates with VMware’s VirtualCenter management suite) promises to help you track VMs from cradle to grave. The tool lets IT groups apply policies and automation to that tagging and tracking work.

Lynch recently shared with me a top 10 list that his staff uses when it meets with IT leaders to discuss common management risks and problems with virtualization. The list reflects actual problems that Embotics has found while helping multiple customers audit and secure virtualized server environments.

I find this list thought-provoking, realistic and worth sharing. Check out the below questions and ask yourself: Could any of these problems be hiding in my virtualized environment?

As for how these problems arose in the first place, virtualization bubbled up from a few people in the server or application development group at many companies, instead of being planned top down from the CIO. Then virtualization spread quickly, and spread further into the production IT environment, because IT and business teams liked the results. As that spread continues, IT finds itself now having to step back and get more formal about managing virtualization, to avoid management complexity and security risks.

“Most of our customers have been very busy operationally,” Lynch says, “now they are starting to have to deal with issues of control.”

Now, on to Embotics’ top 10 list of potential troublemakers lurking in virtualized environments:

1. Rogue VMs

How tightly do you control who can create a virtual machine? It’s a key security question. When you fire up inactive or suspicious VMs, you may find more than you expect. One Embotics customer fired up an offline VM to confirm what it was, and found a DHCP server which took down the production network, Lynch says.

2. Unpatched VMs

Remember, users can run VMs on their own PCs using downloadable software from VMware’s website, for example. Audit all of your company’s machines for such VMs and you may find what Embotics customers have, Lynch says: Unauthorized operating systems and a lack of security patches on those VMs.

3. VM Naming Messes

As you track all the VMs in your company, logical names will be helpful. But chances are, IT pros throughout your organization started naming VMs long before you realized how far virtualization would spread, long before anyone thought about imposing a naming system. Think about naming conventions now, Lynch advises.

4. Production Environment Border Problems

Most IT organizations run pre-production VMs (say for application development work, or software upgrade preparation) and production VMs at the same time. If you checked today, would you find any pre-production VMs running in your production environment? It’s time to investigate and shore up this situation, Lynch says.

5. High Availability Hardware Hogs

If your company has hardware tasked to high availability computing, i.e. hardware tasked to the most mission critical work that cannot be interrupted or slowed under any circumstance, that hardware is a precious and costly resource. Are all the VMs running on that hardware related to your HA efforts? Or do you have some VMs on that hardware that are gobbling part of that hardware inappropriately? It happens, Lynch says.

6. Failure to Enforce Security Zones

As virtualization security guru Chris Hoff told us earlier this year, many IT groups have failed to apply what they know about physical security to the virtual world. Lynch agrees: Embotics customers find problems where applications that would have been separated on the physical network find themselves too close in the virtualized environment, he says. For example, one customer found a VM housing a human resources application running next to a Web server application, in violation of the customer’s own security guidelines, Lynch says.

7. Failure to Separate Customer Data

If you’re rounding up customer data and storing it in VMs, are you separating those customers properly and wisely? Lynch cites the example of a hosting company with sensitive VMs from two clients requiring separation: In auditing all its VMs, the hosting company found those two client VMs co-located on the same physical server. Not a good idea, Lynch says.

8. Failure to Restore VMs Properly

Disaster recovery lends itself very well to using VMs; many companies now use VMs to ensure lack of downtime for the business side. When you do restore a VM into the production environment, however, do you have a best practice in place to confirm that it’s restored to the proper location? Lynch says Embotics customers find that VMs can be inserted from backup into the wrong physical zone, again possibly creating security problems.

9. VMs as Application Camoflauge

Consumer IT, including easily downloaded Web applications, will not go away anytime soon. IT departments can set policies banning specific apps of course, but now users have another tool at their disposal. It’s not unusual to find business and IT staffers using VMs to run and disguise unauthorized applications, Lynch says.

10. VM Deadwood

The first step in getting your enterprise’s total number of VMs that have to be managed and secured under control is to do an audit of the whole virtualized environment. At many enterprises, this audit reveals a large number of VMs get created then left to rot and never used, Lynch says. For example, he cites one customer that did a manually-intensive VM audit only to find that a full 30 percent of VMs weren’t being used. One low-tech management tactic that can be used here: Turn off the inactive VMs and see if anyone complains, Lynch says.