Cloud Providers
Security vs. Compliance in the Cloud
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedInSecurity is always top of mind for CIOs and CSOs when considering a cloud deployment. An earlier post described the main security challenges companies face in moving applications to the cloud and how CloudSwitch technology simplifies the process. In this post, I’d like to dig a little deeper into cloud security and the standards used to determine compliance.
To codify data security and privacy protection, the industry turns to auditable standards, most notably SAS 70 as well as PCI, HIPAA and ISO 27002. Each one comes with controls in a variety of categories that govern operation of a cloud provider’s data center as well as the applications you want to put there. But what does compliance really mean? For example, is SAS 70 type II good enough for your requirements, or do you need PCI? How can your company evaluate the different security claims and make a sound decision?
SAS 70 (Types I and II)
SAS 70 is a well-known auditing standard that features prominently in many compliance discussions. It encompasses a variety of controls in different categories (physical security, application security, security policies and processes, etc.). SAS 70 is not a specific set of standards; instead service organizations such as cloud providers are responsible for choosing their own controls and the goals those controls intend to achieve. With SAS 70 Type I, an independent auditor evaluates the controls and issues an opinion, while the more coveted Type II is based on at least six months of active data. Accordingly, many providers will state that they are in compliance with Type I, and Type II evaluation is underway.
SAS 70 has some wiggle room, and you have to dig a little deeper to determine what the certification really involves. The savvy cloud customer will want to know not just whether a cloud is SAS 70 Type II compliant, but what controls they selected in order to get there. This is a question that people normally don’t ask, and under SAS 70 guidelines, service providers have no obligation to tell you. Thus, the level of transparency varies. Some providers may be quite willing to share their audit report describing their controls, objectives and methods. Others will explain that the information is confidential and delivering it would expose company secrets. Or some types of control information may be freely available and others off-limits.
PCI (and Its HIPAA Component)
A second major security standard in cloud computing is PCI. As the security standard for Mastercard and Visa, PCI has a known set of required controls, making it inherently more stringent than SAS 70 where controls are determined by the service provider. The inference is that PCI has stronger security than SAS 70 (and can command higher pricing). However this is not cast in stone—it depends on the SAS 70 controls that the service provider has chosen. Due to the more rigid compliance requirements PCI branding is usually harder to achieve than SAS 70. HIPAA is a subset of PCI, which means that if a cloud is PCI compliant, HIPAA compliance comes with it.
Compliance Building Blocks
Regardless of which standard is used, achieving compliance to run an application in a cloud involves building blocks, with the cloud provider’s physical infrastructure providing the foundation. Infrastructure controls include obvious things like protecting the facility from natural disasters, assuring reliable electrical power (such as backup distribution systems) in the event of outages, and backing up data in the event of a hardware failure. They also include controls governing the cloud provider’s processes and policies such as employee authorization to access the data center and how internal security reviews are performed and reported.
Sitting on top of the infrastructure controls is a separate set of application controls. Multiple levels of security are required, for example, the transport media must be secure and data must be encrypted once it leaves the data center with encryption keys under enterprise control. An application might meet SAS 70 or other standards within a company’s data center but not when it’s moved to a cloud because of exposures that may exist there or along the way. Likewise, a SAS 70 TII application in the cloud may not meet the controls if moved back to the enterprise datacenter, and could require a re-audit.
Deploying to the Cloud
There is a difference between compliance standards and what a company needs to feel secure. For data and applications that have regulatory requirements, compliance standards and audits are mandatory. For these types of applications, we’re still in the very early days for cloud computing—let’s face it, no company is going to put critical regulated applications into the cloud without the ability to conduct complete end-to-end audits. However, even for applications that do not require compliance, enterprises want to know that their data and applications are protected. Achieving security in these environments is where CloudSwitch is focused.
Cloud computing creates a division of responsibility between the cloud provider and the cloud customer. While the cloud provider needs to address infrastructure operation and protection, the customer is responsible for ensuring compliance for their application, and ultimately the overall solution. The central idea here is keep the controls separated between the cloud provider infrastructure and the customer application. If the controls mix, where for example the cloud provider has access to stored data, then things get very complicated. When this occurs, you have to worry about who in the cloud provider’s organization has access to your data, how and when they can access it, and how this access is audited and controlled. If the provider is opaque, then you can’t know. Even if the cloud provider is more transparent in their access polices, you have to evaluate those controls against your standards and potentially have to adjust your own controls in response. Further, you have to adjust to all changes in the cloud provider’s processes over time.
By keeping your systems isolated from the cloud provider’s infrastructure, you can minimize this mixing of controls. Placing protection mechanisms into your resources in the cloud can assure that data moving across the cloud provider’s networks and all data stored in their systems is encrypted. Combined with external key storage and management, your applications can be separated from the cloud provider’s infrastructure. This still requires that the cloud provider run its data center with proper physical security, power management, etc, but can greatly enhance the application level security that the enterprise needs. Finally, this separation can simplify the process of achieving compliance at the application level when running in the cloud. This isolation layer can address a number of the data protection controls by providing a uniform and repeatable process for encrypting data.
The days of cloud computing are just beginning, but with the right combination of cloud providers and additional technologies, it’s not too early to start doing real work in the cloud and to reap the benefits of this new computing paradigm. Our early customers are doing it, and so can you.
Holiday Presents from the Cloud
As the year winds down, there are a few things I have come to expect: holiday parties, snow, and new features from cloud providers. This year exceeded all of my expectations, starting with a note in early December from our friends at Terremark letting us know that they have fixed their Windows pricing for cloud servers. Until this upgrade, if you started a Windows server in their cloud, you had to pay for a whole month of Windows licensing ($30-$100 depending on the version) no matter how much you used the server. This was rather un-cloudlike, where we want to only pay for what we use. With this new feature, running Windows in Terremark’s cloud only costs a few cents per hour (Linux cost + 20%).
Then came the snow—I live in New Hampshire, and on December 9th we received a foot of new snow to really get the season going. The very next day, Amazon made a big flurry of announcements—support for Windows 2008, the ability to boot from EBS, and the new US region US-West1.
Each of these features means big things for Amazon and for cloud users. First, support for Windows 2008 is a longstanding request from Amazon users. I think that Amazon was held back from supporting W2K8 because of the design of their boot volumes, which needed to be copied out of S3 into the local storage instance in order to boot the operating system. As the boot volume grows, the amount of resources consumed and the boot time of the servers grows significantly, withW2K8 requiring more than 10GB by default. In order to support W2K8, Amazon required another technology advance to make it possible—booting from EBS snapshots.
Perhaps the biggest problem enterprise users had with Amazon was the lack of persistent storage for boot volumes. Amazon has now created a way for users to build persistent boot volumes, coming up to parity with competitors on this feature. Sure, it’s a little different from how enterprises normally think about storage and configure boot volumes, but the ability to use EBS volumes for booting eliminates the window for data loss that most users had to contend with in the original boot methods. (This feature is not huge for CloudSwitch customers because we have always supported booting from EBS as part of our products; however, we can take advantage of this feature to improve boot times for servers in Amazon.)
Another major Amazon announcement is the new west coast region. Many of CloudSwitch’s early customers (not to mention our own development activities) are based on the east coast, so EC2’s primary location has been a good fit for us. Things only improved with the introduction of the Europe region since we have seen a lot of interest for European resources for both locality and compliance reasons. However, for west coast customers, having to hop across the whole country to access your cloud resources was less than ideal. Now these companies have local resources to target, but more important, this ongoing expansion shows that the public cloud is doing well. The addition of US-WEST1 and the soon-to-open Asia region reflect just how quickly the public cloud is growing and how hard Amazon is driving it.
The news from Amazon comes on top of what was already an outstanding year for cloud computing with major announcements from many key players, including: IBM software running in the cloud, new VMware-based public clouds, reduced pricing for servers and storage in the cloud, and Microsoft’s Azure gaining momentum. Each of the cloud providers is growing and maturing its cloud offerings, and we are reaching a tipping point where there are multiple clouds with sufficient features to support enterprise workloads. Get ready for 2010—it’s going to be an exciting year as large-scale enterprise cloud computing takes off.
Moving to the Cloud: What's Really Required
When we started talking with a wide range of IT managers and companies in early 2008, we quickly encountered a fascinating dichotomy – Cloud Computing is really easy / Cloud Computing is really hard. What made this so interesting is that the casual users were saying cloud computing was easy and the hard-core users were claiming that it was hard. Amazon and a number of other cloud providers have made major advancements since this time, but the “it’s easy / it’s hard” split still exists.
Today, if you want to use the cloud and deploy a server, it is really quite easy to “build” a server from the base templates offered by the cloud providers. There are consoles available to launch servers including providers' control panels (Amazon, RackSpace, Terramark), plug-ins for Firefox (ElasticFox), and third party products like RightScale. Start from a predefined image, add your edits, and poof – you have a server running in the cloud.
It becomes a lot more complicated when you try to integrate an application with multiple servers running in the cloud with your existing data center infrastructure. When I say infrastructure, I mean all of your existing networking, services (DNS, DHCP, LDAP, Identity), build processes, third party applications; basically, the whole of your IT environment that you depend on to make things work.
When you deploy applications in the cloud, they are running on an infrastructure built and maintained by the cloud provider. This means that there is a certain amount of control that is transferred to the provider –the underlying control and assignment of resources they require in order to manage their environment. You need to understand this new environment, select the appropriate resources, and adapt your application to it. But moving an application that’s been running in your enterprise infrastructure, with all its associated processes and relationships, to a cloud provider that has its own way of doing things is where using the cloud gets hard.
To highlight some of the difficult areas, we’ll examine a set of issues across a variety of cloud providers out there. Because there’s a lot of ground to cover, I’ll break up the posts into multiple parts dealing with storage, networking, management, performance, and security. We’ll start with storage since it represents the real identity of the server and all that is important to your application and business. Stay tuned.
Next: Key considerations for cloud storage
RSS Feed