While mobile and smartphone security is the hot topic of the moment among virtualization security gurus, plenty of other \n\nvirtualization security topics demand IT's attention right now. At the recent RSA Security Conference in San Francisco, the \n\ninterest in virtualization security ran high with good reason. Different IT departments are at different points on their \n\nvirtualization journeys, of course, and some are still thinking about security in the old physical world terms, analysts \n\nsay."There's still a lot of question about how to approach security on virtualized servers," says Phil Hochmuth, program manager for \n\nsecurity products at IDC.By 2012 half of all the workloads run in corporate data centers will run on virtualized platforms \u2014 whether virtual \n\nservers or cloud platforms; by 2015, 40 percent of the security software that controls inside corporate data centers will be \n\nfully virtualized, according to a November, 2010 report from Gartner. Basic security tools such as intrusion protection don't work well with virtual machines because they're harder to define \n\nby geography, IP or MAC address, and it's hard for external software to see or filter communications between VMs on a single \n\nphysical server, notes Neil MacDonald, VP and Gartner Fellow, who co-wrote the report. With most tools, it's hard for IT to even know how many of the VMs on a particular server even have all their patches up \n\nto date, Hochmuth says. Here are some virtualization security questions to consider when making plans for your environment:\n1. Is a slow server is safe server?\nJust as in physical servers, adding security software adds to the workload, eats resources and lowers performance. \n\nVirtualized servers make more efficient use of their resources than physical servers, but that doesn't mean it's obvious \n\nwhere and how to apply security. "It sounds pretty basic, but there is a lot of disagreement about whether it's better to have agents inside every virtual \n\nmachine to secure them, or if that's too much of a drain on resources and that having something that can watch a group of \n\nVMs is better," Hochmuth says.Run an agent on each of the 30 VMs in a quad-processing server and you get overhead equal to running 30 copies of the \n\nsecurity software \u2014 because that's what you're doing. The other major alternative \u2014 running one piece of software on the physical server that can observe all the VMs and \n\ntheir operating systems \u2014 is more elegant in concept, but may not be as secure, or may not be all that efficient \n\neither.Hochmuth recommends "a really pragmatic proof of concept" comparing the impact on performance of several vendors' \n\nproducts. Even if the test tells you nothing about how good the security is, "it will tell you which products bog down the \n\nparticular workloads you're running more than you find acceptable," he says. \n2. Should you even let the VMs talk to each other without encryption?\nVirtualizing servers means more than just being able to cram several operating systems into one box; it means creating a \n\nnetwork inside that box across which the VMs have to communicate with each other, applications running on other servers, and \n\nthe Internet, according to Matt Sarrell, executive director of security test\/analysis firm \n\nSarrell Group.Much of the drive toward encryption in virtual environments comes from organizations that need to be able to demonstrate \n\na good chain of custody for data under HIPAA or other privacy regulations, according to Sarrell. That same encryption can help lock the doors on malware that can infect a hypervisor or OS on which a VM runs in a data \n\ncenter, however, keeping the rest of the VMs safe even if one is compromised. Encrypting data streaming to and from VMs running in either a public or private cloud can also reinforce the doors \n\nbetween your VMs and the neighbors' in public clouds, Hochmuth says. "Shared-server public clouds are like living in an apartment building, so your security may depend on how safely your \n\nneighbors are acting," he says. "Encrypting your VMs and the data can make that situation a little more secure, but again, \n\nat a potential risk of a performance hit."\n3. Do you know who or what is asking for data?\nSecurity policies linked to MAC or IP addresses don't work well when the entities in question are virtual, according to Gary \n\nChen, research manager for IDC's Enterprise Virtualization Software group.When apps run on virtual machines the security has to take into account who wants access, what they want to access, when, \n\nwhere and from what device they want access, according to Gartner's MacDonald. Only in that context can a security policy remain effective rather than firmly locking down a piece of sensitive data \n\nexcept if a new or untrained employee who has secure access at the office decides to download it across an unencrypted WiFi \n\nconnection to an unsecured laptop. Virtual machines should be able to enforce the same level of security policy on one another, and on public or private \n\nclouds, applying the company's security requirements according to the context in which data is being requested, not what MAC \n\nor IP address sent the request, Hochmuth says. \n4. Are you scrutinizing the in-between spaces?\nRunning virtual servers means running an additional operating system \u2014 VMware's vSphere, Citrix' Xenserver or \n\nMicrosoft's Windows Server 2008 \u2014 that can be attacked by hackers or malware designed to recognize and respond to VMs \n\nor hypervisors, Chen says.Malware can not only spread to virtual machines through their connections to the Internet, it can spread among them once \n\nit's infected a VM inside the firewall, or inside a physical server \u2014 especially if the VMs are set up for fail-over \n\nor disaster-recovery support that gives them special access to one another, Chen says. \nEncrypting data or identity-protecting it can rebuild walls between servers to keep data safe, even after virtualization \n\nsoftware has torn them down to let them share quarters, data or workloads, Hochmuth says. NIST's View of the BasicsJust like physical servers, virtual servers have to be patched, configured and maintained according to organizational \n\nrules that define levels of security so sloppiness or inconsistency doesn't open a hole that negates the whole effort, \n\naccording to a guide to virtualization security issued yesterday by the U.S. National Insitute of Standards and Technology (NIST).A summary of its guidelines:\n1. Secure the hypervisor just as you would an operating system; if functions like an OS and it's vulnerable like one. \n\nHoles in it make everything running on it vulnerable.\n2. Establish consistent guidelines to configure security on virtual and physical machines, and a process to verify the \n\nguidelines are being followed. \n3. Extend patch and vulnerability management processes to cover VMs as well as physical machines.\n\nFollow everything from CIO.com on Twitter @CIOonline.