Archive

Archive for the ‘Cloud Computing’ Category

Video Of My Cloudifornication Presentation [Microsoft BlueHat v9]

August 16th, 2010 2 comments

In advance of publishing a more consolidated compilation of various recordings of my presentations, I thought I’d post this one.

This is from Microsoft’s BlueHat v9 and is from my “Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure” presentation.

The direct link is here in case you have scripting disabled.

The follow-on to this is my latest presentation – “Cloudinomicon: Idempotent Infrastructure, Building Survivable Systems, and Bringing Sexy Back To Information Centricity.

Related articles by Zemanta

Enhanced by Zemanta

Airing Private Cloud’s Dirty Laundry…

August 7th, 2010 10 comments
Laundromat in Toronto, Canada
Image via Wikipedia

It’s 10:13pm on a Friday night and as the highlight of my day begrudgingly reveals itself, I discover in preparation for the inevitable appearance of tomorrow, that I am once again out of clean underwear.

There are many potential remedies for this situation.

Option number one suggests I could borrow a pair of my wife’s low-cuts.  She’s out of town and would never know, except perhaps discovering upon her return the horribly awkward and uncomfortable remnants of chafing in places we simply and politely just don’t talk about at parties.

Option number two involves what I call ‘The Braveheart.” Commando fashionista. Rivets on Levis put a quick end to that potential.

Option number three. CVS. It’s open 24 hours. They sell boxers. I saw them last week when I ran out of toothpaste in a similarly-themed domestic challenge. However, it’s now 10:16pm and whilst the pharmacy is only 10 minutes away, I’d prefer not to have to explain or even acknowledge to the cashier — silently with a sheepish grin and a telling nod — why it is I am buying underwear instead of beer at 10pm on a Friday night.

Option number four. The uncomfortable reconciliation of fact.  Laundry.

Laundry is not an altogether alien concept to me.

In a house where I am surrounded by a fortress of estrogen-themed daily drama, couture — or namely the availability of fresh sources of same, not found strewn around the house in piles resembling Inuit housing — is a constant and simultaneous source of both amusement and utter distress.

I know how it works.  More specifically I know how it *should* work. It’s not that difficult a concept to master.

I contemplate, strangely, what it would be like if option number four required something other than a modest jaunt to the basement where lives the ominous apparatus that does diligent battle with the detritus threatening the sanctity of my linens.

I reckon back to the days of college and of single life in an apartment where this capability was not installed, where I had to pack up my dirty vestments, remember the detergent, fabric softener, dryer sheets and a thousand dollars in quarters and trek to…

The laundromat.

I re-imagine the hours I’ve spent there.

Strangely-timed appearances meant to avoid the rush which is met with the soul-crushing realization that everyone else uses the same random number generator to decide when to show.  The ludicrous rituals of basket placement and folding table land-wars.  The hope that at some point in the next 12 hours, the illusion of infinite laundry scale will avail itself to me.

I remember these things.

I remember the rust-stained linoleum flooring. Faded pictures and warning emblems threatening sure and certain death from things like asphyxiation, electrocution, strangulation and loss of appendages.  I am particularly disturbed and most concerned with the latter.

The community bulletin board is always a symbolic mecca for the cultural awesomesauce around which a neighborhood is formed; an eclectic mix of lost pets, waterbed auctions, spanish and math tutoring services, guitar or tuba lessons (your choice) and a never-ending supply of for-sale-by-owner-1984-in-good-condition-runs-perfectly-Honda Civics.

And yoga lessons.

Because with a wash-rinse-dry-fold cycle time of approximately 2 hours, down dog and vinyasas are a natural way to pass the time.  I must admit to never having witnessed yoga in a laundromat. Unless you consider two newlyweds making out in the corner as Yoga.

I recall the sweet and confusingly intoxicating smell of Downy.  That earthy, hot, suffocating perfumed humidity of 1000 dryers tumbling in a rhytmic chant of anti-moistness. Low frequency undulating serenity drummed into my consciousness, starkly punctuated with the the alarming and syncopated rupture of tempo by unrecovered pocket change falling out of jeans, producing a staccato “pitta-chank, pitta-chank, clink, donk.”

And then, the fear.  The fear that I don’t have enough quarters and that the change machine doesn’t take ten dollar bills and that I’ve forgotten to bring something to read, nourishment, hydration, motivation…

