Selecting a cloud provider starts with exit planning
by Vladimir Jirasek - Research Director at Cloud Security Alliance UK - Tuesday, 9 July 2013.
Firstly, selecting a cloud provider is no different from choosing any 3rd party vendor for any other service. Yet for some unexplained reasons, company directors have a higher level of trust in a cloud provider than a ďstandardĒ 3rd party vendor. This can be a fatal mistake, especially if the organization hands over key business services to the cloud provider.

It is vital to undertake risk assessment for each business process to highlight what the impact would be if the data and systems were compromised, changed or simply unavailable. In my experience, the management is often overly optimistic in these assessments, especially when calculating the likelihood of a disastrous event.

Perhaps this is part of human nature, as we are often very poor in assessing likelihood of threat generally. They blindly see a way of reducing cost by outsourcing these services to a cloud provider, mistakenly believing that they will do a better job than an in-house IT function! Negotiate hard as if the contract is with a ď3rd party vendorĒ.

Secondly, it is key to formulate an exit plan whether it is a planned exit or due to an abrupt (as in the story above) halt to services. Different cloud service models (IaaS, PaaS, SaaS, SecaaS) have distinct characteristics at a technological level, which ultimately affects how a company transfers these services from one cloud provider to another, or to a companyís own datacentre.

Infrastructure as a Service (IaaS) is seen as the easiest to migrate while Software as a Service (SaaS) can prove extremely difficult, costly or even impossible. This aspect should always be added to the base business case before deciding whether to use a cloud service. Sadly, this does not happen often, and in many cases future CIOs pick up the bill for previous incumbentís lax approach. Plan for migration from the cloud provider and be pessimistic about the difficulty of the migration.

Finally, the creation and testing of incident response plans is critical in mitigating abrupt service interruptions. I strongly suggest testing these plans on annual basis, perhaps more often for very critical operational services. Effort spent in running test scenarios will significantly decrease time to recover during actual incident, as well as stress levels of everyone involved.

Issues will be uncovered and risk will be significantly reduced. One of the key components to be included in the plan is a list of contact numbers for those cloud providerís key personnel involved in incident resolution. Reliance on email or a web based ticket management system will add to the time for resolving the issue and the former can be useless if the mail service has gone down. I donít know about you, but I do not like waiting for an email response when in a stressful situation. Test, Retest and test again the incident response.

In the fictitious story I have presented a scenario that can certainly happen to anyone. Disasters happen, often without notice or forewarning. We can, however, be prepared and minimize the impact of the cloud providerís unavailability, poor service, migration between providers or moving out of the cloud altogether. Review your existing service provider contract now and do take the time to read the Cloud Security Alliance Guide.


Harnessing artificial intelligence to build an army of virtual analysts

PatternEx, a startup that gathered a team of AI researcher from MIT CSAIL as well as security and distributed systems experts, is poised to shake up things in the user and entity behavior analytics market.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Tue, Feb 9th