We’ve decided to cross-publish a blog post by Gregory Ness, VP of Marketing for Blue Lane Technologies, because we think it delivers a good insight in the whole Hoff/Crosby debate about virtualization security (virtsec, if you will).
Last year when I blogged about the impact of virtsec on the world of static security I focused on how virtualization could degrade the effectiveness of security solutions. Since then we’ve seen a surge of vendor marketing around virtualization security (virtsec), from a growing corral of one trick pony start-ups with various Barney announcements (“I love you, you love me…”) to the likes of the world’s leading security companies joining VMware’s unprecedented, visionary VMsafe initiative.Last month I blogged about data center security’s key requirements, which included virtsec. My point was that virtsec will require more intelligence and agility than perimeter network security, because it will need to be deployed within the hypervisor layer and will consume hypervisor resources. Simply moving deep packet regular expression inspection engines into the hypervisor layer could add big hypervisor footprints and/or unacceptable levels of latency. These problems aren’t new; they’ve been hidden by faster and faster dedicated hardware at the network perimeter.
That’s why I found a recent virtsec blog exchange between Hoff and Crosby so disconcerting. Two brilliant guys with two very different perspectives are arguing about the ownership and accountability of virtualization security. Chris Hoff is a security guru with a sizable following who has been among the most vocal on the virtsec challenge. Security blogger Rothman calls Hoff Captain Virtual because he has been on a tear when it comes to the blog debate around virtsec.
Simon Crosby is leading the virtualization charge for Xen/Citrix and he insists that virtualization platform vendors should stay focused on securing their platform versus the new infrastructure they’re enabling. Like Chris, Simon is one very smart guy with a deep technology background in virtualization. And from Simon’s perspective he doesn’t sound unreasonable.
The virtualization security debate thus far has had so many issues swept underneath it by various parties that it resembles a lumpy rug. Simon and Chris are exposing some of the lumps as they humor each other with comments about smoking cigars from the wrong end and the following (from Hoff):
“Focusing only on your little patch of grass is short-sighted and it won’t work. Just like it hasn’t worked in the past. It’s a disaster waiting to happen, and you’re enabling it”. – Hoff
The problem isn’t that these two very smart guys disagree; it’s rather that this disagreement promises to play itself out on a micro-level in enterprises around the world, as I commented last year in “VM Security- The Keys to the Virtualization Kingdom.” And no one stands to win, except those hoping for a slow adoption.
The colorful and spirited debate between Hoff and Crosby is very symbolic of the issues we’ve discussed here since my initial virtsec blog in Feb 2007.
Unfortunately I think this debate risks becoming a metaphor for production data center virtualization; it feels to me like two different worlds colliding in a potentially myopic haze of finger-pointing and original sin debates. That scenario will not help Citrix/Xen virtualize production environments, and I think that is why Hoff’s points bear such weight. And I’m not sure that Crosby gets this given his thoughtful and understandable Mother of All Misunderstandings response to Hoff.
I think the mother of all misunderstandings is about to play itself out as “a funny thing happened on the way to the datacenter” scenario. When Caesar crossed the Rubicon he knew his security profile would change, but he still underestimated the Senate. If Citrix doesn’t show leadership (ala VMware and VMsafe, etc.) and instead talks about security as “other people’s problems” its growth in the data center could experience a thousand cuts Caesar style as internal conflicts and strife within customers (between the Hoff’s and Crosby’s) could demonize the incredible and undeniable power of virtualization to enhance data center security.
The virtualization and security vendors can either lead on this issue as an opportunity to enhance security today or merely create awareness around the new risks and dynamics and talk about far-off solutions that may one day work when the market matures. One strategy will lead to the faster deployment of hypervisors in production; the other will fulfill Rothman’s prediction.
Virtualization is a massive opportunity to escape the cycle of attack followed by tactical/regulatory response and establish a new order, with security pros getting powerful, flexible new capabilities to protect systems. That will require leadership and new thinking and a full appreciation by those who don’t want to relive the past. Security may turn out to be strategic to virtualization in ways that it couldn’t be strategic to the network. The hypervisor layer is perhaps the most substantial strategic security opportunity in many years. Let’s hope we leverage it to its fullest.
Virtualization absolutely presents us with the possibility of avoiding past mistakes and making virtual infrastructure (VI) more secure than the physical infrastructure it replaces.
Why?
1. Virtual security appliances and hypervisor APIs have made it possible for us to build security into the VI fabric at all layers.
2. The virtualization platforms give us the tools to automate deployment of primary controls, secondary controls and separation of duties throughout the virtual data center.
3. Virtualization means we can simplify security management and make true defense-in-depth affordable for everyone.
4. Secure hypervisors, their APIs and the right application of security smarts means we can build agent-less security that protects against rootkits, spyware and almost all forms of malware.
5. Virtual security appliances allow us not only to write good security policy but also to automatically enforce policy and provide continuous compliance auditing for the VI.
6. All of the above means, we can create tools for secure life-cycle, trust zones, trusted data paths and secure management in ways never possible with physical infrastructure.
We (as vendors) have a responsibility to educate the IT community to the myths and realities of VI security. The platform OEMs must recognize that simply saying virtual is more secure than physical – is a disservice to all of their customers. Then, when the manufacturers provide the security community the tools and support we need _and_ intelligently inform the market about real risks, then, and only then can we make virtual more secure than physical.
Michael:
Thanks for your comment. Hoff has been blogging at Rational Security for months about virtsec and I think one of the best points he has made has to do with the impact of traditional netsec in the hypervisor layer. Anyone reading this debate is encouraged to thoroughly review his comments. Ultimately I think netsec vendors disguising themselves as virtsec will have to address core architecture issues that impact how many processor cycles will get sucked up by inspection/detection/prevention and what impact deep packet pattern match will have on latency and flexibility.
The first issue is who is responsible for securing these environments. I think the second will be an objective look at the “feature” tradeoffs and the impact on business case.
G
Greg,
Only true to a point, security will require processor cycles somewhere, whether performed in an appliance, a driver in the hypervisor kernel or a service console application. The only difference is in the visibility and management of this processing requirement.
Pure appliances are completely open with respect to the processing cycles they use and are subject to all of the utilization management tools available within the virtualization platform.
Packet inspection requires cycles, even if it’s just to substitute a few bytes of content on the fly. Performing these cycles in a driver only hides the cost from the Virtualization Manager. These cycles are not “eliminated” from the system overhead.
Virtualization is “time sharing” with the context defined by an entire virtual machine. The platform venders are investing heavily in optimizing and reducing the overhead of this context switch. The smart play is to perform our security tasks efficiently wit in a well constrained virtual appliance. This makes the “cost” of security relative to performance both easily determined and easily managed.
In our large scale deployments, we see the biggest “win” has been to avoid requiring any changes to the network topology, routing or HA/BCP solution.
Michael
I think a key difference is how many cycles and where those cycles will be consumed (either within the layer or “hair pinned” to another dedicated appliance which introduces latency).
Sensors, agents and hairpins with deep packet scans of traffic pose tradeoffs that confuse features, processing cycles and business case.
Certainly we’ve seen this in intrusion prevention where “tuning”, false positives and rising processing/management requirements have forced feature turn-off. I think netsec speaking clearly and realistically about what can be done AND what resources will be required will be a big step forward vis-a-vis virtsec.
Thanks again Michael. As always enjoy and appreciate your perspective.
G