Rational Survivability

There are lots of reasons one might use to illustrate why operationalizing security — both from the human and technology perspectives — doesn’t scale.

I’ve painted numerous pictures highlighting the cyclical nature of technology transitions, the supply/demand curve related to threats, vulnerabilities, technology and compensating controls and even relevant anecdotes involving the intersection of Moore’s and Metcalfe’s laws.  This really was a central theme in my Cloudinomicon presentation; “idempotent infrastructure, building survivable systems and bringing sexy back to information centricity.”

Here are some other examples of things I’ve written about in this realm.

Batting around how public “commodity” cloud solutions forces us to re-evaluate how, where, why and who “does” security was an interesting journey.  Ultimately, it comes down to architecture and poking at the sanctity of models hinged on an operational premise that may or may not be as relevant as it used to be.

However, I think the most poignant and yet potentially obvious answer to the “why doesn’t security scale?” question is the fact that security products, by design, don’t scale because they have not been created to allow for automation across almost every aspect of their architecture.

Automation and the interfaces (read: APIs) by which security products ought to be provisioned, orchestrated, and deployed are simply lacking in most security products.

Yes, there exist security products that are distributed but they are still managed, provisioned and deployed manually — generally using a management hub-spoke model that doesn’t lend itself to automated “anything” that does not otherwise rely upon bubble-gum and bailing wire scripting…

Sure, we’ve had things like SNMP as a “standard interface” for “management” for a long while 😉  We’ve had common ways of describing threats and vulnerabilities.  Recently we’ve seen the emergence of XML-based APIs emerge as a function of the latest generation of (mostly virtualized) firewall technologies, but most products still rely upon stand-alone GUIs, CLIs, element managers and a meat cloud of operators to push the go button (or reconfigure.)

Really annoying.

Alongside the lack of standard API-based management planes, control planes are largely proprietary and the output for correlated event-driven telemetry at all layers of the stack is equally lacking.  Of course the applications and security layers that run atop infrastructure are still largely discrete thus making the problem more difficult.

The good news is that virtualization in the enterprise and the emergence of the cultural and operational models predicated upon automation are starting to influence product roadmaps in ways that will positively affect the problem space described above but we’ve got a long haul as we make this transition.

Security vendors are starting to realize that they must retool many of their technology roadmaps to deal with the impact of dynamism and automation.  Some, not all, are discovering painfully the fact that simply creating a virtualized version of a physical appliance doesn’t make it a virtual security solution (or cloud security solution) in the same way that moving an application directly to cloud doesn’t necessarily make it a “cloud application.”

In the same way that one must often re-write or specifically design applications “designed” for cloud, we have to do the same for security.  Arguably there are things that can and should be preserved; the examples of the basic underpinnings such as firewalls that at their core don’t need to change but their “packaging” does.

I’m privy to lots of the underlying mechanics of these activities — from open source to highly-proprietary — and I’m heartened by the fact that we’re beginning to make progress.  We shouldn’t have to make a distinction between crafting and deploying security policies in physical or virtual environments.  We shouldn’t be held hostage by the separation of application logic from the underlying platforms.

In the long term, I’m optimistic we won’t have to.

/Hoff

Related articles

• Don’t Conflate Virtual with Dynamic (devcentral.f5.com)
• Seeing Through The Clouds: Understanding the Options and Issues (thesecuritysamurai.com)
• The Fallacies of Distributed Computing Reborn: The Cloud Era (newrelic.com)
• Gazing into the Crystal Ball: GigaOm on APIs in 2011 (programmableweb.com)
• NSA To Assume Security Is Compromised (securosis.com)
• Seeing Through The Clouds: Understanding the Options and Issues (thesecuritysamurai.com)

• The Fallacies of Distributed Computing Reborn: The Cloud Era (newrelic.com)
• Gazing into the Crystal Ball: GigaOm on APIs in 2011 (programmableweb.com)
• NSA To Assume Security Is Compromised (securosis.com)

I was speaking to an enterprise account manager the other day regarding strategic engagements in Cloud Computing in very large enterprises.

He remarked on the non-surprising parallelism occurring as these companies build and execute on cloud strategies that involve both public and private cloud initiatives.

Many of them are still trying to leverage the value of virtualization and are thus often conservative about their path forward.  Many are blazing new trails.

