If Security in the Cloud Were Handled Like Car Accidents

Though responsibility for taking precautions may be shared, the risk of an incident is always yours and yours alone, no matter who is driving the car.

Cloud and security still take top billing in many discussions today, perhaps because of the nebulous nature of the topic. If we break down security concerns in a public cloud computing environment we can separate them into three distinct categories of risk – the infrastructure, the application, and the management framework. Regardless of the model – IaaS, PaaS, SaaS – these categories exist as discrete entities, the differences being only in what the customer has access to and ultimately over which they have control (responsibility).

A Ponemon study recently reported on by InformationWeek (Cloud Vendors Punt to Security Users ) shows a vastly different view of responsibility as it pertains to cloud computing and data security. Whether it is shared, mostly on the provider or mostly on the customer is a matter of perspective apparently but is just as likely the result of failing to distinguish between categories of security concerns. Regardless of the category, however, if we apply a couple of legal concepts used to determine “fault” in car accidents in many states, we may find some interesting comparisons and insights into just who is responsible – and for what – when it comes to security in a public cloud computing environment.

A MATTER of NEGLIGENCE

Legalese is legalese, no matter the industry or vertical, and cloud computing is no exception. As noted in the aforementioned InformationWeek article:

"When you read the licensing agreements for cloud providers, they don't need to do anything with security--they take 'best effort,'" said Pironti [John P. Pironti, president of IP Architects]. Best effort means that should a case come to court, "as long as they can show they're doing some effort, and not gross negligence, then they're covering themselves."

In other words, providers are accepting that they have some level of responsibility in providing for security of their environments. They cannot disregard the need nor their responsibility for security of their environments, and by law they cannot disregard such efforts below a reasonable standard of effort. Reasonable being defined by what a reasonable person would consider the appropriate level of effort. One would assume, then, that providers are, in fact, sharing the responsibility of securing their environments by exerting at least ‘best effort’. A reasonable person would assume that best efforts would be comparable to those taken by any organization with a public-facing infrastructure, i.e. firewalls, DoS protection, notification systems and reasonable identity and access management policies.

Now if we treated cloud computing environments as we do cars, we might use a more granular definitions of negligence. If we look at those definitions, it may be that we can find the lines of demarcation for security responsibilities in cloud computing environments.

Contributory negligence is a system of fault in which the injured party can only obtain compensation for injuries and damages if he or she did not contribute to the accident in any way.

In comparative negligence, the injured party can recover damages even if she was partially at fault in causing the accident. In a pure comparative system, the plaintiff’s award is reduced by the amount of her fault in the accident. Some states have what is called modified comparative fault. This is where there is a cap on how much responsibility the injured party can have in the accident.

-- Car Accident Fault and Getting What You’re Owed

In a nutshell, when it comes to car accidents “fault” is determined by the contribution to the accident which subsequently determines whether or not compensation is due. If Alice did not fulfill her responsibility to stop at the stop sign but Bob also abdicated his responsibility to obey the speed limit and the two subsequently crash, one would likely assume both contributed to the incident although with varying degrees of negligence and therefore fault. Similarly if Alice has fulfilled all her responsibilities and done no wrong, then if Bob barrels into her it is wholly his fault having failed his responsibilities. The same concepts can certainly be applied to security and breaches, with the focus being on the contribution of each party (provider and customer) to the security incident.

Using such a model, we can determine responsibility based on the ability to contribute to a incident. For example, a customer has no control over the network and management framework of an IaaS provider. The customer has no authority to modify, change or configure network infrastructure to ensure an agreeable level of network-security suitable for public-facing applications. Only the provider has the means by which such assurances can be made through policy enforcement and critical evaluation of traffic. Alice cannot control Bob’s speed, and therefore if it is Bob’s speed that causes an accident, the fault logically falls on Bob’s shoulders – wholly. If data security in a cloud computing environment is breached through the exploitation or manipulation of infrastructure and management components wholly under the control of the provider, then the fault for the breach falls solely on the shoulders of the provider. If, however, a breach is enabled by poor coding practices or configuration of application infrastructure which is wholly under the control of the customer, then the customer bears the burden of fault and not the provider.

IT ALWAYS COMES BACK to CONTROL

In almost all cases, a simple test of contributory negligence would allow providers and customers alike to not only determine the ability to contribute to a breach but subsequently who, therefore, bears the responsibility for security. It is an unreasonable notion to claim that a customer – who can neither change, modify nor otherwise impact the security of a network switch should be responsible for its security. Conversely, it is wholly unreasonable to claim that a provider should bear the burden of responsibility for securing an application – one which the provider had no input or control over whatsoever.

It is also unreasonable to think that providers, though afforded such a luxury by their licensing agreements, are not already aware of such divisions of responsibility and that they are not taking the appropriate ‘best effort’ steps to meet that obligation. The differences in the Ponemon study regarding responsibility for security can almost certainly be explained by applying the standards of contributory negligence. Neither provider nor customer is attempting to abrogate responsibility, in fact all are clearly indicating varying levels of contribution to security responsibility, almost certainly in equal portions as would be assigned based on a contributory negligence model of fault for their specific cloud computing model. Customers of IaaS, for example, would necessarily assign providers less responsibility than that of an SaaS provider with regard to security because providers are responsible for varying degrees of moving parts across the models. In a SaaS environment the provider assumes much more responsibility for security because they have control over most of the environment. In an IaaS environment, however, the situation is exactly reversed. In terms of driving on the roads, it’s the difference between getting on a bus (SaaS) and driving your own car (IaaS). The degree to which you are responsible for the security of the environment differs based on the model you choose to leverage – on the control you have over the security precautions.

Ultimately, the data is yours; it is your responsibility to see it secured and the risk of a breach is wholly yours. If you choose to delegate – implicitly or explicitly - portions of the security responsibility to an external party, like the driver of a car service, then you are accepting that the third party has taken acceptable reasonable precautions. If the risk is that a provider’s “best effort” is not reasonable in your opinion, as it relates to your data, then the choice is obvious: you find a different provider. The end result may be that only your own environment is “safe” enough for your applications and data, given the level of risk you are willing to bear.