Telematique, water and fire.

Virtsec - Looking up from Layer 4

Greg Ness recaps VMworld Europe's VMsafe announcement, and relates it to the future of virtualization security (virtsec). As a bit of imagery, he links the future of the virtualized production data center to the "upstack (layer 7) server" and its overshadowing the "operationally-intensive layer 4 world of deep packet inspection, signatures and tuning." Nice turns of phrase. They set me thinking about how to characterize those aspects of the virtualized data center which must provide visibility into and the reduce complexity of layers 3 and 2 (... notice the ordering sequence based on the point of view). My initial take is that they deserve a different set of metrics and viewpoints that, as well as Greg's when considering security. More as I tease these out.

VMworld Cannes: Au Revoir Layer 4 - Seeking Alpha

When VMware announced VMsafe at Cannes it marked a major data center security milestone on many levels: 1) it was the first major public statement on virtsec by any virtualization platform vendor; 2) it represented the first glimpse of how virtsec will change the netsec game; and 3) it articulated the key differences between what VMware will protect and what its partners will protect.

That combination of vision and clarity against a backdrop of 20 enlisted security vendors was the equivalent of a high level declaration of independence from the hardware-centric network security appliance model that took off with the emergence of fame-seeking hackers in the late 90s and early 00s. It was also a critical launch component of VMware’s push into the data center. Among the leading security players teaming up with VMware: CheckPoint, McAfee and Symantec.

...

The faster that VMware virtualizes the production data center, the faster the virtsec industry will accelerate. Given VMware’s momentum and now its high profile position on security (and the positive reaction of VMworld attendees), it seems likely that upstack (layer 7) server and VM security are about to rock and roll the tired, operationally-intensive layer 4 world of deep packet inspection, signatures and tuning. VMsafe has set in motion a security revolution that will indeed advance the cause of data center security beyond the common expectations of older generation architectures.

More on VMsafe from Chris Hoff

Chris Hoff has a very good (and entertaining) post about the impact of VMsafe on the providers of "Firewalls, IDS/IPSs, UTM, NAC, DLP" ... a sector that he considers as being on life-support and suffering from a severe case of consolidation.

To his point about VMware's willingness to sign on new partners, I'm still at some pains to find out just how open/public the VMsafe API will be and on what time frame. Does anyone out there have definitive information on this? Any of the existing VMsafe partners willing to talk about it?


Rational Survivability: VMWare's VMSafe: Security Industry Defibrilator....Making Dying Muscle Twitch Again.

... VMSafe represents a huge opportunity for these vendors to claw their way back to life, making their solutions relevant once more, and perhaps even more so.

Most of the companies who have so far signed on to VMsafe will, as I mentioned previously, need to align roadmaps and release new or modified versions of their product lines to work with the new API's and management planes.

This is obviously a big deal, but one that is unavoidable for these companies -- most of which are clumbsy and generally not agile or responsive to third parites.  However, you don't get 20 of some of the biggest "monoliths" of the security world scrambling to sign up for a program like VMsafe just for giggles -- and the reality is that the platform version of VMware's virtualization products that will support this technology aren't even available yet.

I am willing to wager that you will, in extremely short time given VMware's willingness to sign on new partners, see many more vendors flock to the program.  I further maintain that despite their vehement denial, NAC vendors (with pressure already from the oncoming tidal wave of Microsoft's NAP) will also adapt their wares to take advantage of this technology for reasons I've outlined here. ...

Cisco IOS-XE and KVM

Interesting post at Virtualization.info about Cisco's new operating system, the most salient point being that with all the noise being made about Cisco's relationship with VMware, it's apparently basing the IOS-XE virtualization on KVM. Also, another (self-referential) mention of Cisco's third-party distributed virtual switch for VI3.

Update:

My colleague Ken Novak has pointed me to a couple of posts by Andy Dornan, one about Riverbed's use of linux-kvm applications as part of the RiOS Service Platform, and his take on Cisco's use of Linux as a basis for IOS-XE. The take-away quote from the IOS-XE post:

When Cisco (NSDQ: CSCO) and Juniper first said they were opening their router
OSes, I thought that they'd be about as open as the iPhone. With Cisco's launch of IOS XE, I realize I
was wrong: The iPhone is much more open.

This is worth watching.

virtualization.info: Cisco puts KVM in its IOS

And now Cisco includes it in the new IOS-XE, the Linux-powered operating system for its highest-end router: the ASR 1000.

