Rational Survivability

Over the last two days, I've seen a plethora (yes, Jefe, a plethora) of trade rag and blog articles espousing that The Cloud is more secure than an enterprise's datacenter and that Cloud security concerns are overblown.  I'd pick these things apart, but honestly, I've got work to do.

<sigh>

Here's the problem with these generalizations, even when some of the issues these people describe are actually reasonably good points:

Almost all of these references to "better security through Cloudistry" are drawn against examples of Software as a Service (SaaS) offerings.  SaaS is not THE Cloud to the exclusion of everything else.  Keep defining SaaS as THE Cloud and you're being intellectually dishonest (and ignorant.)

But since people continue to attest to SaaS==Cloud, let me point out something relevant.

There are two classes of SaaS vendors: those that own the entire stack including the platform and underlying infrastructure and those those that don't.  

Those that have control/ownership over the entire stack naturally have the opportunity for much tighter control over the "security" of their offerings.  Why?  because they run their business and the datacenters and applications housed in them with the same level of diligence that an enterprise would.

They have context.  They have visibility.  They have control.  They have ownership of the entire stack.  

The HUGE difference is that in many cases, they only have to deal with supporting a limited number of applications.  This reflects positively on those who say "Cloud SaaS providers are "more secure," mostly because they have less to secure.

Meanwhile those SaaS providers that simply run their appstack atop someone else's platform and infrastructure are, in turn, at the mercy of their providers.  The information and applications are abstracted from the underlying platforms and infrastructure to the point that there is no unified telemetry or context between the two.  Further, add in the multi-tenancy issue and we're now talking about trust boundaries that get very fuzzy and hard to define: who is responsible for securing what.

Just. Like. An. Enterprise. 🙁

Check out the Cloud model below which shows the demarcation between the various layers of the SPI model of which SaaS is but ONE:

The further up the offering stack you go, the more control you have over your information and the security thereof. Oh, and just one other thing.  The notion that Cloud offerings diminish attack surfaces is in many cases a good thing for sophisticated attackers as much as it may act as a deterrent.  Why?  Because now they have a more clearly defined set of attack surfaces — usually at the application layer — that makes their job easier.

Next time one of these word monkeys makes a case for how much more secure The Cloud is and references a SaaS vendor like SalesForce.com (a single application) in comparison to an enterprise running (and securing) hundreds of applications, remind them about this and this, both Cloud providers. I wrote about this last year in an article humorously titled "Cloud Providers Are Better At Securing Your Data Than You Are."

Like I said on Twitter this morning "I *love* the Cloud. I just don't trust it.  Sort of like why I don't give my wife the keys to my motorcycles."

We done now?

/Hoff

I was referenced in a CSO article recently titled "Four Questions On Google App Security." I wasn't interviewed for the story directly, but Bill Brenner simply referenced our prior interviews and my skepticism for virtualization security and cloud Security as a discussion point.

How many of you assume that virtualization is an integral part of cloud computing? From your perspective do you assume one includes the other?  Should you care?

I'm heading out in a few minutes for an all day talk, but I choked on my oatmeal when I read this:

Despite all the hype surrounding cloud computing, the issue of security is one debate that will not go away. It is regularly flagged as one of the potential stumbling blocks to widespread cloud adoption.

He said: “We’ve developed some interesting technologies that allow the separation of applications and data on the same infrastructure. We guarantee the security through Tivoli Security and Identity Management and Authentication software, and we also ensure the separation of workloads through the separation of the virtual machines and also the separation of client data in a shared database.” Speaking to CBR after the press conference, Kloeckner went into more detail about IBM’s cloud security offering.

“Security is not essentially any different from securing any kind of open environment; you have to ensure that you know who accesses it and control their rights. We have security software that allows you to manage identities from an organisational model, from whoever is entitled to use a particular service. We can actually ensure that best practices are followed,” Kloeckner said.

Kloeckner added that most people do not realise just how vulnerable they really are. He said: “Most people, unless forced by regulations, usually treat security as a necessary evil. They say it’s very high on their list, but if you really scratch the service, it’s not obvious to me that best practices are followed.”

