Source: International Security Buyers Guide, November 2010.
Abstract
There is not yet widespread understanding about the 3 service model options of cloud computing (Software, Platform, Infrastructure). This article outlines these options and examines the end user approach to managing risk relevant to each service model.
To quantify the degree of risk, it is essential to first understand the choices that exist within the framework of the “Cloud”. The approach to managing risk will vary, depending on choice.
Note: this overview is generic and does not describe all of the permutations and approaches, but provides an outline based on existing technology, knowledge and experience.
How Much Risk is in the Cloud?
There is a lot of talk about whether using the cloud is a risky proposition. An essential step to gauging risk is to understand the service and deployment models, the characteristics, and how these apply to the services or applications to be placed in the cloud.
What is the Cloud?
The National Institute of Standards and Technology (NIST) provides an excellent definition of Cloud Computing found at http://csrc.nist.gov/groups/SNS/cloud-computing/
To simplify the framework, think of the cloud as a “3-4-5 model”, namely:
3 service models, (Software, Platform, Infrastructure “SPI”)
4 deployment models, (Private, Community, Public and Hybrid)
5 characteristics, (Broad Access, Rapid Elasticity, Measured Service, On Demand Self Service, Resource Pooling)
Questions to Consider
The framework allows you to consider 3 broad types of questions:
• How much technical participation (direct engineering control) do I require?
• Which type of cloud will I use?
• What quantifiable benefits will the cloud characteristics deliver?
Cloud Service Models – “SPI”
This article focuses on “3” in the 3-4-5 framework; the 3 Cloud Service Models, and the differing approaches to managing risk. The approach depends on the degree of technical participation that the end user is responsible for, or has under their direct control.
The cloud service model is often referred to as the “SPI model” for Software, Platform and Infrastructure (for definitions see the NIST description). Depending on requirements and risk posture – some of which may be dictated by compliance or regulation, choices are available about the amount of “hands-on” control a user organization might decide to have when deciding to use or move an application in or to the cloud.
The three types of service models are:
• SaaS - Software = Turnkey Solution (e.g. Salesforce.com)
The most integrated but least extensible. Characteristics: Turnkey – software, platform and infrastructure are all managed for you. Functionality and system security is built in; “as-is”
• PaaS - Platform = “BYO Application” (e.g. Google App Engine)
Generally restricted to using the application or development environment/s specified by the provider. More extensible than SaaS. Built-in capabilities are less complete, but more flexibility exists to layer in additional security.
The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly the application hosting environment configurations.
• IaaS - Infrastructure = “BYO operating systems and applications” (e.g. Amazon Web Services (AWS)
Users do not manage or control the underlying cloud infrastructure, but have control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g. host firewalls).
Approach to Risk in SPI Model
Each of the 3 service models has a slightly different approach to mitigating risk. These approaches are detailed in the Cloud Security Alliance guidance document available found at http://www.cloudsecurityalliance.org/
In Figure One above., the “all inclusive” nature of SaaS means that risk is most effectively controlled by contract terms, and few engineering choices exist because a standardized application, platform and infrastructure is shared across a large base of users.
In the case of PaaS, risk may be mitigated by a combination of contract terms and technical engineering choices and controls. This is because the user is responsible for much of the application environment and some security features can be built in to mitigate risk.
With IaaS, a combination of contract terms and technical engineering choices and controls is still relevant, but there is much more emphasis and choice about technical security infrastructure as the user has control and responsibility for much of the operating environment.
Summary & Conclusions
• For SaaS, the primary risk control mechanism is contract terms, whereas PaaS and IaaS require a combination of technical engineering controls as well as contract terms to effectively manage risk.
• The lower down the SPI model the chosen service exists, the more control and customization available. The trade-off is more responsibility for security and management.
• The nature and types of specialty skill-sets required to assess and manage risk will vary depending on the service model chosen.
• Decisions need to be made about whether security controls can be outsourced to a provider, or maintained under the control of the user organization or an independent third party.
• To meet regulatory and compliance requirements, in every case organizational policies require careful review and consideration must be given to whether the choice of a particular model is valid.
• Irrespective of the appeal that any given technical approach may have, the business implications require alignment with an organizations overall Enterprise Security Risk Management program.
Cloud is not a “one-size-fits-all” proposition, and service model options provide choices, depending on needs. For each service model, there are differently balanced options to mitigating risk; primarily the proportions of contractual and engineering resources, which may require more direct participation in technology risk decisions by the user.
Posts
