Many a comment on the VMware Communities Forums are about using VLANs to secure a network, while technically this is not a network security feature of the network it does provide a way to logically segregate traffic. In my mind segregate is different than separation.
Segregate implies a logical distancing between two or more elements, yet the elements of the network share the same wires, switches, etc.
Separation implies a physical distancing between two or more elements where the elements do not share anything in common.
To use virtualization, it is impossible to achieve 100% separation as we discussed in my Rethinking vNetwork Security post. I have continued to consider all aspects of the vNetwork with respect to security and VLANs. So here are some basic rules that will help you to decide how to design your vNetwork. These rules are based within the physical network (pNetwork).
During the Virtualization Security Podcast on 5/13, IBM’s David Abercrombie joined us to discuss IBM’s Virtualization Security Protection for VMware (VSP) which contains several exciting uses of the VMsafe API for VMware vSphere. These being:
- Network: Network Monitoring, Firewall, Access Control, and a Protocol Analysis Module
- Memory: Rootkit Detection
This lead me to start to think of how the existing vendors are pushing the Introspection APIs such as VMsafe to their current limits. So what is being done with the Introspection APIs? Many of these technologies are listed within the End to End Virtualization Security Whitepaper. Yet, there are some new use cases to consider.
I recently spoke at the InfoSec World 2010 Summit on Virtualization and Cloud Security and also attended the main conference sitting in on many Virtualization discussions. Perhaps it was the crowd, which was roughly 30-40% auditors. Perhaps it was the timing as SourceBoston was also going on, as well as CloudExpo in NY. But I was surprised to find that people are still ‘just starting’ to think about Virtualization Security. Since I think about this subject nearly every day, this was disappointing to me at best. I found ideas around virtualization security ranging from:
- Virtualization Security is not part of an architecture/design, what do I bolt on?
- My Physical Security will work
- Virtual Environments NEED More security than physical environments
- There are no new threats, so why have something more
- Security is a hindrance
The most recent Virtualization Security Podcast was on the subject of virtualization security for the SMB. Specifically covering the case where the customer wanting virtualization security could afford to purchase a hypervisor and perhaps one other security product. In the end the panelists came up with a list of suggestions for virtualization security for the SMB that are applicable to all levels of Virtualization. The panel looked at SMB security with an eye towards Availability, Integrity, and Confidentiality.
The list follows:
- Download/create a Security and Incident Response Policy: It is very important to have a policy as this will not only let you know your responsibility and legal coverage but will also contain what you need to do if there is a security incident we respect to your data and environment.
- Segregated your virtualization networks from production networks: Virtualizition Networks are not virtual networks but those networks required by the hypervisor functionality such as Management Appliance, Fault Tolerance, High Availability, LiveMigration/vMotion, and Storage virtual networks.
The most recent Virtualization Security Podcast was on Rethinking vNetwork Security and featured Brad Hedlund of Cisco as the guest. The conversation started on twitter two weeks ago and lead to Brad posting a write-up of his discovery’s on his InterNetorkExpert blog titled The vSwitch Illusion and DMZ Virtualization. The podcast went even deeper into the technology and may have come up with a solution to what is becoming a sticky vNetwork problem with some organization’s security policy. However, what it all boils down to is Trust. Where do we place our Trust, but without full knowledge of how the vNetwork stack operates, this trust could be misplaced.
Brad asked the question, should the physical network security policy be different than the virtual network security policy? The answer is obviously no, but why are they treated separately? I and other have pushed the concept that to gain performance, redundancy, and security that you should use multiple network links to your virtualization host to separate traffic. However, does this really give you security?