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 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.


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. 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 - - 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. ... 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. ...


Transactional Cloud DB

EnterpriseDB seems to be making some interesting moves with the announcement of their offering.  I'm not sure I understand how they both scale and transactional DB functionality with any kind of service level assurance.  But, I'm all ears...

Another Amazon 'cloud' database, but this one will be Oracle-compatible

EnterpriseDB plans in March to start beta-testing an online version of its Oracle-compatible database that will leverage Inc.'s Web-based computing and storage services.

The EnterpriseDB Advanced Server Cloud Edition will be much more powerful than the SimpleDB Web database that Amazon itself plans to offer, claimed Bob Zurek, the Edison, N.J.-based software vendor's chief technology officer.

Zurek added that EnterpriseDB, which bases its commercially licensed software on the open-source PostgreSQL database, will offer a new pricing model that will help it compete with Oracle Corp.'s databases and the MySQL open-source technology that Sun Microsystems Inc. recently agreed to buy.

Powered by ScribeFire.