I'm going to highlight a prediction I had on a forthcoming security offering from yet-to-be-named security solution providers for virtualized environments as well as something I overheard at RSA.
In the next few days, I'm going to be releasing my post on the evolution of some really concerning performance and configuration limitations of security solutions in virtualized environments and this will make a lot more sense, but until then, grok this...
Here's Item #1 - Return of the Big, Honkin' NIC Card...
Remember back when 3Com released this little beauty?
3Com® 10/100 Secure Server NIC
Server IPSec and 3DES Encryption at Wire Speeds
The 3Com® 10/100 Secure Server NIC is custom-designed for servers that demand high performance and end-to-end security. Its onboard security processor works with Windows 2000 or XP to offload key processing tasks, reducing the load imposed on the CPU.
It never really took off and has long since been discontinued, but here's where I reckon we're going to see a rebirth (like bellbottoms) of something similar from security vendors, either as a NIC or an offload card sitting in the virtual host.
In a virtualized server, most of the emerging security solutions are going to take the form of agents/applications running in VM's or as virtual appliances in the host. This is all going to be run in software, with limitations on memory, CPU and I/O. Imagine every flow whether inter-host or intra-VM having to bounce back and forth across the vSwitch and the security functions in software.
Ugh.
Despite API's like VMsafe, which allow for hooks on a per-VM basis to "redirect" traffic to a VM/VA for disposition in software, imagine if instead of just having IPSec on a NIC, we also had DPI, firewall, IDP, AV and other security functions also.
Rather than doing all of this stuff in software, the agents/applications or virtual appliances could offload or allow the hardware to perform them on their behalf. This could take the form of FPGA's or custom silicon like Cavium's multi-core Octeon security processors.
This is where the argument of "hey, all we need is COTS multicore hardware to scale" simply falls apart.
It's not at all an original idea, as we've had offload/acceleration cards in appliances/'servers for a long time, but when the performance and configuration limitations of virtual hosts arise, I predict we'll see these things crop up as a "solution" that is "new." ;)
Here's item #2 - Bait and (Virtual) Switch
I've talked previously about virtualization platform providers like VMware ultimately providing a way of modularizing/isolating the vSwitch functionality in the VMM and allowing third parties to instantiate their own vSwitch instead.
Further, I've written about how I/O virtualization is likely to change the way and where the virtual networking is performed.
Intel is rumored (was this news at RSA, I can't tell?) to be taking another approach which is that they intend to embed the vSwitch functionality directly into the underlying CPU chipsets. This makes the vSwitch not so much 'v' (virtual) any longer. You'll have the network switching fabric and functions in the CPU itself.
I'm sure that if Intel is considering this, then AMD would not be far behind.
Thus some version of an upcoming CPU would provide this capability natively, interfacing with the NIC card (or the super NIC above) and the VMM. This brings up some really interesting questions, no?
More later.
/Hoff