Rational Survivability

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!

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

This post contains nothing particularly insightful other than a pronounced giant sucking sound that's left a vacuum in terms of forward motion regarding security and virtualization.

Besides the sumo suit wrestling match I'm organizing between myself and Simon Crosby at this year's coming RSA 2009 show, I'm really excited to announce that there will be another exciting virtualization security (VirtSec) event happening at the show.

"In this verbal cage match session, two well known critics of virtualization security take on two virtualization company CTOs as they spar over how best to secure virtualization platforms: who should be responsible for securing it, and how that ultimately impacts customers and attackers.  We have Hoff and Skoudis versus Crosby and Herrod.  Refereeing will be respected analyst, Antonopoulos."

I just read the latest blog of Alistair Croll from GigaOm titled "Cloud Security: The Sky Is Falling!" in which he suggests that we pillow-hugging security wonks ought to loosen our death grips on our data because not only are we flapping our worry feathers for nothing, but security in "the Cloud" will result in better security than we have today. 

As "the Cloud" provider adds customers, the capability to secure the infrastructure and the data transiting it, ultimately becomes an issue of scale, too. The more automation that is added, the more false positives show up, especially in light of the fact that the service provider has little or no context of the information, business processes or business impact that their monitoring tools observe.  You can get rid of the low-hanging fruit, but when it comes down to impacting the business, some human gets involved.

Read more…

I'm working on the sequel to my Four Horsemen of the Virtualization Security Apocalypse presentation.

It's called "The Frogs Who Desperately Wanted a King: An Information Security Fable of Virtualization, RTI and Cloud Computing Security." (Okay, it also has the words "interpretive dance" in it, but that's for another time…)

Many of the interesting issues from the Four Horsemen regarding the deficiencies of security solutions and models in virtualized environments carries over directly to operationalizing security in the Cloud. 

As a caveat, let's focus on a cost-burdened "large" enterprise who's involved in moving from physical to virtual to cloud-based services.

I'm not trying to make a habit of picking on Amazon AWS, but it's just such a fantastic example for my point, which is quite simply:

Why?  Let me paint the picture…

In non-virtualized environments, we generally use dedicated appliances or integrated solutions that provide one of more discrete security functions. 

These solutions are built generally on hardened OS's, sometimes using custom hardware and sometimes COTS boxes which are tarted up.  They are plumbed in between discretely segregated (physical or logical) zones to provide security boundaries defined by arbitrary policies based upon asset classification, role, function, access, etc.  We've been doing this for decades.  It's the devil we know.

In virtualized environments, we currently experience some real pain when it comes to replicating the same levels of security, performance, resiliency, and scale using software-based virtual appliances to take the place of the hardware versions in our physical networks when we virtualize the interconnects within these zones.

There are lots of reasons for this, but the important part is realizing that many of the same hardware solutions are simply not available as virtual appliances and even when they are, they are often not 1:1 in terms of functionality or capability.  Again, I've covered this extensively in the Four Horsemen.

So if we abstract this to its cloudy logical conclusion, and use AWS as the "platform" example, we start to face a real problem for an enterprise that has a decade(s) of security solutions, processes and talent that is focused on globalizing, standardizing and optimizing their existing security infrastructure and are now being forced to re-evaluate not only the technology selection but the overall architecture and operational model to support it.

Now, it's really important that you know, dear reader, that I accept that one can definitely deploy security controls instantiated as both network and host-based instances in AWS.  There are loads of options, including the "firewall" provided by AWS.

However, the problem is that in the case of building an AMI for AWS supporting a particular function (firewall, WAF, IPS, IDS, etc.) you may not have the same solutions available to you given the lack of support for a particular distro, lack of "port" to a VA/VM, or issues surrounding custome kernels, communication protocols, hardware, etc…  You may be limited in many cases to having to rely on open source solutions.

In fact, when one looks at most of the examples given when describing securing AWS instances, they almost always reference OSS solutions such as Snort, OSSEC, etc.  There's absolutely NOTHING wrong with that, but it's only one dimension.

That's going to have a profound effect across many dimensions.  In many cases, enterprises have standardized on a particular solution not because it's special from a "security" perspective, but because it's the easiest to manage when you have lots of them and they are supportable 24/7 by vendors with global reach and SLA's that represent the criticality of their function.

That is NOT to say that OSS solutions are not easy to manage or supportable in this fashion, but I believe it's a valid representation of the state of things.

