Enterprises continue to be drawn to the cloud, where data and application management is outsourced to a third party in charge of hardware infrastructure. The cloud has matured to where it now comprises several specialized services described by an alphabet soup of acronyms: SaaS (software-as-a-service), PaaS (platform-as-a-service) and perhaps the least pronounceable of all, IaaS (infrastructure-as-a-service).

A recent Gartner study predicts double-digit growth in all cloud sectors.

But outsourcing critical functions to a third party invites important security questions. When enterprises run their own IT in-house, they can define and control the security protocols. When relying on a cloud provider, how do you know what security protocols are in place and how well they are performing?


The cloud industry itself is still evolving frameworks for answering these questions. The leading approach is by defining cloud security standards – industry-wide protocols that can be certified for a given cloud provider. With a thorough and widely adopted standard in place, potential cloud customers will have the tools to evaluate the security offered by a cloud provider.

But the cloud provider industry has yet to adopt a single standard. The existing range of standards, where they are adopted at all, can be confusing to navigate. The resulting confusion means that cloud security standards in cloud security could be described as, ahem, partly cloudy.

Cloud Security Alliance

The largest and arguably most comprehensive player in cloud security standards is the CSA or Cloud Security Alliance. With corporate members including Amazon Web Services, Microsoft, Oracle, RackSpace, RedHat and Salesforce (among dozens more), most blue chip industry cloud services have a stake in the CSA.

The CSA has developed a compliance standard known as the CCM or Cloud Control Matrix. Published in Excel spreadsheet format, the CCM describes over a dozen areas of cloud infrastructure including risk management and security. The CCM goes beyond security itself and includes compliance measures which also address government and legal regulations and hardware architecture.

The CCM describes hundreds of criteria. For example, from the category “Facility Security – Secure Area Authorization” you can find this control specification:

Ingress and egress to secure areas shall be constrained and monitored by physical access control mechanisms to ensure that only authorized personnel are allowed access.

The criterion obviously speaks to the question of the physical security of a cloud provider's facilities. But the standard does not exactly dictate implementation.

For a customer evaluating a cloud provider, if a standards audit could assure you that the provider complied with (in this case) CCM v1.3 control specification FS-04, this is far better than knowing nothing or simply taking the provider’s word for it. But even knowing this, an organization might want to press for more detail in how the provider implements the specification.

NIST, IEEE and ENISA

Standards bodies the world over share a love for names that read like a round of Scrabble. They are also developing their own guidelines for cloud standards, which include coverage of security.

NIST, the U.S. National Institute of Standards and Technology, last year published its Guidelines on Security and Privacy in Public Cloud Computing. Unlike the CSA CCM, the NIST guidelines are aimed at the cloud customer and detail what customers should consider and inquire of a potential cloud provider.

The IEEE – Institute of Electrical and Electronics Engineers – has embarked on its own development of cloud security standards. Known as project P2301, in its Guide for Cloud Portability and Interoperability Profiles, the IEEE has focused primarily on standards to define interoperability between cloud providers.

Although security is only one facet of interoperability standards, for cloud customers interoperability itself is a key to avoiding the potential for vendor lock-in. Without standards in place making it easy to move data and processes between cloud providers, customers can become stuck with one provider – and that can become a security liability.

Not to be left out, the European Network and Information Security Agency or ENISA has published Procure Secure: A Guide to Monitoring of security service levels in cloud contracts. Oriented toward public sector cloud customers, the ENISA guide breaks down key requirements that a client should look for in a cloud provider to ensure strict adherence to security protocols.

Beware SAS 70

One standard that has already seen its light fade in the quickly evolving world of cloud services is SAS 70 , part of the Statement on Auditing Standards issued by the Auditing Standards Board of the American Institute of Certified Public Accountants. Though it was originally created to audit corporate compliance with financial reporting rules, some cloud providers also use SAS 70 as an alleged certification of their security protocols.

But critics including Gartner say SAS 70 suffers from notable shortfalls in providing useful security guarantees to customers. Some argue the audit has been too far overextended beyond its original intent and does not adequately address modern threat assessments. In addition, SAS 70 has been knocked for representing a snapshot in time which may not reflect a service provider’s ongoing performance.

The fact that high-profile cloud services like Amazon experienced failures while technically complying with SAS 70 has further tarnished the audit. Consequently, customers evaluating cloud providers today are warned against placing too much emphasis on SAS 70 certification. Gartner advises supplementing SAS 70 with self-assessments and agreed-upon audit procedures.

Aaron Weiss is a technology writer and frequent contributor to eSecurity Planet and Wi-Fi Planet.