In this tip, the eighth in our series of technical tips on cloud security, we discuss cloud compliance. Cloud compliance concerns are one of the major reasons that companies are holding
back from using cloud services. The promise of inexpensive, flexible computing that can be created, dismantled, reconfigured, grown and shrunk on demand is very appealing, but can it incorporate necessary regulatory requirements?
Standards and regulations, such as the Massachusetts Privacy Law (201 CMR 17), PCI-DSS, SOX, Nevada SB-227 and HIPAA, are requiring many organizations to evaluate their data protection measures. Moving to the cloud can impact an organization's ability to comply with these regulations and standards. In this tip, we'll explore two of the more problematic characteristics of cloud computing that adversely affect an enterprise's ability to maintain compliance.
The main questions in regards to compliance
Virtually every regulation requires organizations to adequately protect their physical and informational assets. To do this, there is an implied or assumed ability to control and prove:
- What information is stored on a system?
- Where is the information stored?
- Who can access the system?
- What they can access?
- Is the access appropriate?
All of these questions imply some level of ownership of the assets in question, and that is where cloud compliance issues become apparent. In a public cloud environment, you are able to answer the first of those questions with certainty; the other four, however, end up posing a compliance problem. We'll look at each of them in turn.
Where is the information stored?
In a typical corporate data center or a colocation center, everyone knows where the disk and server physically reside, and that fact can be proven during an audit. Even a shared service provider can typically tell you which physical systems you are utilizing and identify the data location for audit purposes.
Even with regards to virtualization and disaster recovery, you can, with reasonable effort, identify the physical resource where your information resides. By definition, this is not the case in a public cloud, and this presents our first cloud compliance problem.
In the cloud, there is no expectation on the provider's side to be able to show you where your information resides. This is not to say that the provider cannot do it, but that the market has not driven them to the point of providing this service. Also, to be fair, requiring that type of location awareness is in conflict with the purpose of cloud computing.
So what can you do? Ensure that the provider you use is able and willing to work with you to provide, and prove, any data location restrictions you may have.
The who, what and why of system access
Our second compliance-related issue for the public cloud is related to the questions:
- Who can access the systems that have your information?
- What can they access?
- Is the access appropriate (also known as why)?
As far as the "who" is concerned, while you can control your side of the equation, your provider has staff that can access the systems as well. The main people we are concerned about in this regard are the administrators, both systems and application, at the provider's site. We need to know who the system and application administrators are.
When looking at the "what" can they access, we are concerned about the provider's ability to access the underlying infrastructure or application that our information is stored on. Is the access through the hypervisor (e.g. Infrastructure as a Service) or at the application level (e.g. Platform and Software as a Service)?
Finally, the question of "why" they need that access. This is Security 101: Access should be based on job role, and a clear description of the level of access needed should be provided.
In reality, this is an issue that also arises in shared hosting facilities. The main difference is that many cloud providers are not in a position to meet the requirements set forth in many compliance documents, whereas shared hosting facilities are mature enough to have that capability under their belt.
So what do you do? Ensure that the provider you use is able and willing to prove they use separation of duties for administrative functions, and that they have the ability to "prove" who had access to a system and information and when they had this access. Note that this last requirement would require a robust and state-of-the-art security-related logging solution to be deployed.
As a side note, I believe that the industry as a whole will work on certifications for public cloud providers, and that those certifications will be acceptable for a consumer's compliance.
Much of compliance is about ensuring proper controls over who has access to assets, what level of access they have and how those levels are maintained. The way those things are typically ensured is through audit, where we must say what we are doing and prove we are doing it. The relative immaturity of the public cloud environment makes audits very difficult and sometimes impossible. Two things are going to have to happen to change this landscape:
- The public cloud offerings will have to mature and become more standards-compliant.
- Public cloud providers will have to have contractual language that will assist its customers in meeting cloud compliance requirements.
ABOUT THE AUTHOR:
Phil Cox is a principal consultant of SystemExperts Corporation, a consulting firm that specializes in system security and management. He is a well-known authority in the areas of system integration and security.
His experience includes Windows, UNIX, and IP-based networks integration, firewall design and implementation and ISO 17799 and PCI compliance. Phil frequently writes and lectures on issues dealing with heterogeneous system integration and compliance with PCI-DSS. He is the lead author of Windows 2000 Security Handbook Second Edition (Osborne McGraw-Hill) and contributing author for Windows NT/2000 Network Security (Macmillan Technical Publishing).
Phil holds a BS in Computer Science from the College of Charleston
This was first published in January 2010