(Why am I getting so defensive about OSS? 😉

Taking it further, and using my favorite PCI in the Cloud argument, what if the web application firewall that you've spent hundreds of thousands of dollars purchasing, tuning and deploying in support of PCI DSS throughout the corporate enterprise simply isn't available as a software module installable in an AMI in the cloud?  Or the firewall?  Or the IPS? 

In the short term this is a real problem for customers.  In the long term, it's another potential life preserver for security ISV's and an opportunity for emerging startups to think about new ways of solving this problem.

/Hoff

I read James Urquhart's first blog post written under the Cisco banner today titled "The network: the final frontier for cloud computing" in which he describes the evolving role of "the network" in virtualized and cloud computing environments.

The gist of his post, which he backs up with examples from Greg Ness' series on Infrastructure 2.0, is that in order to harness the benefits of virtualization and cloud computing, we must automate; from the endpoint to the underlying platforms — including the network — manual processes need to be replaced by automated capabilities:

When was the last time you thought “network” when you heard
“cloud computing”? How often have you found yourself working out
exactly how you can best utilize network resources in your cloud
applications?  Probably never, as to date the network hasn’t registered
on most peoples’ cloud radars.

This is understandable, of course, as the early cloud efforts try to
push the entire concept of the network into a simple “bandwidth”
bucket.  However, is it right? Should the network just play dumb and
let all of the intelligence originate at the endpoints?
…
The writing is on the wall. The next frontier to get explored in
depth in the cloud world will be the network, and what the network can
do to make cloud computing and virtualization easier for you and your
organization

If you walked away from James' blog as I did initially, you might be left with the impression that this isn't really about "the network" gaining additional functionality or innovative capabilities, but rather just tarting up the ability to integrate with virtualization platforms and automate it all.

Doesn't really sound all that sexy, does it.  Well, it's really not, which is why even today in non-virtualized environments we don't have very good automation and most processes still come down to Bob at the helpdesk. Virtualization and cloud are simply giving IT a swift kick in the ass to ensure we get a move on to extract as much efficiency and remove as much cost from IT as possible.

Don't be fooled by the simplicity of James' post, however, because there's a huge moose lurking under the table instead of on top of it and it goes toward the fundamental crux of the battle brewing between all those parties interested in becoming your next "datacenter OS" provider.

There exists one catalytic element that produces very divergent perspectives in IT around what, where, why and who automates things and how, and that's the very definition of "the network" in virtualized and cloud models.

How someone might describe "the network" as either just a "bandwidth bucket" of feeds and speeds or an "intelligent, aware, sentient platform for service delivery" depends upon whether you're really talking about "the network" as a subset or a superset of "the infrastructure" at large.

Greg argues that core network services such as IP adddress management, DNS, DHCP, etc. are part of the infrastructure and I agree, but given what we see today, I would say that they are part-in-parcel NOT a component of "the network" — they're generally separate and run atop the plumbing.  There's interaction, for sure, but one generally relies upon these third party service functions to deliver service.  In fact, that's exactly the sort of thing that Greg's company, Infoblox, sells.

This contributes to part of this definitional quandary.

Now we have this new virtualization layer injected between the network and the rest of the infrastructure which provides a true lever and frictionless capability for some of this automation but further confuses the definition of "the network" since so much of the movement and delivery of information is now done at this layer and it's not integrated with the traditional hardware-based network.*

See what I mean in this post titled "The Network Is the Computer…(Is the Network, Is the Computer…)"

This is exactly why you see Cisco's investment in bringing technologies such as VN-Link and the Nexus-1000v virtual switch to virtualized environments; it homogenizes "the network." It claws back the access layer so they can allow the network teams to manage the network again (and "automate" it) while also getting their hooks deeper into the virtualization layer itself. 

And that's where this gets interesting to me because in order to truly automate virtualized and cloud computing environments, this means one of three things as it relates to where core/critical infrastructure services live:

1. They  will continue to be separate as stand-alone applications/appliances or bundled atop an OS
2. They become absorbed by "the (traditional) network" and extend into the virtualization layer
3. They get delivered as part of the virtualization layer

So if you're like most folks and run Microsoft-based "core network services" for things (at least internally) like DNS, DHCP, etc., what does this mean to you?  Well, either you continue as-is via option #1, you transition to integrated services in "the network" via option #2 or you end up with option #3 by the very virtue that you'll upgrade to Windows Server 2008 and Hyper-V anyway.

SO, this means that the level of integration between, say, Cisco and Microsoft will have to become as strong as it is with VMware in order to support the integration of these services as a "network" function, else they'll continue — in those environments at least — as being a "bandwidth bucket" that provides an environment that isn't really automated.

In order to hit the sweet spot here, Cisco (and other network providers) need to then start offering core network services as part of "the network."  This means wrestling it away from the integrated OS solutions or simply buying their way in by acquiring and then integrating these services ($10 Cisco buys Infoblox…)

We also see emerging vendors such as Arista Networks who are entering the grid/utility/cloud computing network market with high density, high-throughput, lower cost "cloud networking" switches that are more about (at least initially) bandwidth bucketing and high-speed interconnects rather than integrated and virtualized core services.  We'll see how the extensibility of Arista's EOS affects this strategy in the long term.

There *is* another option and that's where third party automation, provisioning, and governance suites come in that hope to tame this integration wild west by knitting together this patchwork of solutions. 

What's old is new again.

/Hoff

*It should be noted, however, that not all things can or should be
virtualized, so physical non-virtualized components pose another
interesting challenge because automating 99% of a complex process isn't
a win if the last 1% is a gating function that requires human
interaction…you haven't solved the problem, you've just made it less
steps that still requires Bob at the helpdesk..