I recollect the homeless man curled up in the corner under the flickering TV that only gets Korean soap operas with a vertical lock problem and the industrial-sized machines used for washing tents, small couches or horse blankets.  There’s the cigarette, whiskey and cruely time-stained woman in 50 cent curlers in her high-fashion and Heathcliff slippers, unshaven legs and a hawaiian print moomoo reading People magazine, snickering at the misfortunes of multi-millionaire actresses jilted by their spoiled no-talent actor suitors.  Venom.

But most fondly I smile — almost vindictively — at the memory of the man staring hopelessly at the bank of identical washers, each in spin cycle, wondering which three were his and hopelessly wondering why it is that he is mesmerized and distracted then by the one pink sock in a load of all black washing, flitting back and forth through the porthole in the jumbo drier.

It’s then that  I flash forward to the now, staring at the highly advanced, extremely efficient and 100% available and dedicated GE Monogram front-loading washer and dryer standing before me in my basement.  They’re color matched in a silver hue not unlike that of a fighter jet — beautiful, sexy and — if you paid attention to the warnings in the laundromat — potentially deadly.

Speaking of which, I’m quite sure it *is* possible to drown in a front-loader, but the process eludes me.  Perhaps out of respect for the grieving family of anyone stupid enough who has managed to kill his or herself in a running washing machine. Perhaps because I’m thinking way too much about how this can be done.

The physical attractiveness is not the most compelling element of my dirt-ridding-appliances. It’s the fact that they belong to me.

Mine.

Now.

Forever.

No waiting.

No vehicular excursions. No lady in a moomoo. No territorial battles waged over timing issues between washing machine to dryer transfer latency.

All. Mine.

You see, although I recognize the idealistic beauty and utility of the laundromat, it’s beaten down and mocked selfishly by the bully that is the convenience of dedicated capacity.

The convenience of discretionary load times. The availability of highly-customized wash/dry settings.  Knowing that I didn’t just put my clothes in a vessel that rid unmentionables from someone’s love-stained sheets.

No nickel-and-diming me for quarters because the spin cycle was too short or where I end up paying twice as much for the utility of centralized community resources that do only 80% of what I need in drying cycles because my heavy thread-count towels are just too damned thick.  Nobody else gets to mistakenly touch my loads or scowl at me because I wasn’t neurotically hawking over the dwell times and exfiltrating things the microsecond a cycle was complete.

It is true, however, that I had to pay for the privilege of doing my laundry when and however I see fit and yes, frankly, sometimes the demand for use outstrips the supply, but ultimately, unless it’s comforter day, I can just plan better to make better use of what I have available to me.  Or I’ll make use of the industrial sized washers for my comforters in well-planned, more reasonably strategic washing sessions for when I need that scale, bulk or don’t really need a delicate cycle.

I can’t tell you what it *actually* costs per load of laundry in my basement. I admit I’ve long written off the books the initial investment of purchase. It seems less than what it costs per load to visit the laundromat.  Perhaps that’s just wishful thinking or perhaps it’s worth every penny not to have to share folding space with a man who reeks of kielbasa and Marlboro lights.  That’s not to say I don’t find him amusing in a cinema-verite sort of way.

Nor do I write off the efficiency and service this place provides.  It’s just that it doesn’t provide all things to all people and that’s OK.  The point is, those that need or like this place come here but you don’t hear them espousing that the only one true way to do laundry is at the laundromat, nor do they speak of the “laundromat revolution” whilst sipping hot chocolate or gatorade and finger-snap clapping to the pretentious preaching of bitter launderers.

It just is and I’m cool with that.  Just like my washing own washer and dryer is.  This simply isn’t about religion, righteousness, idealogs or dogma. It’s about getting my underwear clean.

I visit the laundromat still.  Because it’s useful to me.  Because it offers utility for things that are important to me.  But not because of some idealistic need to share space with others or make someone else money.  Afterall, utility is about choice.  There’s no right or wrong if a solution meets my needs.

So my underwear is washed and prior to drying it — at my leisure — I have managed to consume a snack in between watching something on Netflix, playing with my dog and — surprisingly — contemplating those guitar lessons.  I can’t say I miss the lady in curlers, but the dead potted plant that exists in both realities — my house and the laundromat — offers some comfort through familiarity.

