This article can also be found in the Premium Editorial Download "Information Security magazine: Finding affordable encryption options for laptop data security."
Download it now to read this article plus other related content.
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.
HOW THE CLOUD IMPACTS SECURITY
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:
- 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.
- 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.
- 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.
- 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.
- 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.
HOW TO PREPARE FOR THE CLOUD
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:
- 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.
- 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?
- 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?
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:
- 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.
- 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.
- 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.
- 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.
MORE SECURITY NEEDED
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 firstname.lastname@example.org.
This was first published in June 2010