Rational Survivability

There's been a ton of back and forth recently debating the arguments — pro and con — of the need for and very existence of "private clouds."

How many of your friends do you know that would never be caught dead at a karaoke bar belting out 80's hair band tunes and looking like complete tools? 

How
many of them are completely unafraid, however, to make complete idiots of themselves and rock out to the
same musical arrangements in front of total strangers because instead of "karaoke" it's
called "Guitar Hero" and runs on an XBox in the living room rather
than the "Tiki Room" on Wednesday nights?

With all the definitions of the Cloud and the vagaries associated with differentiated value propositions of each, folks have begun to use the phrases "jumping the shark" and "Cloud Computing" in the same breath.

For the sake of argument, if we boil down what Cloud Computing means in simpler and more familiar terms and agree to use rPath's definition (from Cloud Computing in Plain English) as an oversimplified example we get:

Again, overly-simplified example notwithstanding, what's interesting to me — and the reason for the goofy title and metaphor associated with this post — is that with the popularity of "Cloud" becoming the umbrella terminology for the application of proven concepts (above) which harness technology and approaches we already have, we're basically re-branding a framework of existing capabilities and looking to integrate them better.

…oh, and make a buck, too.

That's not to diminsh the impact and even value of the macro-trends associated with Cloud such as re-perimeterization, outsourcing, taking cost of the business, economies of scale, etc., it's just a much more marketable way of describing them.

The cloud: a cooler version of Internet karaoke…

/Hoff

*Image of Triston McIntyre from ITKnowledgeExchange

I'll be updating my speaking itinerary shortly, but I wanted to let folks know I'm working on three major VirtSec/CloudSec presentations for 2009:
 


The Frogs Who Desired a King

The Frogs Who Desired a King is based on the topical reference to one of Aesop's fable about a discontented population of frogs who appealed to Zeus for a king.

Ultimately, through a comedy of errors, the frogs finally got their new king — a stork — which promptly ate them.

We, as a discontented legion of frogs, decry our dark overlords' choices (or lack thereof) of security in virtualized and cloud computing environments and long for security solutions to magically solve all our problems. 

Just like the frogs, we better be careful what we wish for, as our prayers might just be answered, consuming us all. This is the sequel to my "Four Horsemen of the Virtualization Security Apocalypse" series.

Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure

What was in is now out. 

This metaphor holds true not only as an accurate analysis of adoption trends of disruptive technology and innovation, but also parallels the amazing velocity of how our datacenters are being re-perimiterized and quite literally turned inside out.

One of the really scary things happening with the massive convergence of cloud computing is its effect on security models and the information they seek to protect.

Where and how our data is created, processed, accessed, stored, backed up in what is sure to become massively overlaid cloud-based services — and by whom and whose infrastructure — yields significant concerns related to security, privacy, compliance and survivability. 

This "infrastructure intercourse" makes it very interesting to try and secure your assets when you don't own the infrastructure and in many cases cannot provide the same levels of functionality we can today.

Mozart's "The Marriage of Figaro": Complexity & Insecurity Of the Cloud

Mozart's sequel to the Barber of Seville was lauded as one of the most profound works of its time. 

Its staggering complexity, inviting overtures, rich textures and variety of orchestration were perceived by many as unapproachable, unfathomable and in some cases unintelligible. 

Yet so remarkable and unique was the composition that people flocked to its performances although in many cases were blinded by the simplicity of its underlying complexity.

Such are the parallels with the deeply profound cacophony surrounding the issues of securing Cloud Computing and the tonal miscues hidden amongst its various acts.

This presentation will review the most pressing security, privacy, sustainability and resiliency
issues surrounding the marriage of convenience, economics and computing.

It is my pleasure to introduce the fruits of the labor of months minutes of diligent research and engineering prowess — my opus magnum — the next generation of Cloud Computing.  Pending standards-body approval shortly:

I'm looking for extensive peer review prior to standards body submission.  Open source also considered.  Please ensure you comment below in order to ensure transparency.  There are no ivory towers here, flame away (although you might want to open the window first.)

/Hoff

Here's a theme I've been banging around for quite some time as it relates to virtualization, cloud computing and security.  I've never really sat down and written about it, however.

As we trend towards consolidating and (re)centralizing our computing platforms — both endpoints and servers — using virtualization and cloud computing as enablers to do so, we're also simultaneously dealing with the decentralization and distributed data sets that come with technologies such as Web2.0, mobility and exposure of APIs from cloud platforms.*

So here we are all frothed up as virtualization and cloud computing have, in a sense, led us back to the resource-based consolidation of the mainframe model with all it's centralized splendor and client virtualization/thin clients/compartmentalized remote access is doing the same thing for endpoints. 

But the interesting thing is that with Moore's Law, the endpoints are also getting more and more powerful even though we're dumbing them down and trying to make their exposure more limited despite the fact that they can still efficiently process and store data locally.

These models, one could argue, are diametrically opposed when describing how to secure the platforms versus the information that resides on or is utilized by them.  As the cyclic waffling between centralized versus distributed continues, the timing of how and where we adapt to securing them always lags behind.  Which do we focus on securing and where?  The host, centralized server, network.

