Rational Survivability

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 find this case extremely fascinating on many levels.  From eWeek:

You can see the original story from the International Association of Privacy Professionals (IAPP) here.

The implications of this are quite profound as you can imagine.  CEO's and CFO's can be held accountable for crimes committed under their watch, so it's not too far of a stretch to see how privacy officers like Fleischer will have their feet held to the fire when subject to international law that takes a different perspective on the responsibilities associated with privacy than we might. 

How many indictments have we had in the U.S. for the release of information in corporate breaches?  The U.K.?

I'm not making a judgment call on this particular case because I certainly don't have all of the details, but it sets a very interseting precedent.

Imagine if you were a Chief Privacy Officer or perhaps a Chief Information Officer subject to this sort of scrutiny outside of the due care and stewardship requirements of the job in general.  If something bad happens, generally the worst thing that might occur is you lose your job.

Imagine if you were personally liable for the posting of content from millions of users globally and could be sentenced to share a shower and a cell with an angry Italian man who can't get a decent cappuccino.  I can't imagine what that would be like.

This may be the first time a privacy professional has been charged on behalf of the company he/she is employed by, but I will bet this won't be the last time it happens, either.

Besides the impact this can have on employees of providers of service, Google suggests it calls into focus larger issues of Net Neutrality:

An interesting argument for sure and one I can see being debated vigorously.  It's clear Google operates globally, so they must understand this sort of thing could happen.  What about Facebook (sorry, Chris) or MySpace?  What happens when Amazon is used to host data that is mishandled by someone.  What then?

Imagine what fun it's going to be when we're all cloudified and the mash-up frenzy makes the cross-pollenization of information today look orderly; who's responsible then?

What do you think?  Should privacy officers be liable for events like this?  Should CSO's/CISO's and Compliance Managers be liable when a breach occurs exposing protected information?  Think about that answer very carefully.

/Hoff

*You can find Peter Fleischer's blog here.

Here is some of the recent coverage from the last couple of months on topics relevant to content on my blog, presentations and speaking engagements.  No particular order or priority.

Press/Technology & Security eZines:

• Byte & Switch: Securing data wherever it travels
• CSO Online: Hoff – Commode Computing
• Computerworld & CSO Online:  Four questions on Google App Security 
• Dark Reading: Crossing the streams virtually 
• SearchSecurity: PCI needs to address virtualization, experts say
• CSO Online: The myth of Cloud Computing 
• CSO Online: Chris Hoff – On Virtualization and Cloud Computing 
• Computerworld: How can you secure a buzzword? 
• CSO: Security Predictions – What happens next? 
• ITWorld Canada: Security admins offer their risk management pitch

Website/Blog Coverage/Meaningful Links:

• Server Zone: Cloud Ontology – to boldly go where ITIL, Grid and SOA have gone before
• Virtualization.info: Top virtualization blogs of 2008 
• VMware-land: Top 10 Virtualization blogs 
• ebizQ: Naming the part of the cloud
• IT Management & Cloud Blog: And the 2009 Cloudie Award goes to…  
• C|Net Wisdom Of the Clouds: Two ontologies shed light on Cloud Computing 
• SeekingAlpha: Peak IT – The network industry's core challenge
• System Advancements at the Monastery: Recent Cloud Postings
• Meedabyte: Be open to winds of change 
• ZDNet: Will EDoS be the next DDoS?
• Data Center Knowledge: Cloudy Day: CloudSwitch, AWS Torrents, eDoS
• SoftSecurity.com: Will EDoS be the next DDoS?
• The GridPlace.com: In Cloud Computing, a good network gives you control
• RiskAnalys.is: Penetration testing not dead, probably just pining for the fjord
• SYS-CON: How difficult is securing Cloud platforms? Services in a Cloud Computing Environment 
• Data Center Networks (Cisco): Services in a Cloud Computing Environment
• Data Center Links: January Cloud Report
• Symantec Forums: How we win at securing customers in a virtual world
• VMBlog: The Future of virtualization
• Prism: Security – A casualty in the Sovereighnity vs Efficiency tradeoff
• Securosis: How the Cloud destroys everythng I love (about Web App Security)
• CloudAve: Cloud Computing Risks – EDoS
• Elastic Vapor: Cloud attack: Economic denial of sustainability (EDoS)
• Tripwire: Regulations need to get unreal
• Blog Of Trust: Be an IF-MAP Innovator
• DevCentral: The Context-Aware Cloud 
• Law.com: Old habits persist in virtual security 
• Brian Madden: What does Microsoft Azure have to do with us?
• Securosis: Everything old is new again in the fog of the cloud
• Securosis: Cloud Security macro layers
• Telematique: Clouds, the criminal element & V12N to the rescue
• Network Security Blog: PCI Compliance – get it in writing!
• Citrix Community Blog: Hoff is still confused 
• ZDNet: Security will suffer in the financial crisis

