Cisco Blogs

Cloud Computing: Not a Security Panacea

October 21, 2009 - 0 Comments

The Microsoft Sidekick data loss was a pretty big story over the last week or two; for a while, Microsoft was predicting a total loss of all data, although by October 15, things seemed to start looking better in that department. Some have already discussed whether this failure should be used to represent cloud computing entirely. (To get it out of the way now — no, it shouldn’t.) But there remains a gap in expectations and some level of assumptions about what cloud computing has to offer.

One key difference here is that the concept of cloud computing must remain separate from the concept of hosted services. In Microsoft’s case, the Sidekick failure was in what has been described as a traditional hosted environment. But from a consumer perspective, especially for paying customers, there is an expectation of backup and resiliency when all of the data and much of the device functionality is under the control of the vendor. At this point, the security requirements of that data becomes more clarified: what will be the acceptable losses for this customer information, and what costs will be acceptable for preventing those losses?

Yet under a cloud computing model, Microsoft would not necessarily have found themselves in a situation that would have withstood the data loss they experienced. The key here is that cloud computing allows for scalability based upon usage; an organization could increase or decrease their use of computing infrastructure (and consequently cost, maintenance, etc.) based upon need. Yet if the organization implements a cloud architecture for scalability only, resiliency isn’t necessarily improved.

This is evident from the Facebook server failure that was also reported last week. Facebook utilizes a cloud architecture to serve their content, but 150,000 users lost recent settings and data from posts during the outage period. Facebook’s architecture did not make it immune to this loss, so simply employing cloud structure in one area does not exempt an organization from data loss.

But can cloud computing increase resiliency? Certainly, similar to scaling up availability, workload can be distributed to other hosts and scaled around the failed device if it is detected. The fact that this was not employed by Facebook does not speak negatively about the cloud, but simply exists as a design decision made by the company. Immediate failover and resiliency in the cloud is either not a part of their operations plan at this time, or their plan for that resiliency did not succeed — my guess is that the former is true, but that’s just a guess.

What remains to be seen is whether consumer expectation and assumptions about the nature of cloud computing can be satisfied by companies that only offer hosted services, or those that do not include cost-prohibitive design decisions. How services choose to allocate their funding and resources will certainly vary. What the cloud allows is for an organization to be extremely flexible, and not locked into an infrastructure or architecture that has consistent usage, or if utilizing a multi-tenant cloud, not locked into bearing the full cost for that infrastructure.

Services will continue to make infrastructure choices, either with or without cloud capabilities, and these same services will continue to make choices for or against reliability, scalability, and security to meet their needs. As organizations plan to build their own cloud services, or to employ cloud-based services from a third party, they will need to understand just which cloud capabilities are being employed, and what service levels they can expect. Ultimately, the technological benefits of cloud computing are neither a cure-all nor a required, inflexible set. With a greater understanding about cloud computing will come a more realistic set of expectations, which in turn will aid security decisions and how cloud computing will affect (positively or negatively) the cost of ensuring confidentiality, integrity, and availability.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.