Risk Management

Most companies will experience a data breach in one form or another within the next few years. The relative estimates of the impacted organizations every year, vary greatly depending on the source of information used, but most fall within the range of between 40% and 60%. When this inevitable breach does occur, it can have devastating consequences for a company’s finances and reputation. Traditional Risk Management strategies consider the financial impact and the likelihood of occurrence, to address identified risks. This usually leads to following four options for cloud security managers to mitigate these risks.

  • Mitigate the risk (For instance if the cost of the control is lower than the potential losses)
  • Avoid the risk (This often covers risk with a very high financial impact and high likelihood of occurrence)
  • Accept the risk (The organization decides not to implement controls for various reasons, including cost effectiveness)
  • Transfer the risk (Usually to a 3rd party insurance)

Compensation from a responsible 3rd party service provider, however, is not always considered. Especially within a full or hybrid cloud configuration, this option will need to be investigated. What happens if the cloud platform itself is breached, providing access to and even across customer data?

Security Incident Compensation

Most documented Security Incident Compensation cases cover Personal Information Leaks such as the 2014 Sony Pictures and the 2015 TalkTalk breaches. In this type of case, Personal Information is leaked, and the responsible organization offers a monetary compensation before or after a legal battle to compensate the users of their systems for their loss of money of privacy. Although a bit more complex, a similar system does exist between companies as well. This is usually covered in Service Level Agreements (SLA) which include a broad range of service metrics and items such as compensation for downtime and data breaches. The main issue with the standard SLA agreements is that in reality, the value of the compensation does not even come close to the significant loss an average breach or outage can cause to an organization. An example is an organisation whose website crashed during Black Friday sales, resulting in a loss of $50 million in revenue. This organization was compensated with a 6-hour service credit worth approximately $300. It is important to negotiate the SLA terms and conditions and to have the right expectations when intending to use compensation as a (partial) risk management option.

Cloud Environment Nuances

To dive deeper into the specifics of a security incident and breach compensation for cloud customers, it is important to understand some key differences between the traditional options.

The main difference is the shift in responsibilities from the customer, towards the Cloud Service Provider. The responsibilities not only cover the infrastructure availability and performance. They also cover part of the security aspect of the service. These responsibilities go further relative to the depth of the cloud adoption level of the customer. For instance, security responsibilities for a Cloud Service provider are higher for an Infrastructure as a Service (IAAS) model than for a Software as a Service (SaaS) model due to the increased exposure and risk of the provided services. The chance of an attacker exploiting the underlying cloud system simply becomes larger because more services are under the control of the Cloud Platform.

Security in cloud platforms is also different from on-premises focused security due to its scale. Mainly larger, more complex networks will be in one way or another migrated to the cloud. Due to this larger complexity, it is harder to keep track of what data actually is stored and what is not stored in that cloud environment. This brings along an increase in risk which should be considered.

The last, but certainly not least important difference is the multi-tenanted environment. Cloud providers are a high-value target due to the possibility to access the systems of many customers at once. Imagine an attacker getting access to for instance the Azure Web Services Platform or inside the Rack Space infrastructure. If that sounds farfetched at this early cloud adaptation stage, also consider an insider attack. Who has vetted the Cloud Service Provider staff and are the vetting processes of the same standards as their customers? This is still a quite unexplored territory.

Ethical Hacking Training – Resources (InfoSec)

Historical Cloud Breaches

Even though it is hard to find any examples of major cross-customer security breaches in cloud environments, more and more security experts are warning about the enormous risks. In 2015, researchers from Worcester Polytechnic Institute claimed to have used their Amazon Web Services Instance to gain access to another AWS Instance on the same machine, which they documented in a rather complex whitepaper. Amazon immediately downplayed the risk and stated that this attack needs “extremely rare, unlikely pre-existing conditions and outdated third-party software” to be present in the targeted EC2 instance. This example does show, however, that just because the data is in the cloud and is possibly encrypted, no system is bulletproof. It is only a matter of time before the first large Cloud-themed security breach hits the media.


Bringing this all together again, it can be concluded that it is of great importance to investigate and agree to a Cloud Security Incident Compensation policy. This is due to the increased exposure and impact of a breach and with that, the increased risk to any organization. Damages from a Private Information Leak or extensive service downtime cannot simply be settled with the traditional SLA Compensation amounts. Damages can run far into the millions of dollars. A few months’ free service simply does not work in that case. An uptime of anything less than 99% on the Azure Application Gateway Cloud Service, for instance, gives the customer a service credit of 25%. Imagine owning a large webstore and dealing with two days of downtime. It would not even be worth a few hours of paperwork to obtain that service credit, especially when dealing with the aftermath of a recent major outage. A major breach can result in far more downtime or even large legal claims. Discussions with the Cloud Service Provider should clarify the available options because these are most likely customised to the customer’s wishes and environment.