I should note that many of my cloud computing writing is being republished over at the SYSCON Cloud Computing Journal with a self-branded mini-site: ChristoferHoff.Sys-Con.com

Podcasts/Webcasts/Video:

• Network Security Podcast Episode 131: Co-hosted with Rich Mogull
• Briefings Direct: Improved insights and analysis from systems logs reduce complexity risks from virtualization
• Virtualization.com: Video interview with Simon Crosby, Citrix CTO (not in it, mentioned) 
• Cisco Data Center Blog: Data Center 3.0 anniversary note & new products video

I am confirmed to  speak at the following upcoming events:

• Source Boston  - Boston, MA – March 11-13
• TechTarget Threat Management Decisions Summit – New York, NY – March 26
• Americas Growth Capital InfoSec Conference (keynote) – San Francisco, CA, April 20
• RSA 2009 (multiple sessions) – San Francisco, CA, April 21-24
• Virtualization Congress – Las Vegas, NV, May 4-7
• (there are others being sorted at the moment) 

I should/will be attending the following events:

• Shmoocon
• Cloud Computing Expo   

/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

NOTE: Please see the continued discussion in the post titled “Update on the Cloud (Ontology/Taxonomy) Model…“

Updated: 3/28/09 v1.5

There have been some excellent discussions of late regarding how to classify and explain the relationships between the many Cloud Computing models floating about.

The comments are working again.  I’ve had 30-40 comments via email/twitter, so if something you wanted to communicate isn’t addressed, fire away below in the comments!

Version 1.5 Diagram (click to expand):

In v1.5 I highlighted the Integration/Middleware layer in a separate color, removed Coghead from the PaaS offering example and made a few other cosmetic alignment changes.

In v1.4 I added the API layer above ‘Applications’ in the SaaS grouping. I split out “data, metadata and content” as three separate elements and added structured/unstructured to the right.  I also separated the presentation layer into “modality and platform.”  Added some examples of layers to the very right.

John Gerber from the Syetem Advancements at the Monastery blog compiled an awesome round-up of Cloud related news/postings.

The blog entry covers many areas of the cloud including security, which I greatly appreciate.

Check it out here.  Well worth the read and the perspective.

/Hoff

I'm happy to say that there appears to be some good news on the PCI DSS front with the promise of a SIG being formed this year for virtualization.  This is a good thing. 

You'll remember my calls for better guidance for both virtualization and ultimately cloud computing from the council given the proliferation of these technologies and the impact they will have on both security and compliance.

In that light, news comes from Troy Leach, technical director of the PCI Security Standards Council via a kind note to me from Michael Hoesing:

This is a good first step.  if you've got input, make sure to contribute!

/Hoff

I wrote about the notion of EDoS (Economic Denial Of Sustainability) back in November.  You can find the original blog post here.

The basic premise of the concept was the following:

I had a thought about how the utility and agility of the cloud
computing models such as Amazon AWS (EC2/S3) and the pricing models
that go along with them can actually pose a very nasty risk to those
who use the cloud to provide service.

