I’ve been working with the Cloud Security Alliance on the next revision of their official Security Guidance document, and we decided to include a short note on risk in the beginning, to help add some context. Although we are deep in the editorial process, I realized this is the sort of thing I should put out for some public comment, as it’s at the beginning of the document and will help frame how it’s read.

With so many different cloud deployment options – including SaaS vs. PaaS vs. IaaS, public vs. private, internal vs. external, and various hybrid scenarios – no list of security controls can cover all circumstances. As with any security area, organizations should adopt a risk-based approach to moving to the cloud and selecting security options. The following is a simple framework to help evaluate initial cloud risks and inform security decisions.

This process is not a full risk assessment framework, nor a methodology for determining all your security requirements. It’s a quick mechanism for evaluating your tolerance for moving an asset to various different cloud computing models. There is a full section on risk management in the Guidance, and I’m also working on a data security specific post to mesh with the other cloud data security content I’m developing.

Identify the asset for the cloud deployment

At the simplest, assets supported by the cloud fall into two general buckets:

  1. Data
  2. 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, and cloud deployments often scale higher than anticipated.

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 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 was 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 was unexpectedly changed?
  6. How would we be harmed if the asset was 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 also have a wider array of deployment options including internal models.

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 internal vs. external options.

For the asset, determine if you are willing to accept the following options:

  1. Public.
  2. Private, internal/on-premises.
  3. Private, external (including dedicated or shared infrastructure).
  4. Community; taking into account the hosting location, service provider, and identification of other community members.
  5. Hybrid. To effectively evaluate a potential hybrid deployment, you must to have 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 best fit your security and risk requirements.

Evaluate potential cloud service models

In this step focus on the degree of control you’ll have at each SPI tier (Software, Platform, 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 PCI regulated data) you can include them in the evaluation.

Sketch the potential data flow

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.

If you have yet to decide on a particular offering, you’ll want to sketch out the rough data flow for any options on your acceptable list. This is to insure that as you make final decisions, you’ll be able to identify risk exposure points.

Document Conclusions

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.

These together should give you sufficient context to evaluate any other security controls. For low-value assets you don’t need the same level of security controls and can skip many of the recommendations – such as on-site inspections, discoverability, and complex encryption schemes. A high-value regulated asset might entail audit and data retention requirements. For another high-value asset not subject to regulatory restrictions, you might focus more on technical security controls.

Not all cloud deployments need every possible security and risk control. Spending a little time up front evaluating your risk tolerance and potential exposures will provide the context you need to pick and choose the best options for your organization and deployment.

Share: