No, it doesn’t mean we “turn out the lights.” In fact, just the opposite. It means instead of allowing these issues to hibernate in darkness and wait to be bitten, it means shining the light on the issue(s) and pushing for solutions.

I’m not sure if you were alluding to some super-secret agenda I supposedly have based on what you classify as FUD, but you don’t seem to dispute my assertions, so I’m confused.

The only agenda I have is to point out what is quite obvious to me as an impending issue that I’ve not seen discussed elsewhere and offer solutions.

Last time I looked the hypervisor is becoming a commodity and IPv6 will not rescue orphans from a burning building, either

/Hoff

Does this darkside warrant that we ‘turn out the lights’ on virt as we knew it? Or are we beFUDdled just enough to drive another technology breakthrough within InfoTech “feature” that is virtualization. (eluding to recent financial analyst discounts of virtulization as a market and VMWare as a market leader).

My take is that the Hypervisor will at some point become the network, the security intelligence and the policy enforcement that is currently handled by dedicated devices.

The gap is closing fast. So fast that Moore himself can’t see it in motion.

The distributed vs. centralized dilemma is waning in the face of geo-redundancy and local-instance networking.

And finally, if we can get over this hump that is IPv4, we’ll have 64-bit optimized networking and much improved layer 2 negotiation to ice the cake.

Oh, and for those that may not know, FUD is the the loving acronym for the use of Fear, Uncertainty and Doubt to drive an agenda.

I agree with that 100%. So, if you can keep your Virtual environments / traffic (Dev, Test, etc) without making them cross your security zones (using different ESX Hosts and vSwitches plus physical Nics going to dedicated vLans), most of your security problems will be addressed (at least at the network level).

The key point of capacity planning here is that as you continue to add VM’s to a host to “scale” security functionality, you remove the capacity to consolidate P to V which is the primary goal.

If one used to be able to consolidate 10 P servers down into a single V host, and now you’re having to load that same server with 3-4 Virtual appliances for security, you’re not going to have the same ROI and the capacity issue — while similar to the physical world — becomes much more difficult for the other reasons I stated.

The VirtSec providers will start to give you stats shortly that promise performance/throughput, but they will be confusing due to the example above…esp. when these functions are placed inline with VM’s AND the ping/pong of interacting with external security functions.

My opinion is that it’s not going to be as straightforward as people think. I’ve spoken to most of the emerging providers and in confidence, they’ve told me the same thing…

YMMV.

In terms of threats and vulnerabilities — it’s an evolving landscape. Looking for the answer (is virtualization more secure) before the question can even be properly framed is going to give a false answer. What I mean is that as the solutions evolve, so will the T&V’s…we’ll react to them as we always do. There will be classes of new T&V’s that are virtualization-specific.

Right now, the risks are mostly centered on organizational and operational role shifts, separation of duties and virtual networking issues as Scott and I continue to write about.

/Hoff

Thanks for your comments.

One key thing that jumps to mind is a lack of visibility. In the physical world, there are almost always ways we can see the traffic that is flowing across the network–via span ports, inline IDS/IPS, network sniffers, etc. How does one accomplish this in the virtual world? Sure, you could run a network sniffer on a vSwitch in promiscuous mode, but then you’re back to considering the overhead again. It’s not an impossible problem to solve, but it is a problem to be solved (and solved well).

As for the overhead, I do think it’s too early to tell for sure. However, isn’t this something we should address before it becomes a problem? In the physical world when we add appliances and hardware solutions, they don’t detract from the CPU/RAM resources available to the workloads. That inline IDS/IPS has its own RAM and CPU processing power. That hardware firewall has its own RAM and CPU resources. Now we are going to have to collapse those functions onto the same hardware that is running your applications. Of course there’s going to be a performance hit. Adding one more CPU might fix it; adding one more CPU might not. The point is, who out there is telling us how much overhead we should be planning for? The virtual security vendors aren’t going to say because that might cause people not to buy their products. So, in my mind, anything we can do to bring this issue to people’s attention is worthwhile.

I believe that conceptually there is not much new here. True, Virtualization has produced new challenges but fundamentally they are not much different from the challenges we face in the physical world. The current virtualizaton security discussions seem to lack focus and sometimes it just feels like FUD.

As for the overhead, I’m not convinced that it is such a great concern. In the physical world we add dozens of hardware and software solutions that add an overhead. They do cost money and they do impact performance. In case of the virtual world the overhead might just be resolved by adding one more CPU or a little more RAM.