Security Risk and Virtualization is layered issue and multi factorial. We have discussed the points descriptively through three separate articles. Just a quick recall – the first article is the most important one as it indexes the points. Second article was on Securing VM and Monitoring VDS. This is the third article of the series and we will discuss the 5th point – Identify the high risk networks and the 6th point – Migrate virtual machines safely.
Security Risk and Virtualization : Risk Network Identification and Isolation
Further complications arise from the cross-linking technique. We might have only one cable, but 30 guest systems. Guest systems should not be able to communicate with each other uncontrollably. So for each machine should have its own VLAN (Virtual LAN is explained here – refer to the layer 3 of the OSI model and are implemented with subnet). Although technically the virtualized switches and hypervisors are supported today, but it is still very expensive – with limited personnel resources it is a problem. However, one should not abandon it, because this would affect the security.
In addition, separate network connections for management, regular users and guests should be defined. For external access to virtual desktops with Citrix NetScaler there is a special security gateway. VMware also has an edge gateway for external requests within the program. New network technologies such as SDN (Software Defined Networking) could improve the situation. New security services would thus be defined on the fly, and might be integrated into the existing security stack.
---
Security Risk and Virtualization : Migrate Virtual Machines Safely
Especially tricky part is the migration of virtual machines. The mechanism may lead to risks if rules are not strictly mantained. An example : Suppose there was a new cluster of VMware ESX hosts installed or an existing cluster to a new ESX Server is extended. This is a new host has no firewall and been rolled out, at the same time it does not coincide with the vShield App.
Then migrate the virtual machine administrator on a secured setup is not really secured by the host firewall, this machine has been provisionally suspended, and administrator immediately receives a notice that these machines operate there in doubt without protection and are therefore are locked. The administrator confirms the blocking, the machine remains excluded from the communication to the installation of the firewall. The administrator clicks at this point pointing away or gives the wrong answer, the machine is actually running on the host unprotected. Considering that human error caused a great deal of safety margins in past, it would be better if VMware has implemented a feature that has prevented the migration of VMs on unsecured hosts and must be turned on each individual case. Small point, but can get magnified.