The Aggregation Services Router (ASR) 1000 is the first Cisco router that replaces its traditional in-house developed IOS with Linux and targets service providers and biggest enterprises.
Among the exclusive features offered by this new equipment there is the operating system redundancy, achieved without any hardware module: a first in the networking industry.

How Cisco is able to provide a redundant IOS image? Through KVM virtual machines as Information Week reports.
At this point is still unknown which version of Linux kernel is used for IOS-XE and which version of KVM as well, but the company must be absolutely sure of its reliability to use it in such high-end product.

It's interesting that fact that Cisco chosen KVM for this task, while it's very busy with VMware, investing in VMW, occupying its keynotes, and maybe (it's still an unconfirmed news) releasing a software switch for ESX Server.

Xensploit, VMotion and VM Migration

Over the course of the past week, I've seen a number of references to recently published proof-of-concept exploit of virtual machine hot migration. It's got a number of our more exciteable colleagues wrapped around the axle. Two thoughtful and well-considered posts have emerged in response, both worth reading. Scott Lowe and Warren Wu take on the issue directly, provide good advice and, in so doing, make an argument for the class of virtualization management systems in development at Replicate. It's nice be reassured that we're addressing a real source of data center pain.

VMotion and VLAN Security - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers

... Xensploit, as it’s called, is the recently demonstrated exploit that allows virtual machines (VMs) that are “in flight” during a live migration (XenMotion in Citrix XenServer, VMotion in VMware ESX Server) to be manipulated. If you haven’t yet read the PDF that describes Xensploit, I highly encourage that you take a look at it. It’s very enlightening as to exactly what can be done to an in-flight VM.

Naturally, the best way to protect against this particular problem is to guard the integrity of the live migration network. For simplicity’s sake, I’ll refer to this as the VMotion network from this point on, but keep in mind that it is equally applicable to any network connections on any virtualization platform that uses live migration.

The most surefire way to protect the VMotion network is to place it on its own dedicated, physically separate network, using separate physical NICs plugged into separate physical switches that do not possess any connections to production networks. This will ensure that unauthorized access to the VMotion network is prevented, but comes with disadvantages as well: this configuration requires more physical NICs and more physical switches than other configurations. ...

Keeping Your VMotion Traffic Secure

... Although impressive, this work by no means represents any new security risk in the datacenter. It should be emphasized this proof-of-concept does NOT “take over the hypervisor” nor present unencrypted traffic as a vulnerability needing patching, as some news reports incorrectly assert. Rather, it a reminder of how an already-compromised network, if left unchecked, could be used to stage additional severe attacks in any environment, virtual or physical.

On an insecure network, man-in-the-middle attacks can target both virtual and physical machines. The techniques published are novel in that they go after the contents of migrating VM memory to target credentials and data, rather than going after similar information flowing across internal network transactions. Putting aside the question of whether it’s even worthwhile to target memory instead of network traffic directly, the sensitivity of VM memory was never the question. ...

VMsafe ... it's open... it's closed ....

Anyone who's been following the reverberations of VMware's announcement of VMsafe, has certainly picked up on the fact that it's making a great deal of difference to a lot of people.  There's the inevitable hyperbole that accompanies something like this, but from all the information provided by VMware at the conference, it's a significant technical achievement and should advance the use of VMware for production computing environments.

There's just one little thing that continues to bother me.  We still don't seem to be in agreement about whether the API is going to be openly published, openly licensed or whether it's closed to all but a few of VMware's closest friends. Try as I might to find something definitive on this, I keep running into contradictory "statements of fact." Two blog postings shown below indicate that rest of the community is probably in the dark as well.

Back In Town From VMworld Europe « White Noise

... VMware has been working together with McAfee developing a new security API which will be released very soon. The idea is that instead of having a virus or mal-ware scanning tool in the guest OS you are going to see this happen underneath the hardware, in the hypervisor. There are some big advantages to this:

•     No more scanners in the OS poking their way into all kinds of user, kernel, and IO calls causing overhead and potential issues.
•     Being underneath the hardware will make it possible to scan everything. From the full memory map of the guest machine to stopping malicious processes before they are started on the CPU. Yes. This works and had been demonstrated.

The good thing is is that the API will be open for everyone. ...

virtualization.info: VMware announces VMsafe APIs

... Unfortunately nor the new interface neither the related products are available today: VMsafe will be included in future versions of VMware Infrastructure, complemented by security products built specifically for it.

So far VMware didn't open the documentation for the APIs and doesn't seem possible to apply for the technology program. ...