The unfortunate answer is always "yes."

Remember this (simplified) model of how/where we secure things?


If you juxtapose the image above mentally with how I represent the centralized <–> distributed trends in IT below, it's no wonder we're always behind the curve.  The computing model technology changes much more quickly than the security technology and processes do, thus the disconnect:

I need to update the diagram above to split out the "computing" layer
into client and server as well as extend the data layer to reference
storage modalities also, but it gets the job done.

At any rate, it's probably obvious and common sense, but when explaining to people why I spend my time pointing out gaps with security in virtualization and cloud models, I found this useful.

/Hoff

* It's important to note that while I refer to/group cloud computing models as centralized, I understand they have a distributed element to them, also.  I would ask you to think about the multiple cloud overlays as centralized resources, regardless of how intrinsically "distributed" in processing/load balancing they may be.

P.S. I just saw an awesome post titled "The Rise of the Stupid Endpoint" on the vinternals blog that shares many of the same points, although much more eloquently.  Check it out here.  Awesome!

In honor of my friend @quine on Twitter who today complained thusly:


In case you're reading this with Lynx (you web pimp, you!,) Zach was lamenting the fact that vendors who don't support customer operating systems of choice are simply sloughing off development efforts and support by suggesting that customers should simply run it as a VM instead.

Ah, it used to be called "software," but now it's a "virtual appliance!"  Silly rabbit, tricks are for kids.

One might suggest this is a perfectly reasonable use of virtualization technology — neigh one of the very purposes behind its genesis.  I'd agree, to a point.  However, I've noticed an alarming uptake recently by product managers who are simply short-cutting roadmap/development paths by taking the "lazy" way out.

Hey, it cuts down support, testing, regression and troubleshooting…for the vendor.  But in my favorite commentary, it's simply a "squeezing the balloon problem" because it surfaces a whole host of other issues such as performance, scale, and in some cases support for various virtualization platforms.

What say you?  Do you see this happening more in your enterprise?  Do you care?  Is it a good thing?

/Hoff

Alan from the VirtualDC blog wrote a great post today titled "Cloud Security: A New Level of Trust" summarizing some of his thoughts regarding Cloud (in)security.

It's a little depressing because that "new level" of trust he's referring to isn't heightened, it's significantly reduced.  I'll hack his longer post a bit to extract two interesting and relevant nuggets that focus on the notion of this changing nature of trust:

1. Security has different meanings and requirements depending on the context of how a particular service is accessed or invoked.
2. So moving forward, as the security people tear apart the (in)security of cloud computing, the rest of the world will just need to take that leap of trust. A lowering of our standards for what we can control in the cloud’s outsourced data model.

In simply closing our eyes, holding our breath and accepting that in the name of utility, agility, flexibility, and economy, we're ignoring many of the lessons we've learned over the years, we are repeating the same mistakes and magically expecting they will yield a different outcome.

I'll refer back to one of my favorite axioms:


We're willing to give up and awful lot for the sake of convenience, don't you think.  Look, I accept the innovation and ultimate goodness that will come out of this new world order, really I do.  Heck, I use many of these services. 

I also see how this new suite of adapted services are beginning to break down in the face of new threats, use cases and risk models by a cross-pollinated generation of anonymized users that simply do not care about things like privacy or security — until it affects them personally.  Then they're outraged.  Then the next day, they're back to posting about how drunk they were at the orgy they attended last night (but they use SSL, so it's cool…)

So for me, security and the cloud is really a matter of RUST, not trust: the corrosion of expectations, requirements, controls and the relaxation of common sense and diligence for the sake of "progress."

Same as it ever was, same as it ever was…

/Hoff

If I may be as bold to call Andy Jaquith a friend, I'll do so as I welcomed both his first research report and blog as an analyst for Forrester.

Andy's first topic — Data-Centric Security Requires Devolution, Not a Revolution — is a doozy, and an important one given the recent re-focus on information protection.  The notion of data-centric security has caused quite the stir over the last year with the maturation, consolidation and (some might say) commoditzation of certain marketspaces (DLP) into larger mainstream security product suites.

I will admit that I did not spend the $350 to read Andy's research.  As much as I like to support the ever-turning wheels of the analyst sausage machine, I'm going to upgrade to Apple's newly-announced iLife/iWork '09 bundle instead.  Sorry, Andy.  I'll buy you that beer instead.

However, Andy wrote a great blog entry summarizing the research here:

My only comments are that much like the X-Files, the truth is "out there."  It is most certainly somewhere in between as users and the business will always take the convenient path of least resistance and security will impose the iron fist. 

Securing information must be a cooperative effort that involves the broader adoption of pervasive discovery and classification capabilities across the entire information lifecycle.  The technology has to become as transparent as possible such that workflow isn't interrupted.  That's no easy task

Rich Mogull and I have been writing and presenting about this for quite some time, and we're making evolutionary progress, but not revolutionary progress.

To that point, I might have chosen a different by-line.  Instead of "devolution, not a revolution," I would suggest that perhaps "goverened delegation, not regulation" might be appropriate, too.

Can't wait for that iLife/iWork bundle!

/Hoff