We talked about the usual barriers to entry for even small PoC’s: compliance, security, lack of expertise, budget, etc., and then he shook his head solemnly, stared at the ground and mumbled something about a new threat to the overall progress toward enterprise cloud adoption.

MBO Cloud.

We’ve all heard of public, private, virtual private, hybrid, and community clouds, right? But “MBO Cloud?”

I asked. He clarified:

Cloud computing is such a hot topic, especially with its promise of huge cost savings, agility, and the reduced time-to-market for services and goods that many large companies who might otherwise be unable or unwilling to be able to pilot using a public cloud provider and also don’t want to risk much if any capital outlay for software and infrastructure to test private cloud are taking an interesting turn.

They’re trying to replicate Amazon or Google but not for the right reasons or workloads. They just look at “cloud” as some generic low-cost infrastructure platform that requires some open source and a couple of consultants — or even a full-time team of “developers” assigned to make it tick.

They rush out, buy 10 off-the-shelf white-label commodity multi-CPU/multi-core servers, acquire a plain vanilla NAS or low-end SAN storage appliance, sprinkle on some Xen or KVM, load on some unremarkable random set of open source software packages to test with a tidy web front-end and call it “cloud.”  No provisioning, no orchestration, no self-service portals, no chargeback, no security, no real scale, no operational re-alignment, no core applications…

It costs them next to nothing and it delivers about the same because they’re not designing for business cases that are at all relevant, they’re simply trying to copy Amazon and point to a shiny new rack as “cloud.”

Why do they do this? To gain experience and expertise? To dabble cautiously in an emerging set of technological and operational models?  To offload critical workloads that scale up and down?

Nope.  They do this for two reasons:

1. Now that they have proven they can “successfully” spin up a “cloud” — however useless it may be — that costs next to nothing, it gives them leverage to squeeze vendors on pricing when and if they are able to move beyond this pile of junk, and
   –
2. Management By Objectives (MBO) — or a fancy way of saying, “bonus.”  Many C-levels and their ops staff are compensated via bonus on hitting certain objectives. One of them (for all the reasons stated above) is “deliver on the strategy and execution for cloud computing.” This half-hearted effort sadly qualifies.

So here’s the problem…when these efforts flame out and don’t deliver, they will impact the success of cloud in general — everywhere from a private cloud vendor to even potentially public cloud offers like AWS.  Why?  Because as we already know, *anything* that smells at all like failure gets reflexively blamed on cloud these days, and as these craptastic “cloud” PoC’s fail to deliver — even on minimal cash outlay — it’s going to be hard to gain a second choice given the bad taste left in the mouths of the business and management.

The opposite point could also be made in regard to public cloud services — that these truly “false cloud*” trials based on poorly architected and executed bubble gum and bailing wire will drive companies to public cloud (however longer that may take as compliance and security catch up.)

It will be interesting to see which happens first.

Either way, beware the actual “false cloud” but realize that the motivation behind many of them isn’t the betterment of the business or evolution of IT, it’s the fattening of wallets.

/Hoff

* I’m leveraging “false cloud” here to truly illustrate a point; despite actually useful private cloud initiatives, this is a term unfortunately levied on all private cloud initiatives by certain public cloud providers.

Related articles

• CloudSwitch: Traitor To the [Public Cloud] Cause… (rationalsurvivability.com)
• Skype Downtime And The Cloud Fail (cloudave.com)
• Survey Says Large Enterprises Are Already Active In The Cloud (cloudave.com)
• Cloud Computing: A Beautiful Gift of 21st Century (globalthoughtz.com)
• I’ll Say It Again: Security Is NOT the Biggest Barrier To Cloud… (rationalsurvivability.com)
• Best Practices in Cloud Computing for 2010 (datacenterknowledge.com)

Ellen Rubin and John Considine from CloudSwitch chuckled when I muttered this toward them in some sort of channeled pantomime of what an evaluation of their offering might bring from public-only cloud apologists.

Afterall, simply taking an application and moving it to a cloud doesn’t make it a “cloud application.”  Further, to fully leverage the automation, scale, provisioning and orchestration of “true” cloud platforms, one must re-write one’s applications and deal with the associated repercussions of doing so.  Things like security, networking, compliance, operations, etc.  Right?

Well…