That
thought got me noodling about how the pay-as-you-go model could
be used for nefarious means.

Specifically, this
usage-based model potentially enables $evil_person who knows that a
service is cloud-based to manipulate service usage billing in orders of
magnitude that could be disguised easily as legitimate use of the
service but drive costs to unmanageable levels. 

If you take Amazon's AWS usage-based pricing model (check out the cost calculator here,) one might envision that instead of worrying about a lack of resources, the
elasticity of the cloud could actually provide a surplus of compute,
network and storage utility that could be just as bad as a deficit.

Instead
of worrying about Distributed Denial of Service (DDos) attacks from
botnets and the like, imagine having to worry about delicately
balancing forecasted need with capabilities like Cloudbursting to deal
with a botnet designed to make seemingly legitimate requests for
service to generate an economic denial of sustainability (EDoS) —
where the dyamicism of the infrastructure allows scaling of service
beyond the economic means of the vendor to pay their cloud-based
service bills.

At any rate, here are a couple of interesting related items:

1. Wei Yan, a threat researcher for Trend Micro, recently submitted an IEEE journal submission titled "Anti-Virus In-the-Cloud Service: Are We Ready for the Security Evolution?" in which he discusses and interesting concept for cloud-based AV and also cites/references my EDoS concept.  Thanks, Wei!
    
2. There is a tangential story making the rounds recently about how researcher Brett O'Connor has managed to harness Amazon's EC2 to harvest/host/seed BitTorrent files.

   The relevant quote from the story that relates to EDoS is really about the visibility (or lack thereof) as to how cloud networks in their abstraction are being used and how the costs associated with that use might impact the cloud providers themselves.  Remember, the providers have to pay for the infrastructure even if the "consumers" do not:

   "This means, says Hobson, that hackers and other interested parties can
   simply use a prepaid (and anonymous) debit card to pay the $75 a month
   fee to Amazon and harvest BitTorrent applications at high speed with
   little or no chance of detection…

   It's not clear that O'Connor's clever work-out represents anything new
   in principle, but it does raise the issue of how cloud computing
   providers plan to monitor and manage what their services are being used
   for."

It's likely we'll see additional topics that relate to EDoS soon.

UPDATE: Let me try and give a clear example that differentiates EDoS from DDoS in a cloud context, although ultimately the two concepts are related:

DDoS (and DoS for that matter) attacks are blunt force trauma. The goal, regardless of motive, is to overwhelm infrastructure and remove from service a networked target by employing a distributed number of $evil_doers.  Example: a botnet is activated to swarm/overwhelm an Internet connected website using an asynchronous attack which makes the site unavailable due to an exhaustion of resources (compute, network or storage.)

EDoS attacks are death by 1000 cuts.  EDoS can also utilize distributed $evil_doers as well as single entities, but works by making legitimate web requests at volumes that may appear to be "normal" but are done so to drive compute, network and storage utility billings in a cloud model abnormally high.  Example: a botnet is ativated to visit a website whose income results from ecommerce purchases.  The requests are all legitimate but the purchases never made.  The vendor has to pay the cloud provider for increased elastic use of resources where revenue was never recognized to offset them.

We have anti-DDoS capabilities today with tools that are quite mature.  DDoS is generally easy to spot given huge increases in traffic.  EDoS attacks are not necessarily easy to detect, because the instrumentation and busines logic is not present in most applications or stacks of applications and infrastructure to provide the correlation between "requests" and " successful transactions."  In the example above, increased requests may look like normal activity.

Given the attractiveness of startups and SME/SMB's to the cloud for cost and agility, this presents a problem  The SME/SMB customers do not generally invest in this sort of integration, the cloud computing platform providers generally do not have the intelligence and visibility into these applications which they do not own, and typical DDoS tools don't, either.

So DDoS and EDoS ultimately can end with the same outcome: the target whithers and ceases to be able to offer service, but I think that EDoS is something significant that should be discussed and investigated.

/Hoff