Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Cloud computing risks and how to manage them

Cloud computing alters enterprise risk. Here's what you need to know in order to safely navigate the cloud.

As cloud computing moves from marketing hype to reality -- real customers with real utilization, it's increasingly...

important that information security practitioners understand the significant change in computing the cloud heralds and how that impacts enterprise risk. Cloud computing is evolving rapidly, and there is no shortage of vendors suddenly claiming to be "cloudy," which can make it all the harder to discern the critical security ramifications of the cloud for the enterprise.

We'll shine a light on cloud computing and examine how the public cloud model alters the enterprise risk posture. We'll also look at how information security practitioners should prepare for moving into the cloud as well as emerging governance frameworks and other changes that must happen to make cloud computing more trustworthy.


To begin, cloud computing is an evolution in computing, and does not introduce new technology. Instead, the cloud is about a different business and operating model -- one based on shared resources. Those shared resources are the only way to gain the economies of scale that result in lower costs -- one of the primary business drivers for cloud computing, along with agility. However, this change in business model also portends changes in information security that demand to be evaluated. Here are some of the security challenges that come with public cloud computing:

  1. Trust boundaries are unclear. In traditional organizational IT, information security practitioners know where their trust boundaries are. Typically that means everything inside the "perimeter" (at least the concept of a perimeter) plus external facing systems and some third-party connections, depending upon an organization's unique circumstances. With cloud computing, where those trust boundaries are vis-à-vis cloud service providers' responsibilities is far less clear. What your direct security responsibility is versus a provider's is probably not clearly defined in the provider's service level agreement (SLA). Additionally, those changes in responsibility vary from provider to provider. And, on top of that, responsibilities depend on where you are in cloud computing's service delivery model, SPI (software-as-a-service, platform-as-a-service, and infrastructure-as-a-service). That is, your responsibility versus a provider's responsibility is different for SaaS than for IaaS. This confusion about trust boundaries is the primary reason that information security practitioners are concerned about the security of cloud computing, along with current cloud service providers' general lack of transparency about their security.
  2. All data separation is now logical. Formerly, organizations used to ensure that their data was physically separated from other organizations' data. Of course, when data is stored internally in an organization's own data centers that's exactly what's done -- physical separation of data. Even when an organization uses a hosting service, it still separates its data physically. For example, while a hosting service provides a shared facility for multiple customers and there is usually some sharing of network resources, customers usually have dedicated (though rented or leased) servers on which to run their applications and store their data. The same is true with application service providers (ASPs). However, with public cloud computing all computing resources are shared.
  3. Network exposure increases. While this network exposure itself is not new, the magnitude is greater in the cloud than has existed previously. Because users must now traverse the Internet to reach their applications and/or data, as opposed to possibly just an intranet, there is an increased risk that such access is subject to network threats that are usually prevented at the perimeter. For example, a distributed denial of service (DDoS) attack could be directed either against your organization's Internet gateways or your cloud service provider, impeding access to cloud-based applications and/or data. Imagine if such an attack were launched during your organization's end of month or end of quarter processing. Traffic interruption through redirection by means of a Border Gateway Protocol (BGP) attack is also possible with public cloud computing.
  4. Application exposure increases. Applications that might have previously been safer because of their internal location are external and quite exposed when they are public cloud-based and Internet-facing. Many SaaS providers contend that their applications are safe because of the reduced attack surface that these server-based applications have -- a browser is used for access; no application-specific code or functionality is on the client -- as well as the fact that some SaaS applications are exposed only through their application programming interfaces (APIs). Of course, that assumes that SaaS providers have actually taken steps to secure their applications and APIs, and have tested such. That also assumes that SaaS applications are used as stand-alone services, with no integration with other applications, which is a questionable assumption. The fact that many SaaS applications are actually built by third parties on other cloud services (either PaaS or IaaS) further calls into question the security of SaaS applications. Additionally, many SaaS APIs (including Amazon Web Services, Google, and Salesforce.com) use REST (REpresentational State Transfer), which has no predefined security methods.
  5. The governance model changes. More specifically, the issue is that there is no established governance model currently for cloud computing. How exactly are information security professionals supposed to protect their organizational data in what should be considered an untrusted environment? Fortunately, there is now work underway to develop a governance model for cloud computing.


