The need for careful review of cloud service-level agreements is clear. Cloud services that have well-defined conditions and responsibilities will set customer expectations and provide an assurance of value. This tip outlines some of the security and compliance considerations with regard to developing a
ITIL v3 defines a service-level agreement (SLA) as terms between a provider and a customer that describe a service, document targets and specify responsibilities. To put it in security terms, an SLA should bring transparency to an environment capable of rapid change and automation through the use of metrics in order to maintain trust.
With that in mind, key concerns for cloud security and compliance are tied to three primary areas of risk:
- Ownership of assets, which involves data custody, control, possession and right of return;
- Service availability, monitoring and response, which tend to be measured as cost relative to the terms and ability of continuation; and
- Service baselines, such as regulatory compliance or security due diligence for vulnerability and configuration management.
Writing an SLA to cover the above three areas of risk is made easier by considering four control areas (technology, process, people and geography) and measuring them based on levels of availability, confidentiality and integrity.
Cloud SLA: Availability
Availability perhaps is the most infamous SLA item for service providers. Response time, recovery time and recovery point are the usual metrics. An Amazon service outage in 2011 that lasted several days illustrates how geography has become front and center to a cloud SLA. The outage did not violate Amazon's EC2 SLA, which provides for "99.95% availability of the service within a Region over a trailing 365-day period." In other words, when a region of Amazon's EBS and RDS "Availability Zone" became unexpectedly unavailable, fine-print in the company's SLA protected it from complaints. Customers who required a higher level of service needed to have requested multiple availability zones, service across different geographic areas ahead of time.
Cloud SLA: Confidentiality
Geography has the reverse effect on confidentiality. Most do not want their data spread across jurisdictions. Europeans, for example, tend to want data they "own" to avoid touching servers in America because custody, control and possession can be subjected to U.S. laws and enforcement. On the flip-side, a regulatory requirement in America called International Traffic in Arms (ITAR), requires only U.S. citizens be allowed access. In order to meet that requirement, Amazon announced in 2011 a service that isolated to a single data center.
A cloud SLA has to address location with regard to encryption, identity management and other controls subject to national regulations. Another important aspect to this issue is how people, process and technology will securely destroy data to prevent disclosure. The flexibility of a cloud with associated high-availability and geographic distribution begs the question of exactly how a provider will prove data has been destroyed everywhere to a recognized level or standard.
Cloud SLA: Integrity
Integrity measurement tends to point toward risks involving data format and portability, as well as change management. Will a cloud provider use a proprietary format for systems that are a barrier to customer exit? What assurance does a cloud provider offer that a virtual system image or an application has not been modified without authorization by the customer? Some SaaS providers have released changes and even bugs into production without notice or a documented reverse plan; customers are impacted when business processes -- including those based on application programming interfaces -- start to fail unexpectedly.
As you may see, there is a very broad set of risks with some unique factors that must be addressed for a cloud to provide realistic assurances in an SLA. Fortunately, existing standards, guidelines and control lists can be easily adapted to address these factors. The ISO 27001 information security management framework, drawing from the ISO 27002 controls, has become a common international standard to describe and detail security controls of cloud service providers. Also, the SSAE16/SOC2 is replacing the SAS70 standard in the U.S. to describe service provider controls. Customers should consider these standards as a foundation when developing cloud SLAs.
About the author:
Davi Ottenheimer is president of security consultancy flyingpenguin and author of Securing the Virtual Environment: How to Defend the Enterprise Against Attack. He is a QSA and PA-QSA for K3DES with more than 18 years of experience in security operations and assessments, including a decade of leading incident response and digital forensics. Davi formerly was global communication security manager at Barclays Global Investors and a “Dedicated Paranoid” at Yahoo! responsible for digital home, broadband and mobile security.
This was first published in November 2012