Yes, yes. We've talked about this before here. Cisco is introducing a blade chassis that includes compute capabilities (heretofore referred to as a 'blade server.')  It also includes networking, storage and virtualization all wrapped up in a tidy bundle.

QUACK!

It seems that my incomplete thoughts are more popular with folks than the one's I take the time to think all the way through and conclude, so here's the next one…

There is a lot of effort being spent now on attempts to craft standards and definitions in order to provide interfaces which allow discrete Cloud elements and providers to interoperate. Should we not first focus our efforts on ensuring portability between Clouds of our atomic instances (however you wish to define them) and the metastructure* that enables them?

No Good Deed Goes Unpunished…

I've had some fantastic conversations with folks over the last couple of weeks as we collaborated from the perspective of how a network and security professional might map/model/classify various elements of Cloud Computing.

I just spent several hours with folks at ShmooCon (a security conference) winding through the model with my peers getting excellent feedback.  

Prior to that, I've had many people say that the collaboration has yielded a much simpler view on what the Cloud means to them and how to align solutions sets they already have and find gaps with those they don't.

My goal was to share my thinking in a way which helps folks with a similar bent get a grasp on what this means to them.  I'm happy with the results.

And then….one day at Cloud Camp…

However, it seems I chose an unfortunate way of describing what I was doing in calling it a taxonomy/ontology, despite what I still feel is a clear definition of these words as they apply to the work.

I say unfortunate because I came across a post by Steve Oberlin, Cassat's Chief Scientist on his "Cloudology" blog titled "Cloud Burst" that resonates with me as the most acerbic, condescending and pompous contributions to nothingness I have read in a long time.

Steve took 9 paragraphs and 7,814 characters to basically say that he doesn't like people using the words taxonomy or ontology to describe efforts to discuss and model Cloud Computing and that we're all idiots and have provided nothing of use.

The most egregiously offensive comment was one of his last points:

I do think some blame (a mild chastisement) is owed to anyone participating in the cloud taxonomy conversation that is not exercising appropriately-high levels of skepticism and insisting on well-defined and valid standards in their frameworks.  Taxonomies are thought-shaping tools and bad tools make for bad thinking.   One commenter on one of the many blogs echoing/amplifying the taxonomy conversation remarked that some of the diagrams were mere “marketecture” and others warned against special interests warping the framework to suit their own ends.  We should all be such critical thinkers.

I might find more constructive criticism to offer, but the dearth of description and discussion of what it really means (beyond the blog’s comments, which were apparently truncated by TypePad) make the diagram something of a Rorschach test.  Anyone discussing it may be revealing more about themselves than what the concepts suggested by the diagram might actually mean.

NOTHING.

This is the first of my "incomplete thought" entries; thoughts too small for a really meaty blog post, but too big for Twitter.  OK wiseguy.  I know *most* of my thoughts are incomplete, but don't quash my artistic license, mkay?

How many of the cloud providers (IaaS, PaaS) support IPv6 natively or support tunneling without breaking things like NAT and firewalls?  As part of all this Infrastruture 2.0 chewy goodness, from a networking (and security) perspective, it's pretty important.

You want to know how I know that The Cloud is all hot air and will never catch on?

A word of unsolicited advice to those of us trying to help "sort out" Cloud Computing — myself included:

Granted, we mean well in our cautious and guarded admonishment, but it's starting to wear as thin as those who promote Cloud Computing as the second coming (when we all know full well that is Fiber Channel over Token Ring.)

We don't all have to chant the same mantra and we don't have to preach rainbows and unicorns, but it's important to be accurate and balanced.

I, too, am waiting for the day Cloud Computing will wash my car, bring me a beer and make me a ham sandwich. Until that day, instead of standing around trying to look smart by telling everybody that Cloud Computing is nothing more than hot air, how about making a difference by not playing a game of bad news telephone and add something constructive.

