By Brian Moran & William Giandoni
Monday, May 16, 2011

Printer Friendly Version

In our rapid march toward a “cloudy” government, we must quickly identify, evaluate, and mitigate the unique risks presented by moving systems to the Cloud. Although GSA continues to work hard to reduce each federal agency’s security burden by way of Authorizing and Assessing (A&A) Cloud Service Providers through FedRAMP – the FedRAMP program still remains under development. In the meantime, agencies must have three systems migrated to the cloud within the next 18 months. The questions are, how does an agency migrate to the Cloud while maintaining the integrity of their systems before providers have completed the FedRAMP A&A process and how can an agency be sure the provider it chooses is a safe bet? There is a lot of great information on this topic and this article is intended to consolidate much of it through a summarized step-wise process for evaluating Cloud Service Providers (CSP), from a security perspective.

As you know, Clouds are complex systems and the various approaches create new risks. This article will not explicitly dissect all of the risks (most of them are covered in our framework and we don’t have space in a short article to expound on each of the risks) but several other organizations do a great job with it including NIST in Draft SP 800-144 Guidelines on Security and Privacy in Public Cloud Computing (pages 13 to 30, http://csrc.nist.gov/publications/drafts/800-144/Draft-SP-800-144_cloud-...) and Cloud Security Alliance in Security Guidance for Critical Areas of Focus in Cloud Computing V2.1(https://cloudsecurityalliance.org/csaguide.pdf ). The risks have a lot of variability, some are derived from the fact that most Cloud-approaches host in a multi-tenancy environment (multiple customers residing on shared equipment), some are related to the reality that providers have varying abilities to log access and system use that can allow you to view and audit the logs. The variability of CSP implementations for similar services alone makes evaluating providers a daunting process. Add to that the newness of the technologies, continual advancements of CSP technologies and the varying levels of CSP’s maturity in operating in a government environment, and you have an evaluation process that is more complex than traditional hosting scenarios.

When we were first tasked with evaluating a providers’ ability to meet FISMA requirements, we thought that given our experience with C&As/A&As, and our internal experience with Cloud services, we could answer the question with ease. But after some thought and research, we quickly realized the question is extremely complex, hence FedRAMP’s lengthy ramp-up. As we do with the evaluation of any solution, we gathered up all of the available research and pruned it for what we consider the most relevant in supporting Cloud evaluations.

The remainder of this article will walk through a summary of our consolidated process for evaluating CSPs and provide a link to our assessment framework. What we assembled is an evaluation process that is anchored in the NIST Risk Management Framework (RMF) but augmented to address the unique aspects of the Cloud. As most seasoned IT security folks who are reading this will realize, we’ve modified the RMF somewhat. Therefore, we only glaze over the unchanged components of the NIST RMF, since we wanted to lay the majority of our focus on the necessary extensions to the RMF and the distillation of the other research items.

The following are the basic steps necessary for performing an evaluation:
1. Evaluate/re-evaluate and categorize systems;
2. Select applicable CSP controls;
3. Assess CSP compliance with controls;
4. Develop compensation and mitigation strategies for non-covered controls; and
5. Assess risk tolerance.

Step 1: Evaluate/re-evaluate and categorize systems
As you know, the outcome of the process will result in a system that is categorized (in accordance with FIPS 199) as a low, moderate, or high system, which ultimately drives the control requirements. We won’t go into detail on this but for more details on completing the evaluation/categorization step, visit FIPS Publication 199, Standards for Security Categorization of Federal Information and Information
Systems, (http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf).

Step 2: Select applicable CSP controls
Once the categorization process is complete, the agency can begin selecting controls against which the CSPs will be evaluated. These controls should reflect the delivery model selected for the solution (SaaS), PaaS, or IaaS). To aid in evaluating CSPs, we assembled a matrix of controls derived from a host of available literature, which is sourced in the matrix. We also added controls for which we felt coverage was necessary in evaluating the providers.

See our CSP evaluation controls matrix at http://www.governmentcio.com/CSPevalmatrix.xlsx .

Step 3: Assess CSP controls
In many ways, when a Major Application (MA) is architected in the Cloud it operates like a MA that inherits its controls from an internally hosted General Support System (GSS). Therefore, before you even consider moving the system into a CSP, you need to evaluate its control coverage and monitor those controls like you would if you those controls were inherited from the GSS.

Once the evaluation controls are selected to assess the CSP in Step 2, you must test the controls. The most cost-effective approach in evaluating CSPs is to leverage what’s been performed by other organizations. If the Cloud provider has been operating in the federal space, they will have reference implementations that have completed the C&A/A&A process. Acquire those test results and evaluate their coverage accordingly. However, just because someone else has evaluated and accepted controls, you still have the responsibility to evaluate the controls yourself. Due diligence is necessary and if you feel coverage for a control is questionable you need to double-check, re-test, or inspect the evidence that the control is covered for yourself. You are ultimately responsible for accepting risk. If someone else says it’s covered and it turns out that the control is not covered, you and you’re agency will be held accountable.

Each system is unique and the framework only provides a set of common evaluation criteria. You must balance the controls against the unique requirements of your system to determine if your system is appropriate for deployment to a particular provider, taking into account all the provider’s assessed risks and benefits. Once you’ve determined the providers’ ability to satisfy the majority of controls to your accepted level of risk, you need to address those uncovered risks.

Step 4: Develop compensation and mitigation strategies for non-covered controls
If after evaluating providers’ controls, some remain uncovered and you cannot accept the risk, you need to develop mitigation strategies. Those strategies must compensate for the intolerable residual risk for which you are unwilling to accept.

As taken from NIST SP 800-18, compensating controls are:

“ …the management, operational, or technical controls employed by an agency in lieu of prescribed controls in the low, moderate, or high security control baselines, which provide equivalent or comparable protection for an information system. Compensating security controls for an information system will be employed by an agency only under the following conditions: (i) the agency selects the compensating controls from the security control catalog in NIST SP 800-53; (ii) the agency provides a complete and convincing rationale and justification for how the compensating controls provide an equivalent security capability or level of protection for the information system; and (iii) the agency assesses and formally accepts the risk associated with employing the compensating controls in the information system. The use of compensating security controls must be reviewed, documented in the system security plan, and approved by the authorizing official for the information system.”

Step 5. Assess final risk tolerance
After the mitigation and compensation strategies are fully developed, re-assess the potential effect to see whether the effort would really make enough of a change in the residual risk. The important factor is that the strategies reduce the risks to a level your organization finds acceptable. This level of acceptability is driven by your organization’s sensitivity to each of the residual risks as it relates to mission and business functions.

We hope you now have insight and some tools necessary to help you migrate to the Cloud while maintaining the integrity of your agency’s systems before providers have completed the FedRAMP A&A process. As we said at the beginning, this article is meant to be a summary of some of the great information available and also provide some insight into the steps required for evaluating CSPs. As you’ll notice, even the assessment matrix, for which we provide a link, is still high-level. Behind each control are test steps for evaluation of the efficacy of the controls.

For questions, contact Brian Moran at bmoran@governmentcio.com or William Giandoni at wgiandoni@governmentcio.com or leave your comment below.