Do I feel guilty for the inefficient hoarding of resources in my basement and not suggesting to my neighbor that they abandon their machines or pool them with mine to produce a kibbutz-like washing utility for the neighborhood at large?

No.

However, I would consider having a folding party if that makes you feel any better.

Utility is in how you use things, not necessarily how it’s offered.

Lather. Rinse. Repeat.

Enhanced by Zemanta

If You Could Have One Resource For Cloud Security…

August 4th, 2010 1 comment

I got an interesting tweet sent to me today that asked a great question:

I thought about this and it occurred to me that while I would have liked to have answered that the Cloud Security Alliance Guidance was my first choice, I think the most appropriate answer is actually the following:

Cloud Security and Privacy: An Enterprise Perspective on Risks and Compliance”  by Tim MatherSubra Kumaraswamy, and Shahed Latif is an excellent overview of the issues (and approaches to solutions) for Cloud Security and privacy. Pair it with the CSA and ENISA guidance and you’ve got a fantastic set of resources.  I’d also suggest George Reese’s excellent book “Cloud Application Architectures: Building Applications and Infrastructure in the Cloud

I suppose it’s only fair to disclose that I played a small part in reviewing/commenting on both of these books prior to being published 😉

/Hoff

Enhanced by Zemanta

On Amrit Williams’ (BigFix) Beyond The Perimeter Podcast

July 18th, 2010 No comments

My good friend Amrit Williams (@amrittsering) from BigFix (congrats on the IBM acquisition!) has an awesome Podcast titled “Beyond the Perimeter.”

He was nice enough to invite me to record episode 93 titled “Is Trust the Real Barrier To Cloud Computing?” (ultimately points you to an iTunes subscription.)

We spoke for almost an hour on all sorts of great discussion points related to Cloud Computing, specifically focusing on Trust (which I define in context as Security, Compliance, Control, Reliability and Privacy.)

We also spoke about the Cloud Security Alliance, CloudAudit and the HacKid conference — three things I am very passionate about.

Thanks Amrit, great conversation as usual.

/Hoff

Enhanced by Zemanta

Incomplete Thought: Why We Need Open Source Security Solutions More Than Ever…

July 17th, 2010 1 comment
Illustrates a rightward shift in the demand curve.
Image via Wikipedia

I don’t have time to write a big blog post and quite frankly, I don’t need to. Not on this topic.

I do, however, feel that it’s important to bring back into consciousness how very important open source security solutions are to us — at least those of us who actually expect to make an impact in our organizations and work toward making a dent in our security problem pile.

Why do open source solutions matter so much in our approach to dealing with securing the things that matter most to us?

It comes down to things we already know but are often paralyzed to do anything about:

  1. The threat curve and innovation of attacker outpaces that of the defender by orders of magnitudes (duh)
  2. Disruptive technology and innovation dramatically impacts the operational, threat and risk modeling we have to deal with (duh duh)
  3. The security industry is not in the business of solving security problems that don’t have a profit motive/margin attached to it (ugh)

We can’t do much about #1 and #2 except be early adopters, by agile/dynamic and plan for change. I’ve written about this many times and built and entire series of talks presentations (Security and Disruptive Innovation) that Rich Mogull and I have taken to updating over the last few years.

We can do something about #3 and we can do it by continuing to invest in the development, deployment, support, and perhaps even the eventual commercialization of open source security solutions.

To be clear, it’s not that commercialization is required for success, but often it just indicates it’s become mainstream and valued and money *can* be made.)

When you look at the motivation most open source project creators bring a solution to market, it’s because the solution generally is not commercially available, it solves an immediate need and it’s contributed to by a community. These are all fantastic reasons to use, support, extend and contribute back to the open source movement — even if you don’t code, you can help by improving the roadmaps of these projects by making suggestions and promoting their use.

Open source security solutions deliver and they deliver quickly because the roadmaps and feature integration occur in an agile, meritocratic and vetted manner than often times lacks polish but delivers immediate value — especially given their cost.

We’re stuck in a loop (or a Hamster Sine Wave of Pain) because the problems we really need to solve are not developed by the companies that are in the best position to develop them in a timely manner. Why? Because when these emerging solutions are evaluated, they live or die by one thing: TAM (total addressable market.)

