In general, the agenda for the presentation is to dispel some of the myths associated with cloud computing hype. The presentation will cover how the risks of cloud computing are not as obvious as they seem—some risks get too much attention, some don't get enough—and will also cover some of the risks that can be mitigated by a move to cloud computing. Finally, we will cover some of the approaches to mitigating risk, including the risk management model, and certification.
Cloud computing has attracted a considerable amount of hype recently, and continues to do so. The Gartner Hype Cycle from 2010 shows &quot;Cloud Computing&quot; just beyond the &quot;Peak of Inflated Expectations.&quot; Although positive hype is nothing unusual for new technologies, negative hype—specifically about the risks of cloud computing—is potentially more damaging and needs to be addressed.
Coverage in February 2010 of a Department of Finance memo warning public sector bodies not to purchase cloud computing services. Whilst this was really just good advice—don't embark on something new unless you have dealt with the issues—much of the coverage interpreted it as a dire warning of the risks of cloud computing.
Science fiction author Theodore Sturgeon (http://en.wikipedia.org/wiki/Theodore_Sturgeon) originated what has since become known (in science fiction circles at least) as Sturgeon's Law. He found he was frequently defending the genre from people citing examples of trashy pulp sci-fi as &quot;evidence&quot; that 90% of science fiction—and thus the genre itself—was rubbish. He argued that, in his own words: of course 90% of science fiction is &quot;crud&quot; — &quot;90% of everything is crud&quot;. His point of course was that just because science fiction is an easily identifiable genre of fiction, it's easy to 'tar it all with the same brush'. Likewise for cloud computing—an easily identifiable genre of technology—just because much of it is risky doesn't mean it should all be dismissed. There is nothing inherently risky about outsourcing critical processes—finance departments have been doing it for years, for example to shared service centres within or outside their own company. Just because the risks related to cloud computing are different to what we may be used to, does not mean that they are worse .
We need to be aware of the appropriate perspective from which to view our risks—as a general rule, one person's risk is another person's opportunity. It's easy to work out the major risk from the cloud service provider's perspective—it's the commercial risk of not enough customers paying enough for your cloud services. We can take that for granted, and look at it from the customer's perspective, where in general terms, a risk is not just some theoretical &quot;adverse event&quot; but, in very real terms, anything that can adversely affect the achievement of the customer's business goals. Obviously the service provider needs to focus on the customer's perception of risk.
This is an example of what I call a &quot;red herring&quot; risk. Data protection is seen as being much riskier when you move beyond the perceived safety of the relatively strong legislative framework in the EU. Although it is indeed true that the EU (and a small number of other jurisdictions) have stronger data protection legislation than most of the rest of the world, the protection provided by legislation is largely illusory. Mitigating data protection risk is almost entirely a behavioural issue, with behavioural solutions (policies, procedures, training, communication, restricting potentially risky practices, etc). There are huge data protection issues in any jurisdiction, regardless of how good the legislation is.
The above are a number of examples of risks that increase when you move to a cloud environment. Most are self-explanatory; a few need more explanation. Contingency bandwidth is not the same as peak bandwidth—it means the bandwidth required in exceptional circumstances, such as re-uploading a month's worth of transactions to resolve a database corruption issue, or restoring your data from the cloud archiving solution you use. The migration point relates to the safeguards that should be in place if you decide to terminate your contract with a cloud service provider—do they make it easy to get the data back out again? As easy as it was when you were signing up? Forensic issues relate to whether you have sufficient access to the cloud systems in the event that you need to perform a forensic investigation. Regarding general security issues—the use of security testing (e.g. penetration tests) is a common control, but cloud service providers may be very reluctant to allow customers to attempt to hack their systems, requiring a rethink and a different approach. Unfortunately, not all of the above get the attention they deserve.
The often overlooked point is that there are some risks that are greater when you stick with a non-cloud &quot;solution.&quot; Having your infrastructure and apps in-house, managed by your own team that only deals with your company means that you don't have the levels of objectivity, economies of scale and contractual guarantees that you should (although may not always) have with a cloud service provider.
There is no &quot;one-size-fits-all&quot; solution to managing risk—it all depends on your organisation. However, the approach to identifying, managing and mitigating risks should be consistent across an organisation. &quot;Cloud risks&quot; don't deserve special treatment; nor do &quot;IT risks&quot;. A &quot;risk&quot; is either a risk to the achievement of the organisation's strategic objectives, or it isn't. The response should be commensurate with the magnitude of the risk, i.e. impact x likelihood.
This is the overall risk management cycle consists of three major steps: Risks are identified Controls are put in place to mitigate the risks Auditing (internal, external, compliance reviews, security reviews, etc) provides assurance that controls are working and risks are being mitigated It's important to note that there must be a correlation between controls and risk . It doesn't have to be a 1:1 correlation—you can have a single control that mitigates multiple risks, or a single risk that requires multiple controls to mitigate it effectively. The crucial points are that: Every risk must have control(s) that mitigate it effectively Every control must be there to mitigate specific risk(s)—otherwise it's a waste of resources