Shayne Bates maintains a blog at http://www.cyber-crime.biz.
Increased security responsibility further down the cloud service model means moving from contracting to building in security to effectively mitigate risk.
If you ask a security executive for an elevator pitch about risk management in the cloud, some will defer to IT-literate subordinates who quickly immerse you in techno-babble about multi-tenant databases, identity and access, or a lecture about the dangers of online computing.
While this information is relevant, it frequently lacks a strategic business context to adequately frame what the cloud really is, the types of cloud that are available as a service (no offense intended to product marketers), and an overview of the different approaches required to manage risk depending on the service type being contemplated.
This article is a primer to understand the three different cloud service models — SaaS, PaaS and IaaS — and the fundamentally different balances required to effectively manage enterprise risk. The 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.
Understanding the Business Implications
As Enterprise Security Risk Management (ESRM) continues to emerge as a more mature contributor to Enterprise Risk Management (ERM), an understanding of the three service model options for cloud computing (Software, Platform and Infrastructure) becomes essential for security executives to understand, in order to bring business value to the equation. Business value can exist in many forms; such as enhanced service and reduced cost, monetization of a company’s services, or a reduced risk ratio to the required technology investment.
This is achieved by understanding the goals of the business and subsequently analyzing how security will align and contribute to those goals. As an opening example, a CSO would generally not want to submit an Infrastructure-as-a-Service (IaaS) proposition for a new security system — which requires heavy investment in that organization’s technical resources — if the goal of the business is to to shed and partner, rather than invest in technical expertise. Understanding the business implications of cloud service model differences, and relevant terminology becomes vital to enable sound analysis and formation of an effective strategy.
There is a lot of discussion about whether using the cloud is a risky proposition. The answer, as always, is that “it depends.” An essential step to gauging risk is to understand the service and deployment models, the characteristics, and how these apply to services and applications. For example, will existing, custom applications be placed in the cloud, or will new ones be adopted? How much risk is considered risky? Our job as security professionals is to present options to the business, in order to enable effective decision making.
What is the Cloud?
The National Institute of Standards and Technology (NIST) provides an excellent definition of Cloud Computing in its publication which is found at http://1.usa.gov/AxFIPk.
To simplify the framework, think of the cloud as a “3-4-5 model” and a series of choices, namely:
• 3 service models: Software, Platform or Infrastructure (“SPI”);
• 4 deployment models: Private, Community, Public and Hybrid; and
• 5 characteristics: Broad Access, Rapid Elasticity, Measured Service, On-Demand Self Service and Resource Pooling.
The framework allows you to consider three broad questions:
1. How much technical participation (direct engineering control) does the organization require?
2. Which type of cloud(s) will we use, and why?
3. What quantifiable benefits will cloud characteristics deliver to meet the functional needs that security has, and how will they deliver business value?
Whether your organization is a U.S.-centric DoD contractor, or if it is distributed globally will also determine whether geographic boundaries are an important factor in decision making. For example, consider the laws of the European Union, which have significantly more individual privacy requirements than North America. If you are building a global, enterprise security system, these considerations should be at the core of any strategy.
The Cloud Service Models
This article focuses primarily on the “3” in the “3-4-5 framework” — namely the three 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,” which stands for Software, Platform and Infrastructure. Depending on requirements and risk posture — some of which may be dictated by compliance requirements or regulation — choices are available about the amount of “hands-on” control an organization might require when deciding to use or move an application to the cloud.
The three types of service models are:
SaaS (Software as a Service): This is a software, or Turnkey Solution (e.g. Office365.com or Salesforce.com). SaaS offers the most integrated user experience, but is the least extensible. As a turnkey solution, the software, platform and infrastructure are all managed for you. Functionality and system security is built in “as-is.” For an introduction to Software as a Service for the Physical Security Practitioner, see the work of the ASIS International IT Security Council at: http://bit.ly/asiscloudcomputing.
PaaS (Platform as a Service): This is considered a “BYO Application” (such as Microsoft Windows Azure or Google App Engine). Although PaaS options were once generally restricted to using the application or development environment(s) specified by the provider, some are now offering support for multiple environments (e.g. – Windows Azure allows Java and other technologies in addition to Microsoft’s own tools). PaaS is 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; however, the end-user has control over the deployed applications and possibly some of the application hosting environment configurations.
IaaS (Infrastructure as a Service, pronounced “ice”): This is considered a “BYO operating systems and applications” service, such as 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, such as host firewalls.
Matching Service Model Questions with Business Requirements
While the outline above can quickly lead to deep technical discussion, one approach to determining service models and cloud choices to meet business requirements is to consider the following five questions:
1. Location: Is the desired solution an on-premises, off-premises or a combination hybrid?
2. Infrastructure: Will it require exclusive or shared infrastructure?
3. Investment: How much capital is required, or is it an operational expenditure decision?
4. Ownership: Do I need to own the solution, or can I lease or rent it?
5. Management: Will it be managed in-house, or will a third party manage it?
Asking these questions will likely engage every stakeholder and division of the business, and provide fertile ground for a business-related discussion. The careful crafting of questions is a powerful tool to align business requirements with any cloud-centric strategy and obtain buy-in from stakeholders, especially when presented with choices about the risks (and rewards) of each option.
Each service model has a slightly different approach to risk mitigation. These approaches are detailed in the Cloud Security Alliance guidance documents available at cloudsecurityalliance.org.
In the graphic 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.
Summing it Up
The 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.
Here are some key takeaways from the cloud service model discussion:
• 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.
• Regardless of the appeal that any given technical approach may have, the business implications require alignment with an organization’s overall Enterprise Security Risk Management program.
Shayne Bates, CCSK, CPP, CHS-V, FABCHS, leads security cloud strategy development as a Consultant to Microsoft Global Security. He has extensive experience in cloud, security technology, business process and operations, and has served in advisory roles to executive teams collaborating with stakeholders on a global scale. A frequent contributor to security topics, Bates has numerous published articles on topics including risk management and cloud computing, and he maintains a blog at http://www.cyber-crime.biz.