If there’s no big $$$ attached and someone can’t make the case within an organization that this is a strategic (read: revenue generating) big bet, the big companies wait for a small innovative startup to develop technology (or an open source tool,) see if it lives long enough for the market demand to drive revenues and then buy them…or sometimes develop a competitive solution.

Classical crossing the chasm/Moore stuff.

The problem here is that this cycle is broken horribly and we see perfectly awesome solutions die on the vine. Sometimes they come back to life years later cyclically when the pain gets big enough (and there’s money to be made) or the “market” of products and companies consolidate, commoditize and ultimately becomes a feature.

I’ve got hundreds of examples I can give of this phenomenon — and I bet you do, too.

That’s not to say we don’t have open-source-derived success stories (Snort, Metasploit, ClamAV, Nessus, OSSec, etc.) but we just don’t have enough of them. Further, there are disruptions such as virtualization and cloud computing that fundamentally change the game that we can harness in conjunction with open source solutions that can accelerate the delivery and velocity of solutions because of how impacting the platform shift can be.

I’ve also got dozens of awesome ideas that could/would fundamentally solve many attendant issues we have in security — but the timing, economics, culture, politics and readiness/appetite for adoption aren’t there commercially…but they can be via open source.

I’m going to start a series which identifies and highlights solutions that are either available as kernel-nugget technology or past-life approaches that I think can and should be taken on as open source projects that could fundamentally help our cause as a community.

Maybe someone can code/create open source solutions out of them that can help us all.  We should encourage this behavior.

We need it more than ever now.

/Hoff

Enhanced by Zemanta

CLOUDINOMICON: Idempotent Infrastructure, Survivable Systems & Bringing Sexy Back to Information Centricity

July 7th, 2010 1 comment

I’m hurrying to polish up the next in my series of virtualization and cloud computing security presentations which I’m going to give at this year’s Black Hat conference in Las Vegas on July 29th.  I’m speaking from 10-11am on day two up next to folks like Jeremiah Grossman, Moxie Marlinspike, Ivan Ristic, Haroon Meer…quite the “power hour” as someone said on the Twitter.

At any rate, I started the series a couple of years ago with the following progression:

  1. The Four Horsemen of the Virtualization Security Apocalypse
  2. The Frogs Who Desired a King: A Virtualization & Cloud Computing Fable Set To Interpretative Dance
  3. Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure

I proudly present numero quatro:

CLOUDINOMICON: Idempotent Infrastructure, Survivable Systems & Bringing Sexy Back to Information Centricity

Mass-market, low-cost, commodity infrastructure-as-a-Service Cloud Computing providers abstract away compute, network and storage and deliver hyper-scaleable capabilities.

This “abstraction distraction” has brought us to the point where the sanctity and security of the applications and information transiting them are dependent upon security models and expertise rooted in survivable distributed systems, at layers where many security professionals have no visibility.

The fundamental re-architecture of the infostructure, metastructure and infrastructure constructs in this new world forces us back to the design elements of building survivable systems focusing on information centricity — protecting the stuff that matters most in the first place.

The problem is that we’re unprepared for what this means and most practitioners and vendors focused on the walled garden, perimeterized models of typical DMZ architecture are at a loss as to how to apply security in a disintermediated and distributed sets of automated, loosely-coupled resources.

We’re going to cover the most salient points relating to how IaaS Cloud architecture shifts how, where and who architects, deploys and manages security in this “new world order” and what your options are in making sustainable security design decisions.

It’s progressing nicely.  Hope to see you there (and at Defcon)

The Security Hamster Sine Wave Of Pain: Public Cloud & The Return To Host-Based Protection…

July 7th, 2010 7 comments
Snort Intrusion Detection System Logo
Image via Wikipedia

This is a revisitation of a blog I wrote last year: Incomplete Thought: Cloud Security IS Host-Based…At The Moment

I use my ‘Security Hamster Sine Wave of Pain” to illustrate the cyclical nature of security investment and deployment models over time and how disruptive innovation and technology impacts the flip-flop across the horizon of choice.

To wit: most mass-market Public Cloud providers such as Amazon Web Services rely on highly-abstracted and limited exposure of networking capabilities.  This means that most traditional network-based security solutions are impractical or non-deployable in these environments.

Network-based virtual appliances which expect generally to be deployed in-line with the assets they protect are at a disadvantage given their topological dependency.

So what we see are security solution providers simply re-marketing their network-based solutions as host-based solutions instead…or confusing things with Barney announcements.

