Survey after survey note that security is the biggest concern potential users have with respect to public cloud computing. Here, for example, is a survey from April 2010, indicating that 45 percent of respondents felt the risks of cloud computing outweigh its benefits. CA and the Ponemon Institute conducted a surveyand found similar concerns. But they also found that deployment had occurred despite these worries. And similar surveys and results continue to be published, indicating the mistrust about security persists.
Most of the concerns voiced about cloud computing relate to the public variant, of course. IT practitioners throughout the world consistently raise the same issues about using a public cloud service provider (CSP). For example, this week I am in Taiwan and yesterday gave an address to the Taiwan Cloud SIG. Over 250 people attended, and, predictably enough, the first question addressed to me was, "Is public cloud computing secure enough, and shouldn't I use a private cloud to avoid any security concerns?" People everywhere, it seems, feel that public CSPs are not to be trusted.
However, framing the cloud security discussion as a "public cloud insecure, private cloud secure" formula indicates an overly simplistic characterization. Put simply there are two big lies (or, more charitably, two fundamental misapprehensions) in this viewpoint, both rooted in the radical changes this new mode of computing forces on security products and practices.
Cloud Security Lie #1
The first big lie is that private cloud computing is, by definition, secure merely by way of the fact that it is deployed within the boundaries of a company's own data center. This misunderstanding arises from the fact that cloud computing contains two key differences from traditional computing: virtualization and dynamism.
The first difference is that cloud computing's technological foundation is based on the presence of a hypervisor, which has the effect of insulating computing (and the accompanying security threats) from one of the traditional tools of security: examining network traffic for inappropriate or malicious packets. Because virtual machines residing on the same server can communicate completely via traffic within the hypervisor, packets can be sent from one machine to another without ever hitting a physical network, which is where security appliances are typically installed to examine traffic.
Crucially, this means that if one virtual machine is compromised, it can send dangerous traffic to another without the typical organizational protective measures even being involved. In other words, one insecure application can communicate attacks to another without the organization's security measures ever having a chance to come into play. Just because an organization's apps reside inside a private cloud does not protect it against this security issue.
Of course, one might point out that this issue is present with vanilla virtualization, without any aspect of cloud computing being involved. That observation is correct. Cloud computing represents the marriage of virtualization with automation, and it's in this second element that another security shortcoming of private clouds emerges.
Cloud computing applications benefit from this automation to achieve agility and elasticity--the ability to respond to changing application conditions by moving virtual machines quickly and by spinning up additional virtual machines to manage changing load patterns. This means that new instances come online within just a few minutes without any manual interaction. This implies that any necessary software installation or configuration must also be automated so that when the new instance joins the existing application pool it can immediately be used as a resource.
It also implies that any required security software must, likewise, be automatically installed and configured without human interaction. Unfortunately, many organizations rely on security personnel or system administrators to manually install and configure necessary security components--often as a second step after the rest of the machine's software components are installed and configured.
In other words, many organizations have a mismatch between their security practices and the reality of what a cloud requires. Assuming that a private cloud is, ipso facto, secure, is incorrect. Until your security and infrastructure practices align along automated instantiation, you have a vulnerability.
Moreover, it's critical to get them aligned. Otherwise, you face the likelihood that your application automation will outstrip your security practices, which is not a good situation. For sure, one would not like to be in the position of trying to explain why the supposedly-secure private cloud ended up exposing a vulnerability because the automation characteristics of cloud computing had not been extended through all parts of the software infrastructure.
So, the first big lie about cloud computing is that private clouds are inherently secure. What is the second?
Cloud Security Lie #2
The second lie about cloud computing security relates to assumptions about public cloud security; specifically, the assumption that security in public cloud computing rests solely with the CSP. The reality is that security in a service provider world is a responsibility shared between the provider and the user, with the former responsible for security in the infrastructure up through the interface point between application and hosting environment, and the user responsible for security with respect to interfacing with the environment, and importantly, within the application itself.
Failing to configure the application properly with respect to the environment security interface or failing to take appropriate application-level security precautions exposes the user to issues for which no provider can possibly be expected to take responsibility.
Let me provide an example. One company we worked with had placed its core application in Amazon Web Services (AWS). Unfortunately, it had not implemented appropriate security practices with respect to how it used AWS security mechanisms, nor with simple application design issues.
Amazon provides what is, in effect, a virtual machine-level firewall (called a Security Group) which one configures to allow packets to access specific ports. The best practice with respect to Security Groups is to partition them, so that very fine-grained port access is available per virtual machine. This ensures that only traffic appropriate for that type of machine goes to an instance. For example, web server virtual machines are configured to allow traffic on port 80 into the instance, while database virtual machines are configured to disallow traffic on port 80 into the instance. This blocks attacks on database instances (containing crucial application data) from the outside using web traffic.
To construct a secure application, one must use Security Groups properly. This organization had not. It used one Security Group for all traffic to all instances, which meant that every type of instance was exposed to any type of traffic destined for any instance. Clearly, a poor use of AWS security mechanisms.
Regarding the organization's application itself, it had implemented poor security practices. Instead of partitioning application code among different types of machines, it had loaded all application code into a single instance, which meant the same instance that received traffic for its corporate website also had code containing proprietary algorithms running on it as well.
The important fact about this situation: If this organization assumed that all security responsibility lay with the CSP (Amazon Web Services, in this case), it would be extremely negligent, because it had not taken important steps to address security issues for which no CSP could be responsible. This is what shared responsibility implies--both parties have to step up to the security aspects in their control, and failing to do so means the application is not going to be secure. Even if the CSP does everything correctly for portions of the cloud application within its control, if the application owner fails to implement its security responsibility correctly, the application is going to be insecure.
I have been in meetings with security personnel discussing security about public CSPs, who refused to consider their company's responsibility in these environments, insisting on redirecting every security topic back to concerns about the CSP's responsibility.
This struck me, frankly, as reckless, as it insinuated a refusal to seriously grapple with the necessary work of creating as secure a public CSP-based application as possible. It was as if the very attitude that all security responsibility lay with the CSP insulated the security person, and by extension, his company, from any liability for security failures in an application running in a CSP environment. It may not come as a surprise that the individual in question was a staunch advocate of private clouds, asserting their far superior inherent security.
The reality is that organizations are increasingly going to deploy applications in public CSP environments. It is vital that security groups step forward to ensure their organizations take every step possible to implement applications that are as secure as possible, and that means what steps the organization itself needs to take in that regard.
Security is, so to speak, the third rail of cloud computing. It is constantly cited as an inherent benefit of private clouds and a fundamental shortcoming of public cloud computing. Actually, the truth is far more ambiguous than these positions imply. Asserting the putative security shortcomings of public cloud environments without seriously considering how to mitigate them seems irresponsible and evidence of a belief that assertion implies dismissal with no further need to investigate mitigation techniques.
A poorly managed and configured private cloud application can be quite vulnerable, and a properly managed and configured public cloud application can achieve very good security. Characterizing the situation as black and white is simplistic and does a disservice to the discussion.
Far more productive in both environments is to query what actions must be taken to achieve as secure an application as possible, within the constraints of time, budget, and risk tolerance. Security is never a question of black or white, but rather a question of how light a shade of gray is possible, given the particulars of a specific environment and application. Failing to acknowledge that does a disservice to the topic and to how best to ensure an organization's infrastructure is as efficient and cost-effective as possible.
