This tip is a part of the SearchCloudSecurity.com learning guide, Cloud computing risk management: Assessing key...
risks of cloud computing.
In almost any other context, the relatively short April 21 outage of Amazon’s EC2 service would have been a non-issue. After all, data centers go dark, services go down, hosts become nonresponsive -- all these things happen every day and the earth keeps turning. Even “5 nines” of uptime still implies some downtime (small though that period would be in that case).
In the case of Amazon though, the situation didn’t go unnoticed. Because of the number of customers impacted -- and the high-visibility nature of the websites that suffered outages as a result -- the situation at Amazon has been labeled by some as one of the biggest outages of all time. Some even call it the “cloudpocolypse.” In other words, because of the concentrated nature of the service, the impact was disproportionately high.
This illustrates an important point about cloud services generally, and risk dynamics in the cloud specifically: Risk -- under a cloud paradigm -- tends to concentrate, centralize and distill. In other words, as services become more concentrated, so does the risk. Paradoxically, the same forces that drive cloud to be beneficial on the one hand -- leading to economies of scale in support and technical management -- can also potentially have a downside when it comes to concentration of risk.
Enterprises looking to move services to the cloud must understand and account for this change in risk and adjust their security programs accordingly for cloud risk management and business continuity planning.
Why aggregation is a double-edged sword
One of the key promises of cloud has to do with realizing benefits through aggregation: Specifically, through consolidation of services in the environment. The theory is, by implementing a given service once and allowing multiple entities to leverage that service, you realize economies of scale: Services become cheaper and quality improves because you can have centralized, specialized expertise. The promise is you’ll get more at a lower cost.
But aggregation also means consolidation of risk as well; for example, as larger numbers of clients depend on a centrally implemented service, that service can become a single point of failure or attack. This is true whether you’re talking about data center consolidation, consolidation of network pathways, or consolidation of platforms (for example through virtualization). As you concentrate services more densely, your risk becomes denser as well. Consider for example a legacy infrastructure with close to a one-to-one relationship between services (meaning, one service sits on one host). What happens when you lose one physical host? You lose one service, right? But what if that host is a hypervisor? What if it’s a SaaS service that supports dozens of clients? See the issue?
In the cloud, “ripples” in service that might have been relatively minor or even unnoticed under a “traditional” (less dense) IT model, now can have much more amplified impact when fewer singular points are used to support a larger population of services.
Account for changed risks
Enterprises that take cloud seriously need to take steps to account for these changing risk dynamics as they consolidate, virtualize, and re-architect their technology infrastructure. Specifically, anywhere the organization has made determinations about risk -- and impacts to the business derived from that risk -- should be revisited as the organization moves to the cloud. While this is quite a bit of work, it’s necessary because decisions based on assumptions that are no longer valid are dangerous.
The most critical task for organizations looking to respond systematically and plan appropriately for shifting risk is to allocate time in the cloud transition process to revisit decisions made about risk in the past – and to ensure those decisions still make sense in light of the changing environment. There are a few notable areas to look at: specifically, business continuity planning (BCP) and risk management/mitigation.
Business continuity strategies are always based on risk to the business. This is typically evaluated formally by means of a business impact assessment (BIA) that serves to identify, catalogue and document impact associated with loss of a particular process or supporting element within a process. At the very highest levels, business processes may appear unchanged after a cloud migration, but once you start digging into the dependency chain, changes are more likely to become clear.
For example, a particular critical application may now be a SaaS component instead of being hosted on a server in the data center. So instead of having a dependency on continued functionality of the data center, that dependency shifts to the vendor. In some cases, the net/net will be the same; in other cases, it introduces dependencies (like connectivity to the vendor in question) that may not have been accounted for in original DR assumptions. The point is: If you’re moving to the cloud, sooner is better than later to systematically re-evaluate your business impacts and revisit your BCP and DR strategies.
From a cloud risk management standpoint, it behooves organizations to revisit the controls they’ve selected, where they’ve placed those controls, and (most importantly) those controls they’ve elected not to implement because the original risks did not necessitate them. Control selection, whether done formally or informally, is again dependent on business risk, with the goal of investing in mitigating only the risks that a particular organization has. If you’ve gone through a risk management exercise and implemented security and other controls based on observed risk, you’ll certainly need to revisit those assumptions.