Take a press release today from SourceFire:

Snort and Sourcefire Vulnerability Research Team(TM) (VRT) rules are now available through the Amazon Elastic Compute Cloud (Amazon EC2) in the form of an Amazon Machine Image (AMI), enabling customers to proactively monitor network activity for malicious behavior and provide automated responses.

Leveraging Snort installed on the AMI, customers of Amazon Web Services can further secure their most critical cloud-based applications with Sourcefire’s leading protection. Snort and Sourcefire(R) VRT rules are also listed in the Amazon Web Services Solution Partner Directory, so that users can easily ensure that their AMI includes the latest updates.

As far as I can tell, this means you can install a ‘virtual appliance’ of Snort/Sourcefire as a standalone AMI, but there’s no real description on how one might actually implement it in an environment that isn’t topologically-friendly to this sort of network-based implementation constraint.*

Since you can’t easily “steer traffic” through an IPS in the model of AWS, can’t leverage promiscuous mode or taps, what does this packaging implementation actually mean?  Also, if  one has a few hundred AMI’s which contain applications spread out across multiple availability zones/regions, how does a solution like this scale (from both a performance or management perspective?)

I’ve spoken/written about this many times:

Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where… and

Dear Public Cloud Providers: Please Make Your Networking Capabilities Suck Less. Kthxbye

Ultimately, expect that Public Cloud will force the return to host-based HIDS/HIPS deployments — the return to agent-based security models.  This poses just as many operational challenges as those I allude to above.  We *must* have better ways of tying together network and host-based security solutions in these Public Cloud environments that make sense from an operational, cost, and security perspective.

/Hoff

Related articles by Zemanta

* I “spoke” with Marty Roesch on the Twitter and he filled in the gaps associated with how this version of Snort works – there’s a host-based packet capture element with a “network” redirect to a stand-alone AMI:

@Beaker AWS->Snort implementation is IDS-only at the moment, uses software packet tap off customer app instance, not topology-dependent

and…

they install our soft-tap on their AMI and send the traffic to our AMI for inspection/detection/reporting.

It will be interesting to see how performance nets out using this redirect model.

Enhanced by Zemanta

The Classical DMZ Design Pattern: How To Kill Security In the Cloud

July 7th, 2010 6 comments

Every day I get asked to discuss how Cloud Computing impacts security architecture and what enterprise security teams should do when considering “Cloud.”

These discussions generally lend themselves to a bifurcated set of perspectives depending upon whether we’re discussing Public or Private Cloud Computing.

This is unfortunate.

From a security perspective, focusing the discussion primarily on the deployment model instead of thinking holistically about the “how, why, where, and who” of Cloud, often means that we’re tethered to outdated methodologies because it’s where our comfort zones are.

When we’re discussing Public Cloud, the security teams are starting to understand that the choice of compensating controls and how they deploy and manage them require operational, economic and architectural changes.  They are also coming to terms with the changes to application architectures as it relates to distributed computing and SOA-like implementation.  It’s uncomfortable and it’s a slow-slog forward (for lots of good reasons,) but good questions are asked when considering the security, privacy and compliance impacts of Public Cloud and what can/should be done about them and how things need to change.

When discussing Private Cloud, however, even when a “clean slate design” is proposed, the same teams tend to try to fall back to what they know and preserve the classical n-tier application architecture separated by physical or virtual compensating controls — the classical split-subnet DMZ or perimeterized model of “inside” vs “outside.” They can do this given the direct operational control exposed by highly-virtualized infrastructure.  Sometimes they’re also forced into this given compliance and audit requirements. The issue here is that this discussion centers around molding cloud into the shape of the existing enterprise models and design patterns.

This is an issue; trying to simultaneously secure these diametrically-opposed architectural implementations yields cost inefficiencies, security disparity, policy violations, introduces operational risk and generally means that  the ball doesn’t get moved forward in protecting the things that matter most.

Public Cloud Computing is a good thing for the security machine; it forces us to (again) come face-to-face with the ugliness of the problems of securing the things that matter most — our information. Private Cloud Computing — when improperly viewed from the perspective of simply preserving the status quo — can often cause stagnation and introduce roadblocks.  We’ve got to move beyond this.

