Comments on: Virtual Appliances – More Risk than Reward?

By: Andi

Andi — Mon, 15 Mar 2010 04:58:18 +0000

Hey Carl,

Unlike any other VM, the vApp consumer normally has no ability to patch it directly. They must trust the vApp provider to deliver patches quickly and reliably.

For zero-day vulnerabilities especially, this means the supply chain for patch delivery (OS/hypervisor/other OEM vendor to vApp provider to vAPp consumer) is extended.

I believe this added step in the patch supply chain is a significant risk.

But you are right – it is entirely possible to secure a virtual appliance with a good provider that has a good process. Some lag between OEM patch and vApp patch availability is inevitable; but your suggestions are good ones.

P.S. sorry it took so long to approve your comment. It was automatically held for moderation because of the links (anti-spam measure), but I was between laptops and missed the notification email.

By: Carl Skow

Carl Skow — Thu, 11 Mar 2010 21:57:44 +0000

I’m not quite following this security issue. Of course it’s different from a physical model, but honestly is analogous to any other VM in the environment. For example, we can run a vapp created directly off of a supported platform like http://www.susestudio.com, and have the full support of Novell, as it’s the same kernel, modules, libraries underneath; there’s just less of them.

From the management perspective, a vApp can be a waterfall of “rip out and replace with updated vApp version” for patching, and if you can verify that all of the appliances are up to your certified gold standard version, you can insure compliance as you know all vApp systems were built the same, just service different applications.

As long as you can build a multi-tenant solution with newer infrastructure, we can keep it completely compliant from the service perspective and siloed any way we’d like.

In terms of the security of the hypervisior itself, this varies by manufacturer. I can assure that many high security government agencies leverage virtualization technologies, and I know VMware ESX(i) 4.X is going through EAL4+ certification right now (http://www.cse-cst.gc.ca/its-sti/services/cc/oe-pece-eng.html). ESX 3.0 already had it.

By: Coté's People Over Process » Links for March 8th through March 9th

Coté's People Over Process » Links for March 8th through March 9th — Wed, 10 Mar 2010 13:53:03 +0000

[...] Virtual Appliances – More Risk than Reward? [...]

By: Andi

Andi — Thu, 05 Nov 2009 07:27:30 +0000

Jacques, I agree on the security issues especially. It really is under-appreciated. Virtual appliances are fundamentally different from physical appliances in the way they present a wider target, and the hypervisor as you say is not impenetrable. Your preference for h/w appliances is not uncommon for these reasons (and more).

Thanks for adding some good comments on my blog!

Andi.

By: Jacques Talbot

Jacques Talbot — Wed, 04 Nov 2009 13:27:35 +0000

As William pointed out, you (we actually) should separate architectural and tactical arguments.
Tactical arguments can always be attributed to a lack of maturity and can eventually be fixed.

However, IMHO, the strongest architectural argument against vAppliances is security proofing. You cannot certify the vApp+Hypervisor combo. In the name of “depth defense”, it seems difficult to accept in the cloud that the hypervisor is the sole shield against the enemy, because it can have some weaknesses too.
So I would rather user HW appliances to build the basic security boundaries in the cloud.

By: William Vambenepe — Would you like some management with that appliance?

William Vambenepe — Would you like some management with that appliance? — Tue, 03 Nov 2009 06:54:17 +0000

[...] Mann recently wrote an interesting post about virtual appliances . He uses the domain name pleasediscuss.com for his blog so I figured I’d do just that. More [...]