There's value in Cloud Computing so how about we move past the "confusing, over-hyped and buzzword" stage and get to work making it straight-forward, realistic and meaningful instead.

/Hoff

I think we have a failure to communicate…or at least I do.

Tonight I was listening to David Linthicum’s podcast titled “The Harsh Realities Of Private Clouds” in which he referenced and lauded Dimitry Sotnikov’s blog of the same titled “No Real Private Clouds Yet?“

I continue to scratch my head not because of David’s statements that he’s yet to find any “killer applications” for Private Clouds but rather the continued unappetizing use of the definition (quoting Dimitry) of a Private Cloud:

In a nutshell, private clouds are Amazon-like cost-effective and scalable infrastructures but run by companies themselves within their firewalls.

This seems to be inline with Gartner’s view of Private Clouds also:

The future of corporate IT is in private clouds, flexible computing networks modeled after public providers such as Google and Amazon yet built and managed internally for each business’s users

My issue is again that of the referenced location and perimeter.  It’s like we’ve gone back to the 80’s with our screened subnet architectural Maginot lines again!  “This is inside, that is outside.”

That makes absolutely zero sense given the ubiquity, mobility and transitivity of information and platforms today.  I understand the impetus to return back to the mainframe in the sky, but c’mon…

For me, I’d take a much more logical and measured approach to this definition. I think there’s a step missing in the definitions above and how Private Clouds really ought to be described and transitioned to.

I think that the definitions above are too narrow end exculpatory in definition when you consider that you are omitting solutions like GoGrid’s CloudCenter concepts — extending your datacenter via VPN onto a cloud IaaS provider whose infrastructure is not yours, but offers you the parity or acceptable similarity in platform, control, policy enforcement, compliance, security and support to your native datacenter.

In this scenario, the differentiator between the “public” and “private” is then simply a descriptor defining from whom and where the information and applications running on that cloud may be accessed:

From the “Internet” = Public Cloud.  From the “Intranet” (via a VPN connection between the internal datacenter and the “outsourced” infrastructure) = Private Cloud.

Check out James Urquhart’s thoughts along these lines in his post titled “The Argument For Private Clouds.”

As I wrote in my post titled “Mixing Metaphors: Private Clouds Aren’t Defined By Their Location“:

Private clouds are about extending the enterprise to leverage infrastructure that makes use of cloud computing capabilities and is not (only) about internally locating the resources used to provide service.  It’s also not an all-or-nothing proposition.

It occurs to me that private clouds make a ton of sense as an enabler to enterprises who want to take advantage of cloud computing for any of the oft-cited reasons, but are loathe to (or unable to) surrender their infrastructure and applications without sufficient control.

Private clouds mean that an enterprise can decide how and how much of the infrastructure can/should be maintained as a non-cloud operational concern versus how much can benefit from the cloud.

Private clouds make a ton of sense; they provide the economic benefits of outsourced scaleable infrastructure that does not require capital outlay, the needed control over that infrastructure combined with the ability to replicate existing topologies and platforms and ultimately the portability of applications and workflow.

These capabilities may eliminate the re-write and/or re-engineering of applications like is often required when moving to typical IaaS (infrastructure as a Service) player such as Amazon.

From a security perspective — which is very much my focus — private clouds provide me with a way of articulating and expressing the value of cloud computing while still enabling me to manage risk to an acceptable level as chartered by my mandate.

So why wouldn’t a solution like GoGrid’s CloudCenter offering paired with CohesiveFT’s VPN Cubed and no direct “public” Internet originated access to my resources count as Private Cloud Computing?

I get all the benefits of elasticity, utility billing, storage, etc., don’t have to purchase the hardware, and I decide based upon risk what I am willing to yield to that infrastructure.

David brought up the notion of proprietary vendor lock-in, but yet we see GoGrid has also open sourced their CloudCenter API OpenSpec…

Clearly I’m mad because I simply don’t see why folks are painting Private Clouds into a corner only to say that we’re years away from recognizing their utility when in fact we have the technology, business need and capability to deliver them today.

/Hoff