Is the cloud insecure? Maybe. But that's not the first question IT should ask.
I believe if you set it up correctly, the cloud can be as secure as anything else," says the CTO of a financial services startup. "But we don't want to have to waste time communicating to potential customers that the public cloud is secure. It's a conversation you don't want to have."
As a result, this CTO's company, which had deployed its applications on top of Amazon's Web service offering, is bugging out of the public cloud and into a private co-location facility. While he believes his team can configure the Amazon service to be just as secure as the on-site option, and the cloud's low startup costs and rapid deployment benefits are attractive, he had to ask: Could the model cost us business?
No matter how many times public cloud providers assert--often correctly--that data is well-protected on their servers, they just can't shake the insecurity rap. And that means CIOs need to ask not just whether the cloud makes business sense, but whether their customers will see it that way. They may not: Security tops the list of cloud worries in every InformationWeek Analytics cloud survey we've deployed. In our 2010 Cloud GRC Survey of 518 business technology professionals, for example, respondents who use or plan to use these services are more worried about the cloud leaking information than they are about performance, maturity, vendor lock-in, provider viability, or any other concern.
That doesn't mean businesses are shunning the cloud. Of those respondents who do use or plan to use these providers, within the next two years, 20% say up to half of their IT services will come from the cloud; an additional 45% say a quarter of their IT services could be delivered that way. The benefits, such as lower deployment costs and faster time to market, are just too attractive, particularly in today's business climate of stagnant budgets and staffing uncertainty. Still, your customers have legitimate questions about running applications in the cloud, whether on infrastructure-as-a service (IaaS) or platform-as-a-service (PaaS) environments. IT must help the business be prepared with good answers to the two main questions we raise, and others specific to the product. It may make the difference between winning business and losing confidence.
First, customers will look for assurance that an application that runs on PaaS is as secure as an application that runs behind an on-premises firewall. The answer will normally be "No--unless it is." It's an irritating response, but that's because cloud security is frustrating. Here's the breakdown.
A Web application you develop and deploy in a PaaS environment is no more--and no less--secure than a Web app you develop and deploy yourself. The basic principles of secure application development don't change because of the cloud. "Cross-site scripting is still cross-site scripting. There's not much difference whether it's in-house or PaaS," says Brian Chess, chief scientist and co-founder of Fortify Software, an application security testing company. The upshot? Developers must be trained to write secure software, regardless of where that software runs. Applications must be tested regularly to ensure that the inevitable vulnerabilities are found and remediated. Building and running an application on top of Windows Azure, Google App Engine, or Engine Yard doesn't excuse an organization from following these principles.
However, PaaS does change the picture in a couple of critical ways because of the cloud inheritance issue. That is, your company inherits all the security benefits--and risks--that are present in the provider's infrastructure. If the provider patches critical OS vulnerabilities within 24 hours while it takes your internal IT organization five days, you inherit that benefit. If the provider still has the default vendor passwords enabled on all its switches and routers, that risk now belongs to you, too. The focus for potential PaaS customers should be to weigh those benefits and risks and see which way the scales tip.
Customers also will want to verify what operational controls and practices the provider has in place. But let's be clear: There's only so much information you're going to get, and the level of detail depends on how important a customer you are to the provider. One option generally available is SAS 70, an audit standard to evaluate a service provider's controls. SAS 70 audits come in two versions: Type I and Type II. In a Type I audit, an auditor reports on the controls in place. A Type II audit reports on the controls in place and also includes the auditor's opinion on whether the controls are effective to achieve the provider's stated objectives for the controls.
Many service providers undergo SAS 70 audits and will make the results available to customers and potential customers. For example, in a 2009 InformationWeek report on 12 IaaS providers, nine of them reported that they undergo SAS 70 Type II audits. Another IaaS provider was pursuing its SAS 70 audit at the time of the report.
While a SAS 70 report can be useful for a customer to understand what controls are in place, this mechanism has drawbacks. In particular, providers can specify to the auditor which controls will be examined. If a provider feels that a control isn't up to snuff or doesn't even have a specific control in place, it can put that control outside the purview of the auditor's report. Providers may also choose only to confirm with customers that they underwent the audit, but not share the control objectives, something that should raise red flags. Ensure you understand the limitations of the process, because those limitations will affect your customers' view of the provider's operations.
You have other options as well. When we asked companies using cloud services about how they assess a provider's security controls, the two most popular mechanisms were a customer-created questionnaire and results from a third-party review.
In the short term, small and midsize businesses without the funds for deep infosec expertise may find the cloud offers their customers greater security benefits than they could provide themselves, while larger organizations, particularly those with strong compliance or customization requirements, may want to wait for the market to mature. At least then your fate, and that of your customers, is in your own hands.