The resiliency and availability of security appliances in virtual environments is a focus of my "Four Horsemen of the Virtualization Security Apocalypse" presentation which I delivered during Blackhat last week.
In my session I discussed some detailed scenarios of the architectural adjustments to infrastructure that virtualizing physical security appliances require and what that means to the overall resiliency,
reliability, performance and scalability of systems which depend upon security controls in the form of physical appliances today.
Specifically, I highlighted some of the limitations of using security virtual appliances and demonstrated how relying upon virtual security appliances can actually decrease the security posture and increase risk in our environments today.
One of my examples illustrated how it may become necessary to combine multiple security virtual appliances on a cluster separate from the VM's they are protecting in order to achieve the availability, performance, scalability, and resiliency that we get out of dedicated in-line physical appliances today.
If you prefer a simpler example, I also presented the simpler example of a firewall virtual appliance front-ending 10 production VM's. I like the former because it directly contrasts the physical and completely virtual.
For the sake of illustrating a point, imagine if one were actually able to satisfy business, security and compliance requirements using this virtualized security architecture in a production environment built upon the same virtualization platform as non-security guests.*
Not to pick on my friends at VMware, but today's license timebomb issue delivered by a VMware patch is pretty nasty and sends my hackles skyward when contemplating what it would mean were one to virtualize the security infrastructure.
Basically, this issue caused by an update rendered certain VMs unusable after the update. If one or more VM's on an updated host happened to be a security appliance or security control taken down for patching or rotated for re-purposing, etc. imagine your surprise post-patch.
Remember that security applications are very topology and state-sensitive and
unlike other apps. that just care about an IP address with which to spew packets
ethereally, security appliances/applications need to bind access
policies with affinity in order to protect assets behind them. As we
all know, when something doesn't work, we invoke the SysAdmin prime
directive: "Blame the firewall!" ;)
Events such as this may cause some to give pause to enterprise security architects before migrating security functions to virtual appliances, especially given where we are today with what I presented in terms of high-availability options within single-cluster hosts with virtual security appliances.
In reality, it will probably cause people to consider what virtualization means as an overall contributor to operational risk for any physical system conversion -- regardless of vendor -- since any VA/VM would be affected, but let's think about this as if one had virtualized the security infrastructure.
While it's true that for guests we have DR options and snapshotting that would make roll backs an easy affair, this shines a spotlight on the difficulties with patching the underlying virtualization platform and what that means to operational resilience.
The notion of a homogeneous virtualization platform are certainly compelling; easier administration, patching, configuration, standardization, reduced costs, etc. However, the notion of a monoculture "operating system" has its downfalls also. This issue clearly highlights one of them.
I'm not suggesting that there are not opportunities for virtualizing certain security functions, but as I pointed out in my talk, many of the required topologies and high-availability options present in mature physical security appliances are not available in the virtual appliance world.
Today's issue highlights the need for very careful planning when comes to what, when and if one should
virtualize security functions.
When in doubt, refer to Hoff's Corollary:
/Hoff
* You might want to look at what a platform like the Crossbeam X-Series can give you that "normal" virtualization security platforms cannot, as it mitigates some of the issues mentioned in my talk.
** Of relevance is my blog post from back in January titled "On Patch Tuesdays For Virtualization Platforms"
The answers to your questions/suppositions are quite simple:
"It all depends upon the auditor."
Most of the folks I've spoken to recently are essentially counting upon the ignorance of the auditors and the general confusion regarding terminology and technology to glide by at this point.
Server/blade/hypervisor/switch ... it's all fun and games until someone loses a (PC)I... ;)
"As long as I put in place the same host controls I do in a physical environment and not tell the auditor it's virtualized, it's all good and what they don't know, won't hurt me."
Sad but true.