Public Cloud speaks to the needs (and delivers on) agility, flexibility, mobility and efficiency. These are things that traditional enterprise security are often not well aligned with.  Trying to fit “Cloud” into neat and tidy DMZ “boxes” doesn’t work.  Cloud requires revisiting our choices for security. We should take advantage of it, not try and squash it.

/Hoff

Enhanced by Zemanta

Friday Cloud Poetry: “On the Bullshit That is False Cloud”

June 25th, 2010 3 comments

I was inspired to write this given the latest round of marketing being tended to by Amazon Web Services in their renewed campaign to convince Enterprises CIO’s that their server-hugging IT teams are luddites and interested in nothing more than boat anchoring the success of their companies to some desperate need to buy legacy kit.

The “public-all-or-nothing” approach being hammered by AWS simply ignores the reality that the very customers they hope to woo face on a daily basis and instead seeks to rub their noses in the idealism that we should all simply trust that public, mass-market, one-size-fits-all Clouds are ready for critical, compliance-shackled, and heavily regulated applications today.

Werner, this one’s for you…

If the language of Cloud
Were something to parse
You’d find that some constructs
are rooted in farce

Dogmatic pursuits
of cloud terms that are pure
Yields terms of endearment
some profound, some demure

“Private Cloud is a false cloud!”
Werner peddles his schpiel
That’s to be expected
given where he gets his next meal

Cloud’s not about exclusion
There’s no right or no wrong
It’s not a crusade
OR a kumbayah song

Public or private
Inside or out,
Serving the business
is what cloud’s all about

If you make this religious,
Telling people to choose
All you’ll accomplish
is how fast you’ll lose

Say what you’re good at
What value you add
Not that differing approaches
Are inherently bad

Be evangelistic for sure
Promote Public Cloud’s virtue
And don’t be afraid
Private Cloud’s not out to hurt you

The reality is
No matter how you try and avoid it
Private cloud will add value,
No, you haven’t destroyed it

The value prop’s clear
On where each model works best
The market will sort out
where the laurels will rest

Public Cloud is fantastic
Private Cloudies agree
Hybrid models will win
Just wait and you’ll see

Related articles by Zemanta

Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Poetry Tags:

All For One, One For All? On Standardizing Virtual Appliance Operating Systems

June 11th, 2010 6 comments
SuSE logo
Image via Wikipedia

Hot on the tail of the announcement that VMware and Novell are entering into a deeper “strategic partnership” in order to deliver and support SUSE Linux Enterprise Server (SLES) for VMware vSphere environments, was an interesting blog post from Stu (@vinternals) titled “Enter the Appliance.

Now, before we get to Stu’s post, let’s look at the language from the press release (the emphasis is mine):

VMware and Novell today announced an expansion to their strategic partnership with an original equipment manufacturer (OEM) agreement through which VMware will distribute and support the SUSE® Linux Enterprise Server operating system. Under the agreement, VMware also intends to standardize its virtual appliance-based product offerings on SUSE Linux Enterprise Server.

Customers who want to deploy SUSE Linux Enterprise Server for VMware® in VMware vSphere™ virtual machines will be entitled to receive a subscription to SUSE Linux Enterprise Server that includes patches and updates as part of their newly purchased qualifying VMware vSphere license and Support and Subscription. Under this agreement, VMware and its extensive network of solution provider partners will also be able to offer customers the option to purchase technical support for SUSE Linux Enterprise Server delivered directly by VMware for a seamless support experience. This expanded relationship between VMware and Novell benefits customers by reducing the cost and complexity of deploying and maintaining an enterprise operating system with VMware solutions.

As a result of this expanded collaboration, both companies intend to provide customers the ability to port their SUSE Linux-based workloads across clouds.  Such portability will deliver choice and flexibility for VMware vSphere customers and is a significant step forward in delivering the benefits of seamless cloud computing.

Several VMware products are already distributed and deployed as virtual appliances. A virtual appliance is a pre-configured virtual machine that packages an operating system and application into a self-contained unit that is easy to deploy, manage and maintain. Standardizing virtual appliance-based VMware products on SUSE Linux Enterprise Server for VMware® will further simplify the deployment and ongoing management of these solutions, shortening the path to ROI.

What I read here is that VMware virtual appliances — those VMware products packaged as virtual appliances distributed by VMware — will utilized SLES as the underlying operating system of choice. I don’t see language or the inference that other virtual appliance ISVs will be required to do so