CloudSwitch’s solutions — which defy this fundamental rearchitecture requirement —  enable enterprises to securely encapsulate and transport enterprise datacenter-hosted VM-based applications as-is and run them atop public cloud provider environments such as Amazon Web Services and Terremark in a rather well designed, security-conscious manner.

The reality is that their customer base — large enterprises in many very demanding verticals — seek to divine strategic technologies that allow them to pick and choose what, how and when to decide to “cloudify” their environments.  In short, CloudSwitch TODAY offers these customers a way to leverage the goodness of public utility in cloud without the need to fundamentally rearchitect the applications and accompanying infrastructure stacks — assuming they are already virtualized.  CloudSwitch seeks to do a lot more as they mature the product.

I went deep on current product capabilities and then John and I spent a couple of hours going off the reservation discussing what the platform plans are — both roadmapped and otherwise.

It was fascinating.

The secure isolation and network connectivity models touch on overlay capabilities from third parties, hypervisor/cloud stack providers like VMware (vCloud Director) as well as offers from folks like Amazon and their VPC, but CloudSwitch provides a way to solve many of the frustrating and sometimes show-stopping elements of application migration to cloud.  The preservation of bridged/routed networking connectivity back to the enterprise LAN is well thought out.

This is really an audit and compliance-friendly solution…pair a certified cloud provider (like AWS, as an example) up with app stacks in VMs that the customer is responsible for getting certified (see the security/compliance=shared responsibility post) and you’ve got something sweeter’n YooHoo…

It really exemplifies the notion of what people think of when they envision Hybrid Cloud today.  “Native” cloud apps written specifically for cloud environments, “transported” cloud apps leveraging CloudSwitch, and on-premises enterprise datacenters all interconnected.  Sweet.  More than just networking…

For the sake of not treading on FrieNDA elements that weaved their way in and out of our conversation, I’m not at liberty to discuss many of the things that really make this a powerful platform both now and in future releases.  If you want more technical detail on how it works, call ’em up, visit their website or check out Krishnan’s post.

Let me just say that the product today is impressive — it has some features from a security, compliance, reporting and auditing perspective I think can be further improved, but if you are an enterprise looking for a way to today make graceful use of public cloud computing in a secure manner, I’d definitely take a look at CloudSwitch.

/Hoff

Related articles

• CloudSwitch Releases New Version With Enhances Enterprise Features (cloudave.com)
• “Lights Out” in the Cloud (devcentral.f5.com)
• CloudSwitch Lets Developers Provision Apps in the Cloud with Point-and-Click Simplicity (devx.com)
• The Shifting Market for the Extended or Hybrid Cloud (readwriteweb.com)

I’m not sure this makes any sense whatsoever, but that’s why it’s labeled “incomplete thought,” isn’t it? 😉

A few weeks ago I was delivering my Cloudinomicon talk at the Cloud Security Alliance Congress in Orlando and as I was describing the cyclical nature of computing paradigms and the Security Hamster Sine Wave of Pain, it dawned on me — out loud — that we have Apple’s iPhone and its U.S. carrier, AT&T, to thank for the success of Cloud Computing.

My friends from AT&T perked up when I said that.  Then I explained…

So let me set this up. It will require some blog article ping-pong in order to reference earlier scribbling on the topic, but here’s the very rough process:

1. I’ve pointed out that there are two fundamental perspectives when describing Cloud and Cloud Computing: the operational provider’s view and the experiential consumer’s view.  To the provider, the IT-centric, empirical and clinical nuances are what matters. To the consumer, anything that connects to the Internet via any computing platform using any app that interacts with any sort of information is also cloud.  There’s probably a business/market view, but I’ll keep things simple for purpose of illustration.  I wrote about this here:  Cloud/Cloud Computing Definitions – Why they Do(n’t) Matter…
   –
2. As we look at the adoption of cloud computing, the consumption model ultimately becomes more interesting than how the service is delivered (as it commoditizes.) My presentation “The Future of Cloud” focused on the fact that the mobile computing platforms (phones, iPads, netbooks, thin(ner) clients, etc) are really the next frontier.  I pointed out that we have the simultaneous mass re-centralization of applications and data in massive cloud data centers (however distributed ethereally they may be) and the massive distribution of the same applications and data across increasingly more intelligent, capable and storage-enabled mobile computing devices.  I wrote about this here: Slides from My Cloud Security Alliance Keynote: The Cloud Magic 8 Ball (Future Of Cloud)
   –
