Further Reflection On Virtualizing Security Appliances…
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"
First of all, great use of that photo…
Secondly, what troubles me is the rush to "all things xxx" and what that means for security in most situations. It never fails…
i this and i that…
e this and e that…
Now V this and V that…
The lack of understanding of VMs in general from a communications perspective as far as visibility in organizations is rather staggering. It is the new old Windows GUI ..just click and watch it work..oh wait..it did not work? Just click again!
Jesus…it's like the argument people use against CLI or black screens or command prompts..
"We are more efficient this way…"
The real question is do they even understand what the tools do? It is that simple.
We screw ourselves in this industry at every turn because we innovate without educating and have for years. That in turn creates a vacuum that vendors fill where they have the upper hand because many folks are nearly forced to stand by while the "Ninja Monkeys" that all have a vested interest in their product take over and steer the ship. It is a vicious cycle and VMs have sailed right into the middle of that no-mans land now.
A couple of years ago the topic was a bit too complex to just tackle out of hand for any shop. You had to know your craft to some degree. Now the curve drops a bit…the rhetoric gets amped…the vendors get amped…the "tools" get amped…everything has a V in it…and people that should never be able to make the decisions they are about to make point and click and…
Here…we…go…
Chaos.
–David
First of all, great use of that photo…
Secondly, what troubles me is the rush to “all things xxx” and what that means for security in most situations. It never fails…
i this and i that…
e this and e that…
Now V this and V that…
The lack of understanding of VMs in general from a communications perspective as far as visibility in organizations is rather staggering. It is the new old Windows GUI ..just click and watch it work..oh wait..it did not work? Just click again!
Jesus…it’s like the argument people use against CLI or black screens or command prompts..
“We are more efficient this way…”
The real question is do they even understand what the tools do? It is that simple.
We screw ourselves in this industry at every turn because we innovate without educating and have for years. That in turn creates a vacuum that vendors fill where they have the upper hand because many folks are nearly forced to stand by while the “Ninja Monkeys” that all have a vested interest in their product take over and steer the ship. It is a vicious cycle and VMs have sailed right into the middle of that no-mans land now.
A couple of years ago the topic was a bit too complex to just tackle out of hand for any shop. You had to know your craft to some degree. Now the curve drops a bit…the rhetoric gets amped…the vendors get amped…the “tools” get amped…everything has a V in it…and people that should never be able to make the decisions they are about to make point and click and…
Here…we…go…
Chaos.
–David
Hoff,
Nice to see you still showing us the love. We did finally buy out the other company that was taking our rightful URL, and are finally just http://www.crossbeam.com. Sounds like Blackhat was quite eventful for you; nothing like being misquoted.
Cheers,
Ward
While I agree with the substance, currently some updates cause even traditional independent security systems to fail. As with all things, being able to deploy updates in a testing fashion (test server first, toe-in server second, full production last) will probably do the most to prevent patch related failure in any system. I recognize that security patches must be deployed quickly but doing so intelligently has always been an issue too.
With this stated, VM does have it's place with some aspects of security. For example, your audit server can easily be virtualized with minimal concern.
Finally, I think a related issue in the security world is the 'it does it all' box. Many times, separating your security devices so you know 'blame the firewall' as opposed to 'blame the firewall / VPN concentrator / router / mail inspection / AV system / web filter / ' is at the very least, more accurate since the others can be validated independently. Having these as separate VMs allows some amount of speed in resolving related issues yet keeps the cost of physical servers lower which will drive many more to continue virtualization. This 'business' argument to continue using VMs will need to be argued effectively with examples of failure and full explanations about single points of failure (since many businesses only look at the bottom line).