Posted on by Cloud Computingin
The transition from on-premises information systems to cloud services represents a significant, and sometimes uncomfortable, new way of working for organizations. Establishing meaningful Service Level Agreements (SLAs) and monitoring the security performance of cloud service providers are two significant challenges. This post proposes that a process- and data-driven approach would alleviate these concerns and produce high-quality SLAs that reduce risk and increase transparency.
The National Institute of Standards and Technology (NIST) defines cloud computing as "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources." There are several variations of the cloud computing model. These are differentiated primarily by the level of control an organization retains over the shared computing sources. The public cloud is defined as a model in which all shared computing resources are operated by a third party on their premises. Expertise in cloud architecture, risk management, and supply risk management varies greatly. A study by Citrix found a general lack of knowledge about cloud concepts among corporate decisions makers. This research noted that "first to mind when asked what 'the cloud' is, a majority responded it's either an actual cloud, the sky, or something related to the weather." This meteorological interpretation of cloud computing concepts is evidence of a potential knowledge gap in a vital element of enterprise risk management.
Information security management expectations and techniques need to evolve along with the service delivery model. Service Level Agreements (SLAs) are a prominent feature of this newly altered domain of information security. SLA are the subject of a great deal of cloud security research. This is no surprise given the prominence of SLAs in the cloud computing model. They are the most practical monitoring mechanism available to most cloud service consumers. NIST defines a Service Level Agreements as "a binding agreement between the provider and customer of a cloud service" (SP 500-307, pg.8). The SLA lifecycle is commonly described as having five phases: negotiation, implementation, monitoring, remediation, and renegotiation). Each phase of the lifecycle presents challenges to the cloud services consumer.
Negotiating SLAs can be a difficult task. This is especially true for smaller organizations attempting to negotiate with large cloud service providers. Standard, non-negotiated, SLAs are not surprisingly advantageous to the provider and minimize penalties for non-compliance. The concept of dedicated security Service Level Agreements (SSLAs) is relatively new and still resisted by some providers.
Putting an organization's vital information and data assets in the hands of a third party can be a source of new risks. One should not assume that cloud service providers are meeting security expectations because of their size and reputation. SLAs are the most impactful method by which information security practitioners can peer into the propriety black box of the cloud. The advice offered to me by one former CISO that "managing SLAs and doing security" are different should be remembered. The objective needs to be improving SLAs to demonstrate tangible improvements rather than producing more complex charts or visually appealing graphs without meaning.
Trust in the cloud is believing that the third-party provider will proactively manage security in the best interest of the consumer. Risks will be identified, and mitigated, without a need to revisit the SLAs in a time of crisis. This means applying judgement to new and unanticipated issues within the context of existing SLAs. The cloud service provider will operate with great transparency and not obscure information that may indicate that service levels have not been met. In this way trust should be viewed as the next stage of relationship after establishing justified confidence (see Figure 1: Evolution of Trust)
Figure 1: Evolution of Trust
The need for high-quality SLAs is not obviated by trust. In fact, SLAs are essential to creating the conditions for trust. According to researchers Huang and Nicol, "'trust, but verify' is good advice for dealing with the relationship between cloud users and cloud service providers." Huang and Nicol also identify three key attributes for placing trust in a cloud services provider: competency, goodwill, and consistency. This is an area of significant opportunity to improve security SLAs. They should facilitate trust by verifying that cloud service providers are exhibiting the attributes of competency, goodwill, and consistency.
A framework for the creation and management of SLAs would help to ensure a consistent level of quality and usefulness in SLAs. This framework must also be accessible to the target community of information security professionals. Academics lament the lack of measurement in cloud security SLAs, but typically offer only additional calculus as a solution. The framework needs to produce SLAs with sufficient quantitative data without overwhelming the user. SLAs need to be tied to security requirements important to the service consumer.
The software engineering and operational resilience communities have faced challenges similar to cloud consumers. Capability maturity models emerged as a solution to the need for a standard set of processes and metrics. CMMI for Outsourcing and the CERT Resilience Management Model were designed to be rigorous in process and applied broadly. These examples provide a useful path forward in the evolution of requirements management. Additionally, as securing public cloud services becomes more integrated with other facets of supply chain risk management; a framework containing comparable techniques will be of great value to the organization.
The framework proposed by this author draws on the concept of capability maturity in that a progression of measurable activities result in a desired end state (i.e., high-quality security SLAs that reduce risk and increase transparency). The SLA creation and management framework divides activities into two basic phases of a lifecycle: (1) Relationship Formation and (2) Ongoing Relationship Management. Each phase contains discrete processes and the phases are linked (i.e., the output of the Relationship Formation serves as input for Ongoing Relationship Management).
The Relationship Formation phase comprises (1) creation of a detailed service description, (2) translation of internal security requirements to cloud service provider requirements, (3) selection of specific SLA metrics and measurements, and (4) negotiation and agreement on specific SLAs with the cloud service provider. The Ongoing Management phase contains the following processes: (1) independently monitoring and verifying the security performance of the cloud service provider, (2) performing periodic service reviews with provider using the SLAs, (3) conducting root cause analysis as required on service security issues, (4) invoking penalties for SLA violations as required, (5) managing corrective actions to resolution as specified in the SLAs, and (6) capturing lessons learned to inform revisions of the SLAs (see Figure 2: SLA-Creation and Management Framework).
Figure 2: SLA-Creation and Management Framework
Using the cloud requires the acquisition of new skills and methods. Establishing meaningful SLAs and monitoring the cloud service provider security performance are two significant challenges. This author proposes that a process and data-driven approach would assist in alleviating these concerns and produce high-quality SLAs intended to reduce risk and increase transparency. The proposed SLA creation and management framework leverages concepts from capability maturity models to ensure rigor and accessibility. Application of the framework would help recast SLAs as a device to help facilitate the development of trust. Security SLAs have migrated from the pages of contracts to the forefront of performance management.
Visit the SEI Digital Library for other publications by Matthew.