Over the past year or so I have been thinking pretty heavily about the direction networking is taking within virtualization. In some ways, it appears security has been forgotten or relegated to ‘encrypt’ and forget. However, it takes quite a bit of knowledge and time to properly set up the backbone of an ‘encrypt’ and forget approach to network security, so it does not happen automatically. Instead, we have a proliferation of technologies being used to cut down on cable clutter and thereby consolidate the network. These are all very important concepts. Security practitioners like myself realize that this type of consolidation WILL happen. So what tools are required to either ‘encrypt and forget’ or to protect these consolidated networks?
First we really need to define the problem. Most people feel that VLANs offer adequate security as they are within the switch and they trust their switch. This trust however depends entirely on the configuration of the switch, which can change. Also, unlike a Firewall, a switch is a Failed Open system. In other words, if the switch software fails for some reason, it fails open, which could send ALL packets on one VLAN to all other VLANs as well as the designated VLAN.
This is NOT a new problem, but virtualization does exacerbate it quite a bit, as does VLANs, FCoE, and CNAs.
The common solution to this problem is to SILO the security zones within the virtual environment in such a way that the clusters of virtualization hosts are designated for a particular zone. This does not change when you start to think about using VMsafe or Xen Introspection. You would think it would, but if you still use VLANs, FCoE, or CNAs, the external and internal wires still contain the mixed security zone data in relatively random contiguousness. If there is a bump in the wire possible in the physical network or a switch gets hacked or fails open this data is now at risk.
Within the virtual network, the hypervisor can see all packets and so can the management consoles for Xen and Hyper-V. For VMware vSphere this is a much more difficult prospect as the physical NICs are hidden from the service console. Also, if a VM puts its vNIC into promiscuous mode it could be an attempt to coerce the virtual network so that it can see all data. Once more a difficult prospect but possible if the network is mis-configured.
Many of the issues that arise with virtual networking, arise due to misconfiguration of data. So it is critical that virtual networking have some form of change control either using ConfigureSoft, Tripwire, or some other tool integrated into the virtual environment.
So what can we do?
At the moment there is not much out there that could be used to ensure that traffic on the virtual network goes exactly where it is destined and that other parties cannot read that data even if it was accidentally sent. Such as the case with a failed virtual switch. The best we can hope for is that the data is encrypted and that delivery is fully controlled in some manner.
In many ways, IP addresses and protocols are fairly difficult with which to work. Mainly because we have the mindset that A) they are necessary and B) the work only a certain way. But within the virtual environment we have other tools available to us as well. Once that perhaps could tag packets so that they are also rejected at the virtual machine layer as not belonging. We are actually talking about the virtual machine unique ID (VM UID). Each VM has a VM UID, and this is a larger address space than most IP addresses in use today. In addition, virtualization hosts can be extremely authoritative about the VM UIDs they are currently hosting.
Perhaps there is enough data in these VM UIDs to be part of an encryption key that can be used to encrypt packet payloads so that even if mis-delivered, they cannot be read without the proper keys. Research into this type of encryption is being done today.
Even so, there are some enterprises that desire to never encrypt data on their wires until it leaves their bastions. This way they can audit traffic for malfeasance and other things. For this need, the appliances used would need to either use a back door type of key or have access to the encryption keys to decrypt any packet desired. It also means many of these appliances would need to have more horsepower to handle such decryption.
The proper place to perform such encryption would be at Layer-2 using IPsec or something similar, unfortunately, the chances of someone properly setting up a large scale public key infrastructure (PKI) is very slim or we would have seen it in place today.
Is there a Solution?
There are glimmers of solutions from many vendors on the horizon, but one stands out now. This is Apani’s EpiForce VM. In essence, EpiForce creates an identity aware network, pretty much creating multiple policy based encrypted networks where each server on a specific identity network understands how to properly decrypt packets and only those packets for that identity. An identity could be a person, place, or existing security zone.
Since EpiForce works within and without the virtual environment all types of networks are protected and those pesky security appliances used for auditing traffic could be members of multiple identity networks and still solve the problem.
EpiForce layers an encrypted set of networks on top of Layer 2 and simplifies the PKI problem.