3. The iPhone isn’t really that remarkable a piece of technology in and of itself, in fact it capitalizes on and cannibalizes many innovations and technologies that came before it.  However, as I mentioned in my post “Cloud Maturity: Just Like the iPhone, There’s An App For That… “The thing I love about my iPhone is that it’s not a piece of technology I think about but rather, it’s the way I interact with it to get what I want done.  It has its quirks, but it works…for millions of people.  Add in iTunes, the community of music/video/application artists/developers and the ecosystem that surrounds it, and voila…Cloud.”
   –
   
4. At each and every compute paradigm shift, we’ve seen the value of the network waffle between “intelligent” platform and simple transport depending upon where we were with the intersection of speeds/feeds and ubiquity/availability of access (the collision of Moore’s and Metcalfe’s laws?)  In many cases, we’ve had to rely on workarounds that have hindered the adoption of really valuable and worthwhile technologies and operational models because the “network” didn’t deliver.

I think we’re bumping up against point #4 today.  So here’s where I find this interesting.  If we see the move to the consumerized view of accessing resources from mobile platforms to resources located both on-phone and in-cloud, you’ll notice that even in densely-populated high-technology urban settings, we have poor coverage, slow transit and congested, high-latency, low-speed access — wired and wireless for that matter.

This is a problem. In fact it’s such a problem that if we look backward to about 4 years ago when “cloud computing” and the iPhone became entries in the lexicon of popular culture, this issue completely changed the entire application deployment model and use case of the iPhone as a mobile platform.  Huh?

Do you remember when the iPhone first came out? It was a reasonably capable compute platform with a decent amount of storage. It’s network connectivity, however, sucked.

Pair that with the fact that the application strategy was that there was emphatically, per Steve Jobs, not going to be native applications on the iPhone for many reasons, including security.  Every application was basically just a hyperlink to a web application located elsewhere.  The phone was nothing more than a web browser that delivered applications running elsewhere (for the most part, especially when things like Flash were’nt present.) Today we’d call that “The Cloud.”

Interestingly, at this point, he value of the iPhone as an application platform was diminished since it was not highly differentiated from any other smartphone that had a web browser.

Time went by and connectivity was still so awful and unreliable that Apple reversed direction to drive value and revenue in the platform, engaged a developer community, created the App Store and provided for a hybrid model — apps both on-platform and off — in order to deal with this lack of ubiquitous connectivity.  Operating systems, protocols and applications were invented/deployed in order to deal with the synchronization of on- and off-line application and information usage because we don’t have pervasive high-speed connectivity in the form of cellular or wifi such that we otherwise wouldn’t care.

So this gets back to what I meant when I said we have AT&T to thank for Cloud.  If you can imagine that we *did* have amazingly reliable and ubiquitous connectivity from devices like our iPhones — those consumerized access points to our apps and data — perhaps the demand for and/or use patterns of cloud computing would be wildly different from where they are today. Perhaps they wouldn’t, but if you think back to each of those huge compute paradigm shifts — mainframe, mini, micro, P.C., Web 1.0, Web 2.0 — the “network” in terms of reliability, ubiquity and speed has always played a central role in adoption of technology and operational models.

Same as it ever was.

So, thanks AT&T — you may have inadvertently accelerated the back-end of cloud in order to otherwise compensate, leverage and improve the front-end of cloud (and vice versa.)  Now, can you do something about the fact that I have no signal at my house, please?

/Hoff

* Update:  A few hours after writing this last night, AWS announced they had achieved Level 1 PCI DSS Compliance.* If you pay attention to how the announcement is worded, you’ll find a reasonable treatment of what PCI compliance means to an IaaS cloud provider – it’s actually the first time I’ve seen this honestly described:

Merchants and other service providers can now run their applications on AWS PCI-compliant technology infrastructure to store, process and transmit credit card information in the cloud. Customers can use AWS cloud infrastructure, which has been validated at the highest level (Level 1) of PCI compliance, to build their cardholder environment and achieve PCI certification for their applications.

Note how they phrased this, then read my original post below.

However, pay no attention to the fact that they chose to make this announcement on Pearl Harbor Day 😉

—

Here’s the thing…

A cloud provider can achieve compliance (such as PCI — yes v2.0 even) such that the in-scope elements of that provider which are audited and assessed can ultimately contribute to the compliance of a customer operating atop that environment.  We’ve seen a number of providers assert compliance across many fronts, but they marketed their way into a yellow card by over-reaching…