Given the risks, the public cloud -- at least for now -- is not good for sensitive, regulated, and/or classified information. What it is good for is non-sensitive, non-regulated, and unclassified data -- data that is probably already public and most of which is intended to be public. For the vast majority of organizations (except defense contractors, the military, and the intelligence community), such publicly releasable information probably makes up 90 percent of their data. Besides, for sensitive, regulated, and/or classified information, private clouds or cloud infrastructure shared by several organizations (community clouds) are still attractive options. For example, the Defense Information Systems Agency (DISA) operates a community cloud for the Department of Defense, Rapid Access Computing Environment (RACE), which is supposed to begin accepting classified information soon.

With that in mind, here are steps security practitioners should take when investigating the use of public cloud services:

  1. Self assessment. The number one priority should not be to investigate the security afforded by cloud service providers. The top priority should be to examine your own data classification policies and how well those polices currently are enforced. Before figuratively beating up a cloud service provider over their relative lack of security (compared to that implemented by most large enterprises), make sure that your own data house is in order. Do you have an up-to-date data classification policy? How well enforced is that policy? Do you have data stewards and custodians assigned for all data? What is the awareness level of your own organization's privacy policy, and how well is it enforced (assuming that your organization has one)?
  2. Data anonymizing. What tools and capabilities does your organization have for anonymizing data so that any elements that identify individuals are removed? If you do move to the cloud, expect that other business units will likely overwhelm information security with requests for help on anonymizing data so that it can be put into the cloud in compliance with your data classification policy.
  3. Due diligence. When these data classification activities have been accomplished by your organization, then your due diligence of cloud service providers' security should begin. For example, what is the connectivity model to the public cloud for administration? What support is there for leveraging existing security monitoring and management tools, including vulnerability scanners, change management and firewall policy enforcement at network- and host-levels (e.g., through use of a virtual private cloud)? Some applications require database connectivity back into the organization and may violate existing policy. Also, your organization might have a requirement for strong authentication support; can the provider meet that requirement?
  4. Endpoint security. While you are conducting such due diligence, essentially of your organization's new IT back-end capabilities, don't forget about your organization's IT front-end capabilities. How is the security of all those end-user devices that will be used to access the cloud and your data in it?

The Basics

Here's a quick overview of the essential elements of cloud computing

By now, security practitioners should at least have a good, basic understanding of cloud computing. If you've been too busy fighting tactical fires to have that level of understanding, you need to take time to get up to speed. A good place to start is the National Institute of Standards and Technology (NIST).

NIST defines cloud computing as composed of five essential characteristics, three service models, and four deployment models.

Among the five essential characteristics described by NIST, resource pooling is the most important and what sets cloud computing apart from earlier IT business models. Think "shared resources" or "multi-tenancy," as several providers refer to it. The most significant promise of cloud computing is lower costs, and those lower costs come only through economies of scale, and those economies of scale come only through use of shared resources. Unlike earlier IT business models, such as hosted services or ASPs (application service providers), all resources are shared in cloud computing.

Notice that virtualization is not a defining characteristic of cloud computing. Oftentimes, media sources equate virtualization with cloud computing. That is wrong. Virtualization is an enabling technology often used in cloud computing but virtualization does not equate to cloud computing. In fact, the largest cloud computing provider, Google, does not use system or machine virtualization (though it does use application and storage virtualization). It chooses instead to scale horizontally by adding more standardized servers.

In the technology sector, we love our acronyms as almost as much as the military does. But some acronyms are essential to understanding cloud computing. "SPI" refers to the three service delivery models in cloud computing: software-as-a-service, platform-as-a-service, and infrastructure-as-a-service. These three models effectively form a "cloud stack," with SaaS at the top and IaaS at the bottom. These three different types of cloud services are deployed in four different models, as defined by NIST: private cloud, community cloud, public cloud and hybrid cloud.

From a security perspective, it's important to note that as an organization moves up the cloud stack, it loses operational flexibility and direct control over security. An IaaS customer has far greater control over its configurations, actions, and security than a SaaS customer does. For some users, that is a negative. However, for many organizations, the lack of comparative operational flexibility in SaaS is in fact a benefit. Many companies move to the cloud precisely because of that lack of operational flexibility; the cloud service provider is responsible for providing nearly everything, making it extremely easy for organizations to switch to this new business model.



