Rational Survivability

I don’t know if you’ve noticed, but lately the ability to carry a tune while singing is optional.

Thanks to Cher and T-Pain, the rampant use of the Autotune in the music industry has enabled pretty much anyone to record a song and make it sound like they can sing (from the Autotune of encyclopedias, Wikipedia):

Auto-Tune uses a phase vocoder to correct pitch in vocal and instrumental performances. It is used to disguise off-key inaccuracies and mistakes, and has allowed singers to perform perfectly tuned vocal tracks without the need of singing in tune. While its main purpose is to slightly bend sung pitches to the nearest true semitone (to the exact pitch of the nearest tone in traditional equal temperament), Auto-Tune can be used as an effect to distort the human voice when pitch is raised/lowered significantly.^[3]

A similar “innovation” has happened to the security industry.  Instead of having to actually craft and execute a well-tuned security program which focuses on managing risk in harmony with the business, we’ve simply learned to hum a little, add a couple of splashy effects and let the compliance Autotune do it’s thing.

It doesn’t matter that we’re off-key.  It doesn’t matter that we’re not in tune.  It doesn’t matter that we hide mistakes.

All that matters is that auditors can sing along, repeating the chorus and ensure that we hit the Top 40.

/Hoff

Related articles

• Auto-Tune Really Is The Devil’s Favorite Tool (dlisted.com)
• Auto-Tune: Why Pop Music Sounds Perfect (time.com)
• Simon Cowell’s X Factor Fesses to Auto-Tune Use (omg.yahoo.com)
• What T-Pain Sounds Like Without Auto-Tune: Not That Much Better Than Sasha Frere-Jones [Sasha Frere-jones] (gawker.com)
• Navigating PCI DSS (2.0) – Related to Virtualization/Cloud, May the Schwartz Be With You! (rationalsurvivability.com)
• What’s The Problem With Cloud Security? There’s Too Much Of It… (rationalsurvivability.com)

I’m grumpy, confused and scared.  Classic signs of shock.  I can only describe what I’m feeling by virtue of an analog…

There’s a scene in the movie Jaws where Chief Brody, chumming with fish guts to attract and kill the giant shark from the back of the boat called “The Orca,” meets said fish for the first time.  Terrified by it’s menacing size, he informs [Captain] Quint “You’re gonna need a bigger boat.”

I felt like that today as I read through the recently released draft of the long-anticipated FedRAMP documents.  I saw the menace briefly surface, grin at me, and silently slip back into the deep.  Sadly, channeling Brody, I whispered to myself “…we’re gonna need something much sturdier to land this fish we call cloud.”

I’m not going to make any friends with this blog.

I can barely get my arms around all of the issues I have.  There will be sequels, just like with Jaws, though unlike Roy Schneider, I will continue to be as handsome as ever.

Here’s what I do know…it’s 81 pages long and despite my unhappiness with the content and organization, per Vivek Kundra’s introduction, I can say that it will certainly “encourage robust debate on the best path forward.”  Be careful what you ask for, you might just get it…

What I expected isn’t what was delivered in this document. Perhaps in the back of my mind it’s exactly what I expected, it’s just not what I wanted.

This is clearly a workstream product crafted by committee and watered down in the process.  Unlike the shark in Jaws, it’s missing it’s teeth, but it’s just as frightening because its heft is scary enough.  Even though all I can see is the dorsal fin cresting the water’s surface,  it’s enough to make me run for the shore.

As I read though the draft, I was struck by a wave of overwhelming disappointment.  This reads like nothing more than a document which scrapes together other existing legacy risk assessment, vulnerability management, monitoring and reporting frameworks and loosely defines interactions between various parties to arrive at a certification which I find hard to believe isn’t simply a way for audit companies to make more money and service providers to get rubber-stamped service ATO’s without much in the way of improved security or compliance.

This isn’t bettering security, compliance, governance or being innovative.  It’s not solving problems at a mass scale through automation or using new and better-suited mousetraps to do it.  It’s gluing stuff we already have together in an attempt to make people feel better about a hugely disruptive technical, cultural, economic and organizational shift.  This isn’t Gov2.0 at all.  It’s Gov1.0 with a patch.  It’s certainly not Cloud.

Besides the Center for Internet Security reference, there’s no mention of frameworks, tools, or organizations outside of government at all…that explains the myopic focus of “what we have” versus “what we need.”

The document is organized into three chapters:

Chapter 1: Cloud Computing Security Requirement Baseline
This chapter presents a list of baseline security controls for Low and Moderate
impact Cloud systems. NIST Special Publication 800-53R3 provided the foundation
for the development of these security controls.

Chapter 2: Continuous Monitoring
This chapter describes the process under which authorized cloud computing systems
will be monitored. This section defines continuous monitoring deliverables,
reporting frequency and responsibility for cloud service provider compliance with
FISMA.

Chapter 3: Potential Assessment & Authorization Approach
This chapter describes the proposed operational approach for A&A’s for cloud
computing systems. This reflects upon all aspects of an authorization (including
sponsorship, leveraging, maintenance and continuous monitoring), a joint
authorization process, and roles and responsibilities for Federal agencies and Cloud
Service Providers in accordance with the Risk Management Framework detailed in
NIST Special Publication 800-37R1.

It’s clear that the document was written almost exclusively from the perspective of farming out services to Public cloud providers capable of meeting FIPS 199 Low/Moderate requirements.  It appears to be written in the beginning from the perspective of SaaS services and the scoping and definition of cloud isn’t framed — so it’s really difficult to understand what sort of ‘cloud’ services are in scope.  NIST’s own cloud models aren’t presented.  Beyond Public SaaS services, it’s hard to understand whether Private, Hybrid, and Community clouds — PaaS or IaaS — were considered.

It’s like reading an article in Wired about the Administration’s love affair with Google while the realities of security and compliance are cloudwashed over.

