The Cloud Security Alliance has published some guidelines to help companies with a quick risk assessment when considering moving to the cloud. This process is not a full risk assessment framework, nor a methodology for determining all your security requirements. It’s a quick method for evaluating your tolerance for moving an asset to various cloud computing models.
(1) Identify the asset for the cloud deployment
At the simplest, assets supported by the cloud fall into two general buckets: (a) Data and (b) Applications/Functions/Processes
We are either moving information into the cloud, or transactions/processing (from partial functions all the way up to full applications). With cloud computing our data and applications don’t need to reside in the same location, and we can even shift only parts of functions to the cloud. For example, we can host our application and data in our own data center, while still outsourcing a portion of its functionality to the cloud through a Platform as a Service.
The first step in evaluating risk for the cloud is to determine exactly what data or function is being considered for the cloud. This should include potential uses of the asset once it moves to the cloud to account for scope creep. Data and transaction volumes are often higher than expected.
(2) Evaluate the asset
The next step is to determine how important the data or function is to the organization. You don’t need to perform a detailed valuation exercise unless your organization has a process for that, but you do need at least a rough assessment of how sensitive an asset is, and how important an application/function/process is.
For each asset, ask the following questions:
1. How would we be harmed if the asset became widely public and widely distributed?
2. How would we be harmed if an employee of our cloud provider accessed the asset?
3. How would we be harmed if the process or function were manipulated by an outsider?
4. How would we be harmed if the process or function failed to provide expected results?
5. How would we be harmed if the information/data were unexpectedly changed?
6. How would we be harmed if the asset were unavailable for a period of time?
Essentially we are assessing confidentiality, integrity, and availability requirements for the asset; and how those are affected if all or part of the asset is handled in the cloud. It’s very similar to assessing a potential outsourcing project, except that with cloud computing we have a wider array of deployment options, including internal models.
(3) Map the asset to potential cloud deployment models
Now we should have an understanding of the asset’s importance. Our next step is to determine which deployment models we are comfortable with. Before we start looking at potential providers, we should know if we can accept the risks implicit to the various deployment models: private, public, community, or hybrid; and hosting scenarios: internal, external, or combined.
For the asset, determine if you are willing to accept the following options:
2. Private, internal/on-premises
3. Private, external (including dedicated or shared infrastructure)
4. Community; taking into account the hosting location, potential service provider, and identification of other community members
5. Hybrid. To effectively evaluate a potential hybrid deployment, you must have in mind at least a rough architecture of where components, functions, and data will reside
At this stage you should have a good idea of your comfort level for transitioning to the cloud, and which deployment models and locations fit your security and risk requirements.
(4) Evaluate potential cloud service models and providers
In this step focus on the degree of control you’ll have at each SPI tier ((SPI refers to Software as a Service, Platform as a Service, or Infrastructure as a Service) to implement any required risk management. If you are evaluating a specific offering, at this point you might switch to a fuller risk assessment.
Your focus will be on the degree of control you have to implement risk mitigations in the different SPI tiers. If you already have specific requirements (e.g., for handling of regulated data) you can include them in the evaluation.
(5) Sketch the potential data flow
And lastly, if you are evaluating a specific deployment option, map out the data flow between your organization, the cloud service, and any customers/other nodes. While most of these steps have been high-level, before making a final decision it’s absolutely essential to understand whether, and how, data can move in and out of the cloud.
You should now understand the importance of what you are considering moving to the cloud, your risk tolerance (at least at a high level), and which combinations of deployment and service models are acceptable. You’ll also have a rough idea of potential exposure points for sensitive information and operations.