While public clouds are good for public data (non-sensitive, non-regulated, and non-classified data), there are many organizations that would like to utilize public clouds for other data -- provided their security is adequate. And today, public cloud security is not adequate for this sensitive data.

The biggest security problem with public cloud computing is a lack of transparency by cloud service providers about their security capabilities: Generally, they are reluctant to be audited and their service level agreements are worthless. Cloud service providers themselves have begun, privately at least, to admit to such shortcomings. They agree that it is in their best interests, as well as their customers, to have more transparency and to have some sort of standardized security framework to be measured against.

In fact, in the last couple of months, almost the opposite problem has arisen: There are now multiple organizations developing different security frameworks for cloud computing. Frameworks in development include:

  1. A6 (Automated Audit, Assertion, Assessment, and Assurance API) Working Group: This effort, also known as CloudAudit, is led by well-known security expert Chris Hoff, director of cloud and virtualization solutions at Cisco Systems.
  2. Trusted Cloud Initiative: Under development by the Cloud Security Alliance. According to Liam Lynch, chief security strategist for eBay and co-chairman of the initiative, the effort will build on the "pillars" of the alliance's work and will include all vendors with products that enable an end-to-end security platform. The initiative also plans to provide reference implementations and will incorporate the A6 initiative.
  3. Common Assurance Maturity Model (CAMM): A 24-member consortiumof mostly vendors, but also includes the European Network and Information Security Agency (ENISA). CAMM originally launched in February as Common Assurance Metric. According to Gerry O'Neill, CEO of the U.K.-based Institute of Information Security Professionals and a CAMM steering committee member, a formal release is planned for November.
  4. Federal Risk and Authorization Management Program (FedRAMP): Related to the other three projects, this is an effort intended to be a U.S. government-wide initiative that would provide joint authorizations and continuous security monitoring of shared IT services for federal departments and agencies that enter contracts with outside providers, including those offering cloud computing solutions. The National Institute of Standards and Technology (NIST) co-chairs this effort.


Besides greater transparency, there are other improvements that cloud computing needs in order for enterprises to rely on it for more than non-sensitive and unregulated data. From a technical perspective, the primary security improvement needed is better attribute management, for both identity and (cryptographic) key management. Better identity management is necessary in terms of expanded use of federated identity -- both enterprise-centric, typically supported by standards such as Security Assertion Mark-Up Language (SAML), and consumer-centric, supported by standards like OpenID. However, federated identity management still suffers from trust issues (i.e., acceptance of an assurance issued by another organization), as well as the management of credentials themselves.

Cryptographic key management also suffers from a lack of federation. OASIS' Key Management Interoperability Protocol (KMIP) is an improvement that standardizes use of clients-to-servers protocols. While this effort is significant for private clouds within enterprises, it remains insufficient for public cloud computing. What is really needed for cryptographic key management, in addition to KMIP, is standardized use of servers-to-servers protocols and support by third parties (independent from cloud service providers) for key lifecycle management, including back-up and revocation. But the larger issue is why do we manage identities and cryptographic keys separately, especially when both have evolved similar management frameworks? Both identities and cryptographic keys are attributes, which should be managed in a common framework that also accommodates other attributes. Only such a framework will scale to a public cloud and inter-clouds, or cloud-to-cloud interaction.

We've only touched on the surface of the security concerns with cloud computing, especially with use of public clouds. However, before casting too much dispersion on cloud service providers about their security capabilities and offerings, take a step back and look at your own organizational readiness to use the cloud. And, let's remember that cloud computing is indeed immature at this time. The cloud is maturing, and there is no shortage of standards-type organizations and industry groups now trying to ensure that happens. But before impulsive calls for regulations, we need to give the market some time to find its own level.

There has been a huge amount of progress in this new business and service delivery model in the last two years, and we can expect that the associated security and privacy issues will make progress in the next two years. Will that development be sufficient to enable public clouds to host sensitive or regulated information in the next two years? Highly doubtful. Will that evolution be sufficient to allay concerns by organizations and consumers about how cloud service providers handle their data? Probably. The cloud is evolving rapidly and getting better -- be patient and diligent.

Tim Mather, a long-time information security practitioner, is co-author of Cloud Security and Privacy and a security consultant. Send comments on this article to [email protected].

Dig Deeper on Secure SaaS: Cloud application security