To that point, Stu’s blog post said:

VMware will be adopting SUSE Linux Enterprise Server, SLES, as the single platform for their virtual appliances.

I’ve ranted in the past about the problem with virtual appliances. Everything from the lack of a standard Linux platform even within a single vendor (let alone amongst multiple vendors), to the additional overhead such a model of software distribution would place upon software vendors, to the security needs of the Enterprise around patch response times etc. And today, every single one of those arguments has been nullified in one fell swoop. Hallelujah, someone was listening after all!

So far, so good. Seems pretty much in-line with what VMware said.

Here’s the interesting assertion Stu makes that inspired my commentary:

If you’re a software vendor looking to adopt the virtual appliance model to distribute your wares then I have some advice for you – if you’re not using SLES for the base of your appliance, start doing so. Now. This partnership will mean doors that were previously closed to virtual appliances will now be opened, but not to any old virtual appliance – it will need to be built on an Enterprise grade distro. And SLES is most certainly that.

Chris Wolf, Stu and I had a bit of banter on Twitter regarding this announcement wherein I suggested there’s a blurring of the lines and a conflation of messaging as well as a very unique perspective that’s not being discussed.

Specifically, I don’t see where it was implied that ISV’s would be forced to adopt SLES as their OS of choice for virtual appliances.  I’m not suggesting it’s not compelling to do so for the support and distribution reasons stated above, but I suggest that the notion that “…doors that were previously closed to virtual appliances” from the perspective of support and uniformity of disto will also have and equal and opposite effect caused by a longer development lifecycle for many vendors.

Especially networking and security ISVs looking to move their products into a virtual appliance offering.

I summed up many of the issues associated with virtual security and networking appliances in my Four Horsemen of the Virtualization Security Apocalypse presentation, and given how the definition and capabilities of “the network” are (d)evolving (depending upon how you view abstraction) you might also find Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where… an interesting read:

What does this mean?  It means that ultimately to ensure their own survival, virtualization and cloud providers will depend less upon virtual appliances and add more of the basic connectivity AND security capabilities into the VMMs themselves as its the only way to guarantee performance, scalability, resilience and satisfy the security requirements of customers. There will be new generations of protocols, APIs and control planes that will emerge to provide for this capability, but this will drive the same old integration battles we’re supposed to be absolved from with virtualization and Cloud.

Tell me that’s not what’s happening *right* now.

Unlike most user-facing or service-delivery applications that are not topology sensitive (that is, they simply expect to be able to speak to “the network” without knowing anything about it,) network and security ISVs do very interesting things with drivers and kernel-space code in order to deal with topology, where they sit in the stack, and how they improve performance and stability that are extremely dependent upon direct access to hardware or at the very least, customer drivers or extended/hacked kernels.

One of the reasons you see a slow trickle of network and security virtual appliances is because of these bespoke OS builds and what virtualization has done to how these services are delivered, scaled and deal with resilience.  We’ve already seen the challenge of ISVs having to re-write code to fit the VMsafe fast/slow-path driver model.

You can imagine the consternation involved if what Stu alluded to is actually required — that you must build your virtual appliances on a specific OS.  It’s going to slow down innovation and delivery of solutions if the ISV does not (for any number of valid reasons) use SLES.  This is also one of the downsides of a JEOS approach.

Stu’s warnings about compliance to SLES development notwithstanding, this puts ISVs in a delicate position — one they’ve faced before but is now exacerbated by virtualization and Cloud.  Security vendors generally minimize and harden OS stacks to fit their “application” and then tune the environment accordingly.  We’re already introducing new monocultures and uniformity in attack surfaces with hypervisors.  Are we going to do the same with the operating systems that power the virtual appliances/virtual machines that run atop them — especially those designed to protect these very systems?

Diversity is a good thing — at least when it comes to your networking and security infrastructure.  While I happen to work for a networking vendor, we all recognize that uniformity brings huge benefits as well as the potential for nasty concerns.  If you want an example, check out how a simple software error affected tens of millions of users of WordPress (WordPress and the dark side of multitenancy.) While we’re talking about a different layer in the stack, the issue is the same.

I totally grok the standardization argument for the cost control, support and manageability reasons Stu stated but I am also fearful of the extreme levels of lock-in and monoculture this approach can take.

/Hoff

Enhanced by Zemanta