by Bernard Golden

Data Compliance and Cloud Computing Collide: Key Questions

Sep 10, 2010
Cloud Computing

On the crucial issue of data compliance, do you understand what you are responsible for versus your cloud service provider? One thing you don't want is a costly and labor-intensive manual audit mechanism, says's Bernard Golden.

Forrester has been putting out really interesting reports on cloud computing lately. I discussed one of them in a recent post entitled “Cloud Computing: Whose Crystal Ball is Correct,” which addressed the topic of private clouds. In that post, I examined Forrester’s James Staten’s point that implementing private cloud computing requires far more than buying vSphere and a few add-on modules—it requires standardization, process re-engineering, and organizational alignment.

This week brought another excellent report from Forrester, “Compliance with Cloud: Caveat Emptor,” written by Dr. Chenxi Wang, exploring the challenges raised by the collision between data compliance requirements and cloud computing real-world offerings.

As Dr. Wang notes, most data compliance laws and regulation are written with an assumption that the liable party controls the infrastructure data is stored on as well as the placement decision about where that storage is located. Practically none of the laws and regulations recognize that a service provider may hold the data on behalf of the liable organization. Therefore, most compliance situations assign all of the responsibility to the user of a cloud computing environment despite the manifest fact that much of the control of the data is out of the hands of the user.

Several things about Dr. Wang’s analysis stood out to me:

1. It may be easier to learn where an IaaS provider’s data centers (and therefore, data storage location) are than for an SaaS provider. Google is identified in the report as not being able to state, definitively, where one’s data is hosted or that its location will be restricted to any given region. Obviously, any opaqueness about location causes a real problem for users to ascertain if they are in compliance with applicable laws and regulations.

2. Only one law is identified as specifically recognizing the role of a service provider—HITECH for HIPAA. All other laws and regulations leave all of the responsibility with the user. At HyperStratus, we refer to this situation as asymmetric risk —despite the fact that compliance is a shared responsibility, most or all of the risk falls upon the user.

3. Those who trumpet that cloud providers accept responsibility for legal compliance measures overlook an obvious difficulty—cloud providers often don’t know what data is being stored in their infrastructure and can’t know what legal conditions apply to the data.

For a company like Amazon, the fact that someone can begin executing a cloud-based application with nothing more than a credit card and an account id means that it has no way to validate (or indeed, even understand) an application’s compliance requirement. This is worth repeating—absent a discussion, there is no way for a cloud provider to have any idea what measures should be taken for compliance reasons—so insisting the cloud provider step up and meet compliance requirements may be unrealistic.

4. Cloud-based PCI doesn’t really exist. Dr. Wang states that achieving PCI compliance appears to be economically unattractive for cloud providers, so most cloud providers don’t bother. The standard recommendation we make is to place the application in a cloud environment and to make PCI-oriented calls out to another service provider that specializes in PCI compliance.

In terms of recommendations, Dr. Wang proposes two types of compliance measures:

1. Assess: One approach is to assess a cloud provider’s compliance situation by discussing (and perhaps auditing) their compliance measures. I don’t necessarily think this is bad advice, but it may not be practical for all users, since a cloud provider could easily be overwhelmed by customers wanting to sit down and discussing implemented measures. In any case, the interaction-heavy model is a poor fit for many cloud providers who want to provide low-cost, low-touch service. There is an effort afoot to develop a standardized cloud audit description that could be accessed remotely in an automated way. This is a far better match for the direction computing is heading in, and holds the potential that a standardized description could be accessed as part of a provisioning workflow and direct the resource placement decision from a rule-based engine.

2. Compensate: Another approach is to implement compensating controls to mitigate shortcomings on the part of the cloud provider. Five controls are identified: (1) scrubbing or anonymizing data; (2) encrypting data; (3) seeking cloud providers with strong security certifications; (4) paying more to encourage the cloud provider to offer the necessary compliance measures; and (5) using a hosted private cloud. The first three recommendations are excellent suggestions and we would prescribe they be considered whether or not the cloud provider has other compliance measures in place. These steps provide protection even if the cloud provider’s measures fail or fall short, and represent a best practice no matter what cloud provider is involved. The fourth and fifth make sense, but may not be achievable in a world where cloud providers make their margin by focusing on standardized, automated offerings. They’re worth pursuing, but don’t be surprised if they prove unworkable in a given situation.

Looking to the future, Dr. Wang predicts that cloud providers will differentiate and compete based on compliance support and effectiveness because (1) they can spread out the cost; (2) they automate processes and can therefore operate very efficiently in terms of compliance controls; and (3) they must since regulatory and legal requirements are important and going to get more important in the future.

I agree with Dr. Wang, with the following proviso: compliance will be important, but the real service provider winners will be those that figure out how to marry automated internal controls with an automated discovery process a la the automated audit mechanism I previously mentioned.

The current compliance assessment model of manual interactions, audits, extensive checklists, etc., makes sense in the old, non-cloud world. For the cloud world of tomorrow, speed and agility is crucial, and putting a lengthy and labor-intensive—not to mention expensive—manual audit mechanism in the middle of the process is not sustainable in the long-term. It’s not enough to automate operations, all of the surrounding interactions need to be automated, too.

Bernard Golden is CEO of consulting firm HyperStratus, which specializes in virtualization, cloud computing and related issues. He is also the author of “Virtualization for Dummies,” the best-selling book on virtualization to date.

Follow Bernard Golden on Twitter @bernardgolden. Follow everything from on Twitter @CIOonline