I found the additional requirements and guidance related to the NIST 800-53-aligned control objectives to be hit or miss and some of them utterly laughable (such as SC-7 – Boundary Protection: “Requirement: The service provider and service consumer ensure that federal information (other than unrestricted information) being transmitted from federal government entities to external entities using information systems providing cloud services is inspected by TIC processes.”  Good luck with that.  Sections on backup are equally funny.

The “Continuous Monitoring” section requirements wherein the deliverable frequency and responsibile party is laid out engenders a response from “The Princess Bride:”

You keep using that word (continuous)…I do not think it means what you think it means…

Only 2 of the 14 categories are those which FedRAMP is required to provide (pentesting and IV&V of controls.)  All others are the responsibility of the provider.

Sigh.

There’s also not a clear distinction that in a service deployed on IaaS (as an example) where anything in the workload’s VM fits into this scheme (you know…all the really important stuff like information and applications) and how agency processes intersect with the CSP, FedRAMP and the  JAB.

The very dynamism and agility of cloud are swept under the rug, especially in sections discussing change control.  It’s almost laughable…code changes in some “cloud” SaaS vendors every few hours.  The rigid and obtuse classification of the severity of changes is absolutely ludicrous.

I’m unclear if the folks responsible for some of this document have ever used cloud based services, frankly.

“Is there anything good in the document,” you might ask?  Yes, yes there is. Firstly, it exists and frames the topic for discussion.  We’ll go from there.

However, I’m at a loss as how to deliver useful and meaningful commentary back to this team using the methodology they’ve constructed…there’s just so much wrong here.

I’ll do my best to hook up with folks at the NIST Cloud Workshop tomorrow and try, however if I smell anything remotely like seafood, I’m outa there.

/Hoff

Related articles

• Feds Roll Out Cloud Security Guidelines (informationweek.com)
• Administration Proposes Security Requirements For Cloud Computing (techdailydose.nationaljournal.com)
• New Standards for Governmental Agencies on Cloud Computing Security (blogs.csoonline.com)
• Feds Discover 1,000 More Data Centers (datacenterknowledge.com)
• What’s The Problem With Cloud Security? There’s Too Much Of It… (rationalsurvivability.com)
• Hoff’s 5 Rules Of Cloud Security… (rationalsurvivability.com)

[Disclaimer: I’m not a QSA. I don’t even play one on the Internet. Those who are will generally react to posts like these with the stock “it depends” answer, to which I respond “you’re right, it does.  Not sure where that leaves us other than with a collective sigh, but…]

The Payment Card Industry (PCI) last week released version 2.0 of the Data Security Standard (DSS.) [Legal agreement required]  This is an update from v1.2.1 but strangely does not introduce any major new requirements but instead clarifies language.

Accompanying this latest revision is also a guidance document titled “Navigating PCI DSS: Understanding the Intent of the Requirements, v2.0” [PDF]

One of the more interesting additions in the guidance is the direct call-out of virtualization which, although late to the game given the importance of this technology and its operational impact, is a welcome edition to this reader.  I should mention I’ve sat in on three of the virtualization SIG calls which gives me an interesting perspective as I read through the document.  Let me just summarize by saying that “…you can’t please all the people, all of the time…” 😉

What I find profoundly interesting is that since virtualization is a such a prominent and enabling foundational technology in IaaS Cloud offerings, the guidance is still written as though the multi-tenant issues surrounding cloud computing (as an extension of virtualization) don’t exist and that shared infrastructure doesn’t complicate the picture.  Certainly there are “cloud” providers who don’t use infrastructure shared with other providers beyond themselves in order to deliver service to different customers (I think we call them SaaS providers,) but think about the context of people wanting to use AWS to deliver services that are in scope for PCI.

Here’s what the navigation document has to say specific to virtualization and ultimately how that maps to IaaS cloud offerings.  We’re going to cover just the introductory paragraph in this post with the guidance elements and the actual DSS in a follow-on.  However, since many people are going to use this navigation document as their first blush, let’s see where that gets us:

PCI DSS requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server or application that is included in, or connected to, the cardholder data environment. System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

I would have liked to see specific mention of virtual storage here and although it’s likely included by implication in the management system/sub-system mentions above and below, the direct mention of APIs. Thanks to heavy levels of automation, the operational movements related to DevOps and with APIs becoming the interface of the integration and management planes, these are unexplored lands for many.

I’m also inclined to wonder about virtualization approaches that is not server-centric such as physical networking devices, databases, etc.

If virtualization is implemented, all components within the virtual environment will need to be identified and considered in scope for the review, including the individual virtual hosts or devices, guest machines, applications, management interfaces, central management consoles, hypervisors, etc. All intra-host communications and data flows must be identified and documented, as well as those between the virtual component and other system components.

It can be quite interesting to imagine the scoping exercises (or de-scoping more specifically) associated with this requirement in a cloud environment.  Even if the virtualized platforms are operated solely on behalf of a single customer (read: no shared infrastructure — private cloud,)  this is still an onerous task, so I wonder how — if at all — this could be accomplished in a public IaaS offering given the lack of transparency we see in today’s cloud operators.  Much of what is being asked for relating to infrastructure and “data flows” between the “virtual component and other system components” represents the CSP’s secret sauce.

The implementation of a virtualized environment must meet the intent of all requirements, such that the virtualized systems can effectively be regarded as separate hardware. For example, there must be a clear segmentation of functions and segregation of networks with different security levels; segmentation should prevent the sharing of production and test/development environments; the virtual configuration must be secured such that vulnerabilities in one function cannot impact the security of other functions; and attached devices, such as USB/serial devices, should not be accessible by all virtual instances.

“…clear segmentation of functions and segregation of networks with different security levels” and “the virtual configuration must be secured such that vulnerabilities in one function cannot impact the security of other functions,” eh? I don’t see how anyone can expect to meet this requirement in any system underpinned with a virtualized infrastructure stack (hardware or software) whether it’s multi-tenant or not.  One vulnerability in the hypervisor makes this an impossibility.  Add in management, storage, networking. This basically comes down to trusting in the sanctity of the hypervisor.

Additionally, all virtual management interface protocols should be included in system documentation, and roles and permissions should be defined for managing virtual networks and virtual system components. Virtualization platforms must have the ability to enforce separation of duties and least privilege, to separate virtual network management from virtual server management.

Special care is also needed when implementing authentication controls to ensure that users authenticate to the proper virtual system components, and distinguish between the guest VMs (virtual machines) and the hypervisor.

The rest is pretty standard stuff, but if you read the guidance sections (next post) it gets even more fun.  This is why the subjectivity, expertise and experience of the QSA is so related to the quality of the audit when virtualization and cloud are involved.  For example, let’s take a sneak peek at section 2.2.1, as it is a bit juicy:

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing
on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

I  acknowledge that there are “cloud” providers who are PCI certified at the highest tier.  Many of them are SaaS providers.  Many simply use their own server stacks in co-located facilities but due to their size and services merely call themselves cloud providers — many aren’t even virtualized per the description above.   Further, there are also methods of limiting scope and newer technologies such as tokenization that can assist in solving some of the information-centric issues with what would otherwise be in-scope data, but they offset many of the cost-driven efficiencies marketed by mass-market, low-cost cloud providers today.

Love to hear from an IaaS public cloud provider who is PCI certified (to the VM boundary) with customers that are in turn certified with in-scope applications and cardholder data or even a SaaS provider who sits atop an IaaS provider…

Just read this first before responding, please.

/Hoff

Related articles

• “PCI DSS 2.0 standard released, but detailed virtualization guidance still unavailable” and related posts (itknowledgeexchange.techtarget.com)
• Dear Verizon Business: I Have Some Questions About Your PCI-Compliant Cloud… (rationalsurvivability.com)
• Scoping Fun with PCI DSS 2.0 (brandenwilliams.com)
• PCI DSS 2.0 Released, Updating Requirements for Credit Card Security (palisadesystems.com)
• What’s The Problem With Cloud Security? There’s Too Much Of It… (rationalsurvivability.com)

Blogging is very much a broadcast medium.  Sure, people comment every now and then, but I like talking to people; I like to understand what *they* think.

I have some folks I’d like to “interview” for my blog on the topic of cloud – specifically practitioners who have relevant cloud computing experience relevant to ops, compliance, risk, and security. I don’t want anecdotes or take ill-defined polls and I also don’t want to regurgitate my interpretation of what somewhat else said. I want to hear you say it and let others know directly what you said.

Not interested in vendor pitches, thanks.

The structure would be somewhat similar to my Take 5 interviews.  I’d preferably like folks in the architect or CISO/CSO role who have broad exposure to initiatives in their large enterprise or service provider companies.

We can keep it anonymous.

Email me [choff @ packetfilter.com] if you’re interested.

Thanks,

/Hoff

Here’s the biggest challenge I see in Cloud deployment as the topic of security inevitably occurs in conversation:

There’s too much of it.

Huh?

More specifically, much like my points regarding networking in highly-virtualized multi-tenant environments — it’s everywhere — we’ve got the same problem with security.  Security is shot-gunned across the cloud landscape in a haphazard fashion…and the buck (pun intended) most definitely does not stop here.

The reality is that if you’re using IaaS, the lines of demarcation for the responsibility surrounding security may in one take seemed blurred but are in fact extremely well-delineated, and that’s the problem.  I’ve seen quite a few validated design documents outlining how to deploy “secure multi-tentant virtualized environments.”  One of them is 800 pages long.

Check out the diagram below.

I quickly mocked up an IaaS stack wherein you have the Cloud provider supplying, operating, managing and securing the underlying cloud hardware and software layers whilst the applications and information (contained within VM boundaries) are maintained by the consumer of these services.  The list of controls isn’t complete, but it gives you a rough idea of what gets focused on. Do you see some interesting overlaps?  How about gaps?

This is the issue; each one of those layers has security controls in it.  There is lots of duplication and there is lots of opportunity for things to be obscured or simply not accounted for at each layer.

Each of these layers and functional solutions is generally managed by different groups of people.  Each of them is generally managed by different methods and mechanisms.  In the case of IaaS, none of the controls at the hardware and software layers generally intercommunicate and given the abstraction provided as part of the service offering, all those security functions are made invisible to the things running in the VMs.

A practical issue is that the FW, VPN, IPS and LB functions at the hardware layer are completely separate from the FW, VPN, IPS and LB functions at the software layer which are in turn completely separate from the FW, VPN, IPS and LB functions which might be built into the VM’s (or virtual appliances) which sit stop them.

The security in the hardware is isolated from the security in the software which is isolated from the security in the workload.  You can, today, quite literally install the same capabilities up and down the stack without ever meeting in the middle.

That’s not only wasteful in terms of resources but incredibly prone to error in both construction, management and implementation (since at the core it’s all software, and software has defects.)

Keep in mind that at the provider level the majority of these security controls are focused on protecting the infrastructure, NOT the stuff atop it.  By design, these systems are blind to the workloads running atop them (which are often encrypted both at rest and in transit.)  In many cases this is why a provider may not be able to detect an “attack” beyond data such as flows/traffic.

To make things more interesting, in some cases the layer responsible for all that abstraction is now the most significant layer involved in securing the system as a whole and the fundamental security elements associated with the trust model we rely upon.

The hypervisor is an enormous liability; there’s no defense in depth when your primary security controls are provided by the (*ahem*) operating system provider.  How does one provide a compensating control when visibility/transparency [detective] are limited by design and there’s no easy way to provide preventative controls aside from the hooks the thing you’re trying to secure grants access to?

“Trust me” ain’t an appropriate answer.  We need better visibility and capabilities to robustly address this issue.  Unfortunately, there’s no standard for security ecosystem interoperability from a management, provisioning, orchestration or monitoring perspective even within a single stack layer.  There certainly isn’t across them.

In the case of Cloud providers who use commodity hardware with big, flat networks with little or no context for anything other than the flows/IP mappings running over them (thus the hardware layer is portrayed as truly commoditized,) how much better/worse do you think the overall security posture is of a consumer’s workload running atop this stack.  No, that’s not a rhetorical question.  I think the case could be argued either side of the line in the sand given the points I’ve made above.

This is the big suck.  Cloud security suffers from the exact same siloed security telemetry problems as legacy operational models…except now it does it at scale. This is why I’ve always made the case that one can’t “secure the Cloud” — at least not holistically — given this lego brick problem.   Everyone wants to make the claim that they’re technology is that which will be the first to solve this problem.  It ain’t going to happen. Not with the IaaS (or even PaaS) model, it won’t.

However, there is a big opportunity to move forward here.  How?  I’ll give you a hint.  It exists toward the left side of the diagram.

/Hoff

Related articles

• Hoff’s 5 Rules Of Cloud Security… (rationalsurvivability.com)
• Hack The Stack Or Go On a Bender With a Vendor? (rationalsurvivability.com)
• The Missing Piece of Cloud Security? (pcworld.com)
• Cloud Adoption Still Struggles With Security Issues in CSO Survey (securecloudreview.com)
• VMware’s (New) vShield: The (Almost) Bottom Line (rationalsurvivability.com)
• If You Could Have One Resource For Cloud Security… (rationalsurvivability.com)

There are many projects in my time that I’ve been passionate about, honored to have curated and personally gratified by others’ responses to, but none more than HacKid.

What is HacKid?

HacKid is a new kind of non-profit conference focused on  providing an interactive, hands-on experience for the entire family — kids aged 5-17 & their parents —  in order to raise awareness, excitement and understanding of technology, gaming, mathematics, safety, privacy, networking, security and engineering and their impact on society and culture.

The first HacKid conference is in Cambridge, MA on the weekend of October 9th and 10th, 2010.

The activities and sessions at HacKid are many and varied in topic.  Some of the things the kids and parents will do are:

• Learn About Online & Social Networking Safety
• Make a 
Podcast
• Learn How to Deal With 
Cyber-Bullies
• Learn Kodu & 
Scratch Programming Languages
• Build An 
Interactive Robot 3D printer
• Discover Hair Hacking
• Learn How the Internet works
• Get Creative With Food Hacking
• Manipulate Hardware & Software For Fun
• Dive Into Electronics
• Learn magic
• Build a trebuchet
• Meet & interact With Law Enforcement
• Learn About Low-impact Martial Arts/Self-Defense

There’s a ton of stuff to learn and get excited about.

The gist of the idea for HacKid (sounds like “hacked,” get it?) came about when I took my three daughters aged 6, 9 and 14 along with me to the Source Security conference in Boston.  It was fantastic to have them engage with my friends, colleagues and audience members as well as ask all sorts of interesting questions regarding the conference, however while they were interested in some things, it wasn’t engaging for them because it wasn’t relevant, it wasn’t interactive, it wasn’t hands-on…it wasn’t targeted to them.

…and it wasn’t meant to be.

I went home that night, registered the domain name, tweeted about it and was overwhelmed with people who said they wanted to help make this a reality.  The next day I reached out to the folks at Microsoft’s New England Research and Development (NERD) center in Cambridge and they kindly volunteered their amazing facilities.  From that moment on (a few months) it’s been on like Donkey Kong.

We have some amazingly kind and generous sponsors: USENIX, Microsoft, Kaspersky, Barracuda, IOActive, Cisco, Elenco, Trustwave, ISC2, You-Do-It Electronics, O’Reilly, and the Cloud Security Alliance.  Also, I’ve been blessed with some amazing volunteer help in the form of my Board of Advisors: Andy Ellis, Zach Lanier, Jack Daniel, Joe Garcia, Tim Mugherini, Tim Krabec, Jennifer Hoff, Tiffany Rad, Ryan Naraine, and David Blank-Edelman.

I’m really excited about how this is turning out and we’re going to replicate it across the country/world after we wrap the first one in Boston.  The wiki details some of the other candidate venues.

I do hope you’ll join us.  Space is running out and we’re closing registration on 10/6, so get typing if you and your kids want to come: www.regonline.com/hackid

/Hoff

Related articles by Zemanta

• What skills should a geek kid learn? (mckeay.net)
• I’m going to be where? (uncommonsensesecurity.com)
• On Amrit Williams’ (BigFix) Beyond The Perimeter Podcast (rationalsurvivability.com)
• SecuraBit Episode 65: Application Security From the Ground Up! (securabit.com)
• Grecs’ Weekly Infosec Ramblings for 2010-07-22 (novainfosecportal.com)

I have the privilege of being invited around the world to talk with (and more importantly) listen to some of the biggest governments, enterprises and service providers about their “journey to cloud computing.”

I feel a bit like Kwai Chang Caine from the old series Kung-Fu at times; I wander about blind but full of self-assured answers to the questions I seek to ask, only to realize that asking them is more important than knowing the answer — and that’s the point.  Most people know the answers, they just don’t know how — or which — questions to ask.

Yes, it’s a Friday.  I always get a little philosophical on Fridays.

In the midst of all this buzz and churn, there’s a lot of talk but depending upon the timezone and what dialect of IT is spoken, not necessarily a lot of compelling action.  Frankly, there’s a lot of analysis paralysis as companies turn inward to ask questions of themselves about what cloud computing does or does not mean to them. (Ed: This comment seemed to suggest to some that cloud adoption was stalled. Not what I meant. I’ll clarify by suggesting that there is brisk uptake in many areas, but it’s diversified, split between many parallel paths I reference below; public and private deployments. It doesn’t mean it’s harmonious, however.)

There is, however, a recurring theme across geography, market segment, culture and technology adoption appetites; everyone is seriously weighing their options regarding where, how and with whom to make their investments in terms of building cloud computing infrastructure (and often platform) as-a-service strategy.  The two options, often discussed in parallel but ultimately bifurcated based upon explored use cases come down simply to this:

1. Take any number of available open core or open source software-driven cloud stacks, commodity hardware and essentially engineer your own Amazon, or
2. Use proprietary or closed source virtualization-nee-cloud software stacks, high-end “enterprise” or “carrier-class” converged compute/network/storage fabrics and ride the roadmap of the vendors

One option means you expect to commit to an intense amount of engineering and development from a software perspective, the other means you expect to focus on integration of other companies’ solutions.  Depending upon geography, it’s very, very unclear to enterprises of service providers what is the most cost-effective and risk-balanced route when use-cases, viability of solution providers and the ultimate consumers of these use-cases are conflated.

There is no one-size-fits-all solution.  There is no ‘THE Cloud.”

This realization is why most companies are spinning around, investigating the myriad of options they have available and the market is trying to sort itself out, polarized at one end of the spectrum or trying to squeeze out a happy balance somewhere in the middle.

The default position for many is to go with what they know and “bolt on” new technology both tactically (in absence of an actual long-term strategy) to revamp what they already have.

This is where the battle between “public” versus “private” cloud rages — where depending upon which side of the line you stand, the former heralds the “new” realized model of utility computing and the latter is seen as building upon virtualization and process automation to get more agile.  Both are realistically approaching a meet-in-the-middle strategy as frustration mounts, but it’s hard to really get anyone to agree on what that is.  That’s why we have descriptions like “hybrid” or “virtual private” clouds.

The underlying focus for this discussion is, as one might imagine, economics.  What architects (note I didn’t say developers*) quickly arrive at is that this is very much a “squeezing the balloon problem.” Both of these choices hold promise and generally cause copious amounts of iteration and passionate debate centered on topics like feature agility, compliance, liability, robustness, service levels, security, lock-in, utility and fungibility  of the solutions.  But it always comes back to cost.

Hard costs are attractive targets that are easily understood and highly visible.  Soft costs are what kill you.  The models by which the activity and operational flow-through — and ultimate P&L accountability of IT — are still black magic.

The challenge is how those costs are ultimately modeled and accounted for and how to appropriately manage risk. Nobody wants the IT equivalent of credit-default swaps where investments are predicated on a house of cards and hand-waving and at the same time, nobody wants to be the guy whose obituary reads “didn’t get fired for buying IBM.”

Interestingly, the oft-cited simplicity of the “CapEx vs. OpEx” discussion isn’t so simple in hundred year old companies whose culture is predicated upon the existence of processes and procedures whose ebb and flow quite literally exist on the back of TPM reports.  You’d think that the way many of these solutions are marketed — both #1 and #2 above — that we’ve reached some sort of capability/maturity model inflection point where either are out of diapers.

If this were the case, these debates wouldn’t happen and I wouldn’t be writing this blog.  There are many, many tradeoffs to be made here. It’s not a simple exercise, no matter who it is you ask — vendors excluded 😉

Ultimately these discussions — and where these large companies and service providers with existing investment in all sorts of solutions (including previous generations of things now called cloud) are deciding to invest in the short term — come down to the following approaches to dealing with “rolling your own” or “integrating pre-packaged solutions”:

1. Keep a watchful eye on the likes of mass-market commodity cloud providers such as Amazon and Google. Use (enterprise) and/or emulate the capabilities (enterprise and service providers) of these companies in opportunistic and low-risk engagements which distribute/mitigate risk by targeting non-critical applications and information in these services.  Move for short-term success while couching wholesale swings in strategy with “pragmatic” or guarded optimism.
   .
2. Distract from the back-end fracas by focusing on the consumption models driven by the consumerization of IT that LOB and end users often define as cloud.  In other words, give people iPhones, use SaaS services that enrich user experience, don’t invest in any internal infrastructure to deliver services and call it a success while trying to figure out what all this really means, long term.
   .
3. Stand up pilot projects which allow dabbling in both approaches to see where the organizational, operational, cultural and technological landmines are buried.  Experiment with various vendors’ areas of expertise and functionality based upon the feature/compliance/cost see-saw.
   .
4. Focus on core competencies and start building/deploying the first iterations of “infrastructure 2.0” with converged fabrics and vendor-allied pre-validated hardware/software, vote with dollars on cloud stack adoption, contribute to the emergence/adoption of “standards” based upon use and quite literally *hope* that common formats/packaging/protocols will arrive at portability and ultimately interoperability of these deployment models.
   .
5. Drive down costs and push back by threatening proprietary hardware/software vendors with the “fact” that open core/open source solutions are more cost-effective/efficient and viable today whilst trying not to flinch when they bring up item #2 questioning where and how you should be investing your money and what your capabilities really are is it relates to development and support.  React to that statement by threatening to move all your apps atop  someone elses’ infrastructure. Try not to flinch again when you’re reminded that compliance, security, SLA’s and legal requirements will prevent that.  Rinse, lather, repeat.
   .
6. Ride out the compliance, security, trust and chasm-crossing comfort gaps, hedging bets.

If you haven’t figured it out by now, it’s messy.

If I had to bet which will win, I’d put my money on…<carrier lost>

/Hoff

*Check out Bernard Golden’s really good post “The Truth About What Really Runs On Amazon” for some insight as to *who* and *what* is running in public clouds like AWS.  The developers are leading the charge.  Often times they are disconnected from the processes I discuss above, but that’s another problem entirely, innit?

Related articles by Zemanta

• Open Source And Cloud Computing: How Bitnami Helps Launch Open Source Apps On EC2 In 2 Minutes (cloudave.com)
• Impact of OpenStack Project Goes Beyond the Cloud Industry Leaders (readwriteweb.com)
• Why OpenStack Has its Work Cut Out (gigaom.com)
• Cloud Computing: A Treasure Trove for Hackers (deurainfosec.com)
• Cloud.com Collaborates with Industry Leaders in Open Source and Cloud Computing to Help Put an End to Cloud Lock-in (eon.businesswire.com)
• CLOUDINOMICON: Idempotent Infrastructure, Survivable Systems & Bringing Sexy Back to Information Centricity (rationalsurvivability.com)
• The Classical DMZ Design Pattern: How To Kill Security In the Cloud (rationalsurvivability.com)
• Incomplete Thought: Why We Need Open Source Security Solutions More Than Ever… (rationalsurvivability.com)
• Hoff’s 5 Rules Of Cloud Security… (rationalsurvivability.com)

I’ll be adding a material review of this document here later, but I wanted to make sure folks know this resource exists.

It’s titled the “VMware vCloud Director Security Hardening Guide”

You can download it here (PDF)

The Table of Contents appears reasonably robust…content is TBD

/Hoff

Related articles by Zemanta

• VMWare launches six new vCloud products (zdnet.com)
• How To Wield the New vShield (Edge, App & Endpoint) (rationalsurvivability.com)
• VMware’s (New) vShield: The (Almost) Bottom Line (rationalsurvivability.com)
• VMware’s Cloud Strategy: Neither Deadwood Nor Sandalwood But A Little More Than A Collection Of Driftwoods (cloudave.com)
• VMworld: VMware pushes IT-as-a-service (v3.co.uk)
• Hoff’s 5 Rules Of Cloud Security… (rationalsurvivability.com)
• The Classical DMZ Design Pattern: How To Kill Security In the Cloud (rationalsurvivability.com)
• If You Could Have One Resource For Cloud Security… (rationalsurvivability.com)

Try not to be
such an Oracle Hater,
Build a big, honkin’ Cloud:
Exalogic &  -data

It’s fluffy & shiny
it’s new & fantastic
It scales like butta,
cos it’s so damned elastic

It may cost you millions,
but it’ll save you a buck.
Is it really a cloud?
Larry don’t give a f*ck.

It’ll castigate partners
and alienate friends
it’s got unbreakable linux
and it also self-mends

The kernel is magic,
OVM’s where it’s at
Some might disagree,
especially RedHat

Infiniband, ten Gig,
many Sun-powered cores
It’s got enough cycles
for HPC chores

The issue some have,
is Larry’s evil plot
It’s really quite simple,
a mortgage and yacht.

It’s like “War of the Roses,”
‘tween Big O, Salesforce
Gets ugly in the  Valley
when partners divorce

Some CEO’s chide Larry,
and others, they scoff.
Some fire back with venom
like Mark Benioff

It’s a False Cloud, a Non-Cloud
“We’re like A-W-S”
this marketing plan
is one freakin’ mess

Just one file to patch it,
it’s IT on demand.
It’s a mainframe with JBoss,
can’t you understand!?

It’ll take all you can give it,
all you can muster,
It scales from one
to an eight headed cluster

At the end of the day,
from morning to nox
take comfort that Cloud
now comes in a box.

—

P.S. You may be interested in other little ditties I have scratched into existence, here.

Related articles by Zemanta

• Oracle spins own Linux for mega hardware (go.theregister.com)
• Is Oracle the Leader in Cloud Computing? (dailyfinance.com)
• Oracle Exalogic (pythian.com)
• Oracle Launches ‘Private Cloud’ Box (developers.slashdot.org)
• Exalogic: Larry Gets the Cloud Now & He Wants It All (cloud.gigaom.com)
• Proceed With Caution to Oracle’s Proprietary Linux Kernel (pcworld.com)
• Oracle Unbreakable Enterprise Kernel: A Clean Break With Redhat? (cloudave.com)
• Oracle Adopts the Worst Term for Cloud Computing to Describe an Impressive Machine (readwriteweb.com)

Recent Speaking Engagements/Confirmed to  speak at the following upcoming events:

• FIRST, Miami, FL, keynote  – June 13-18
• SANS What Works In Virtualization and Cloud, Washington, D.C., keynote – August 19th-20th
• Ping Identity Summit, Keystone, CO, Cloud session with Gunnar Peterson – July 20-23
• Black Hat 2010, Las Vegas, NV, July 26-29
• Defcon 18, Las Vegas, NV – July 30-August 1
• VMworld, San Francisco, CA – August 30-September 3
• RSA Japan, Tokyo, Japan – September 6-12
• Telfonica Cloud Security Event, Madrid, Spain – September 13-16
• NIST 2010 SCAP conference, Baltimore, Maryland – September 28
• IANS New England Information Security Forum, Boston, MA, keynote – September 29
• MassTLC Security Summit, Burlington, MA – October 1
• HacKid, Cambridge, MA – October 9-10
• RSA Europe, London, UK – October 11-15
• Security at University of Michigan Summit (SUMIT_10), Ann Arbor, MI – October 18-19
• Sector, Toronto, Canada – October 25-28
• Black Hat Abu Dhabi, UAE – November 10-11
• Cloud Security Alliance Congress, Orlando, FL – November 16-17

There are a ton of venues I haven’t added here because they are directly related to customer visits that may not wish to be disclosed.  You can see the prior list of speaking engagements listed here.

[I often get a bunch of guff as to why I make these lists: ego, horn-tooting, self-aggrandizement. I wish I thought I were that important.  The real reason is that it helps me keep track of useful stuff focused not only on my participation, but that of the rest of the blogosphere.  It also allows folks to plan meet-ups]

/Hoff