It’s safe to say, nearly all enterprise network security teams tightly control what physical devices get connected to their networks. Most have clearly defined process and procedures in place with regard to controlling and securing any new devices plugging into their physical networks. Industry statistics show that the vast majority of security breaches initiate from inside the network, and not from an intruder penetrating the perimeter, physical network access control has become standard practice. As a result, it is increasingly rare to allow anyone in an organization to plug in a new server or system without first making sure the new device has been adequately secured in accordance with their corporate security standards including anti-virus protection, firewall policies, etc.  For physical devices, the process begins as soon as the ‘box’ hits the receiving dock; the equipment is intercepted and is put through the process of being secured. Once it’s been properly configured to meet the corporate requirements as defined by the security policy, it’s distributed for deployment. Then, and only then, is it plugged into the physical network.

Enter the virtual system, be it a virtual server or virtual desktop. These devices are nothing more than software however, to users, they look and feel exactly like actual physical devices on the network. At issue is the ease in which these systems can be created and connected to the corporate network. In about as much time as it takes to make a peanut butter and jelly sandwich, a VM administrator can spin up a new virtual server with all of the attributes of its physical server counterpart including nic, disk, memory, etc. However, this new virtual server can be deployed and added to the network without ever being secured by the security process described earlier. Furthermore, because the virtual server is deployed inside the internal network on a VMware ESX host with vswitches and full connectivity to the network it represents significant security vulnerability if it has not been properly secured.

What’s more, because the network traffic traversing inside the virtual network is invisible to network monitoring tools operated on the physical network, the network traffic to and from these unsecured virtual servers inside the ESX host goes completely undetected. The virtual network is in reality an internal network inside the physical network. There is simply no way to see or control the traffic running within the virtual infrastructure.

Companies are exposed to numerous security vulnerabilities and compliance issues because of the high percentage of security breaches coming from the internal network along with the fact that the ESX Host(s) represent invisible networks inside the internal network. Any new virtual server being added to the virtual network is not subject to the same corporate security policy for network access control as physical servers.

For all of these reasons, security teams must take control of their virtual networks. They must ensure that any system, be it physical or virtual, be properly secured. We encourage security teams to explore virtualized security in detail.

Read more on this topic:
"Why Do We Need Virtual Security?"

• Bestselling Author Team Shows Computer Users How to Clean Up and Take Control of Their PCs With Degunking(TM) Your PC
• Third Version of CaseCentral's On-Demand eDiscovery Review Platform Enables Legal Teams to Simplify and Take Control of eDiscovery
• Time Management Expert Julie Morgenstern Reveals How Small-Businesses Owners Can Remain Organized and Take Back Control of Their Work Life