It should be clear already, but for a service to be considered compliant, it clearly means that the customer’s in-scope elements running atop a cloud provider must also undergo and achieve compliance.

That means compliance is elementally additive the same way “security” is when someone else has direct operational control over elements in the stack you don’t.

In the case of an IaaS cloud provider who may achieve compliance from the “concrete to the hypervisor,” (let’s use PCI again,) the customer in turn must have the contents of the virtual machine (OS, Applications, operations, controls, etc.) independently assessed and meet PCI compliance in order that the entire stack of in-scope elements can be described as compliant.

Thus security — and more specifically compliance — in IaaS (and PaaS) is a shared responsibility.

I’ve spent many a blog battling marketing dragons from cloud providers that assert or imply that by only using said provider’s network which has undergone and passed one or more audits against a compliance framework, that any of its customers magically inherit certification by default. I trust this is recognized as completely false.

As compliance frameworks catch up to the unique use-cases that multi-tenancy and technologies such as virtualization bring, we’ll see more “compliant cloud” offerings spring up, easing customer pain related to the underlying moving parts.  This is, for example, what FedRAMP is aiming to provide with “pre-approved” cloud offerings.  We’ve got visibility and transparency issues to solve , as well as temporal issues such as the frequency and period of compliance audits, but there’s progress.

We’re going to see more and more of this as infrastructure- and platform-as-a-service vendors look to mutually accelerate compliance to achieve that which software-as-a-service can more organically deliver as a function of stack control.

/Hoff

* Note: It’s still a little unclear to me how some of the PCI requirements are met in an environment like an IaaS Cloud provider where “applications” that we typically think of that traffic in PCI in-scope data don’t exist (but the infrastructure does,) but I would assume that AWS leverages other certifications such as SAS and ISO as a cumulative to petition the QSA for consideration during certification.  I’ll ask this question of AWS and see what I get back.

Related articles

• Navigating PCI DSS (2.0) – Related to Virtualization/Cloud, May the Schwartz Be With You! (rationalsurvivability.com)
• Seeing Through The Clouds: Understanding the Options and Issues (thesecuritysamurai.com)
• I’ll Say It Again: Security Is NOT the Biggest Barrier To Cloud… (rationalsurvivability.com)
• PCI 2.0 Allows For Compliant Clouds, Make Sure Your Service Providers Are PCI Compliant (securecloudreview.com)
• What’s The Problem With Cloud Security? There’s Too Much Of It… (rationalsurvivability.com)
• FedRAMP. My First Impression? We’re Gonna Need A Bigger Boat… (rationalsurvivability.com)
• Mixed Mode and PCI DSS 2.0 (brandenwilliams.com)
• The Future Of Audit & Compliance Is…Facebook? (rationalsurvivability.com)
• Incomplete Thought: Compliance – The Autotune Of The Security Industry (rationalsurvivability.com)

EMC today launched two new private cloud architect certifications.  I find it intriguing that the certification is described as “Leverag[ing] ‘open’ curriculum training and certification focused on technology concepts and principles applicable to any vendor environment.”  I’ll be interested to see how applicable to Citrix and Hyper-V environments the courseware is… 😉

From their community blog:

Related articles

• Creating A New Generation Of Cloud Professionals (chucksblog.emc.com)

Nope.

Security is not the biggest barrier to companies moving to applications, information and services delivered using cloud computing.

What is?

Compliance.

See Cloud: Security Doesn’t Matter (Or, In Cloud, Nobody Can Hear You Scream) and You Can’t Secure The Cloud…

That means what one gives up in terms of direct operational control, one must gain back in terms of visibility and transparency (sort of like www.cloudaudit.org)

Discuss.

/Hoff

Related articles

• The Future Of Audit & Compliance Is…Facebook? (rationalsurvivability.com)
• Hack The Stack Or Go On a Bender With a Vendor? (rationalsurvivability.com)
• What’s The Problem With Cloud Security? There’s Too Much Of It… (rationalsurvivability.com)
• Navigating PCI DSS (2.0) – Related to Virtualization/Cloud, May the Schwartz Be With You! (rationalsurvivability.com)
• Incomplete Thought: Compliance – The Autotune Of The Security Industry (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