Security
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.
Five Things to Do Before Moving to the Cloud
Before moving an enterprise application to the cloud, you need to be sure that your expectations are realistic and your objectives match what the cloud can deliver. In this post, I’d like to share what we’ve learned from working with our beta customers, from their initial exploration of cloud possibilities to going live with a specific application they’ve migrated to the cloud. The following steps can help guide the thought process when considering a cloud deployment, and provide a starting point for moving forward.
1. Determine your cloud objectives. What are you trying to accomplish? Is the cloud a solution for reducing costs, faster provisioning, data center consolidation, all of the above? Sometimes all goals align, where the cloud allows you to save money, be more responsive and avoid huge infrastructure investments all at the same time. But it may not be possible to realize all the benefits for a given organization or use case. For example, if there’s extra capacity in your data center there may be no obvious consolidation advantage to putting an application in the cloud. However, there could be other issues at play that justify the move, such as high operating costs or an infrastructure that makes it difficult for users to get the support they need.
2. Pick an application that makes sense. For example, how much latency is acceptable to users? The laws of physics slow things down over the Internet and network performance will vary, so if you need millisecond response the cloud may not work for your application. How critical is the application? You may not want to put an application in the cloud upon which the business depends even if infrastructure limitations (scaling, support, response time, etc.) make it seem like an attractive option. Get your feet wet before diving in -- a safer approach might be to start with a low-risk, back office (not-strategic) application before setting your sights on more ambitious targets.
3. Involve the CSO/risk management team from the beginning. The cloud, perhaps even more than other technology shifts, has raised red flags about security since your applications and data will potentially be moving outside of the enterprise firewall. Engage your company’s security experts and decision makers from the beginning to understand their perspective and address their concerns directly. Get them involved in the discussion early so they’ll understand why the cloud is important to the business and how you want to use it. Give them a chance to review their security concerns with potential vendors before you sign up.
4. Decide which cloud(s) are acceptable. Finding a cloud that’s best suited to your needs is as critical as identifying the right target applications. Cloud offerings vary widely—in their APIs, configurations, storage infrastructure, networking options, pricing structures and SLAs. Some of the variables will be essential for your requirements, while others are simply nice to haves. The process is like evaluating any other technology offering, except the environment is probably new and unfamiliar. You may want assistance from a partner with cloud expertise who can help you qualify the various cloud options to make sure you make the right choice.
5. Create a sandbox where people can experiment. All of the different user groups should be able to see how a cloud-based application compares to a traditional one. Give business users, administrators and developers a chance to evaluate the benefits of the cloud from their perspective, as well as the limitations. Application experts can use the sandbox to run functionality and performance testing on the application in the cloud to see how it behaves compared to the traditional environment, and if any differences are acceptable.
Get Your Hands Dirty
Once you’ve done the necessary due-diligence, you’re ready to get started with beta testing and proof-of-concept pilots with vendors. In an area as hyped as the cloud there’s really no better way to learn than hands-on, and these basic best practices will help lay the foundation for a successful cloud strategy. CloudSwitch can help address the security concerns and make it “point-and-click” easy to move to the cloud, using your existing management tools and applications.
Making Cloud Computing Secure for the Enterprise
For cloud computing to gain traction in the enterprise, IT and security executives need to be certain that their company’s applications and data are safe. But when security is partly out of enterprise control, it becomes impossible to know if sensitive information has been accessed or compromised.
Today, using a public cloud means moving from an internal environment where a company has complete control of data and processes to an environment where that control belongs to someone else, and is often opaque. Within the cloud, applications run in a multi-tenant virtual environment, sharing physical machines with other customers. Companies considering moving an application to a cloud have legitimate concerns about data being compromised or stolen, including unauthorized access by cloud administrators, exposure in the internet or rogue employees using the cloud to corrupt or leak sensitive information.
One solution is to keep sensitive data within the corporate data center and put the other application tiers in the public cloud. While this approach works well for some use case scenarios, the latency impact of the “reach back” into the data center can be unacceptable for many applications and users. The other option is to move the entire application to the cloud – including the database tier – for better performance and scalability, but this exposes the application to new potential threats such as those mentioned above.
Encryption is a well-known approach to addressing these types of security threats. For protection in the cloud, the enterprise would need to encrypt all data and communications. While it’s not that difficult to add encryption software initially to the application environment, the new configuration requires ongoing management and maintenance. And in order to run the application in the cloud, the enterprise needs to deliver the encryption keys to the cloud to decrypt the data, creating additional security risks by exposing the keys in the operating environment. In the worst case, poor configuration can expose the corporate data center to threats from the cloud.
In developing our security model at CloudSwitch, we worked closely with CSOs and security teams at several large enterprises to understand their requirements. As a result, our architecture addresses three areas of protection required to make cloud computing secure for the enterprise:
- In the data center: Role-based access control protects data and processes from unauthorized access.
- In the Internet: Connections are authenticated and data is encrypted to prevent data in transit from being exposed or compromised.
- In the public cloud: Data is encrypted with keys under enterprise control, and can never be accessed by the cloud provider or unauthorized users.
The CloudSwitch security strategy is a key part of our vision to make the cloud a seamless extension of the corporate data center. Using CloudSwitch technology, companies can move applications and data to a cloud without modification, and back to the data center as needed. Companies can also select the right cloud for a specific application, based on security and compliance levels as well as service offerings and pricing structures. Only with control of applications and data at all times can enterprises take full advantage of cloud resources without sacrificing the security required by customers, internal users, regulators and other stakeholders.
RSS Feed