Speeding Cloud Adoption Through New FedRAMP Initiative

One major barrier to widespread adoption of cloud computing by the federal government- and a big frustration to vendors and service providers - is the reality that each agency conducts its own risk management assessment when acquiring outsourced IT services. The fact that providers must address literally scores of different sets of security standards is a costly process that slows deployment of new technologies.

But a new federal program being ramped up - the Federal Risk and Authorization Management Program, or FedRAMP - should eliminate that barrier by getting agencies to collaborate on establishing common security standards for the services they contract from vendors, including cloud computing offerings.

"An advantage of this program is that [vendors] primarily work with one security assessment and authorization body, or one risk management program, and they don't have to independently meet all of the security requirements of the many, many different agencies," FedRAMP Vice Chairman Peter Mell said in an interview with GovInfoSecurity.com (transcript below).

"This is common sense," said Mell, who also is a senior computer scientists at the National Institute of Standards and Technology and had led NIST's cloud computing research efforts. "I don't think we are doing anything unexpected or unusual here."

In the interview with GovInfoSecurity.com's Eric Chabrow, Mell explains how FedRAMP:

  • Will work.
  • Should speed adoption of cloud computing within the federal government.
  • Should save agencies money by piggybacking on certifications and accreditation work performed by other agencies.

"We want to reduce duplication of effort, reduce costs, increase security and we believe we can do that through this unified, risk management program," says Mull, who also is a senior computer scientists at the National Institute of Standards and Technology and had led NIST's cloud computing research efforts. "Agencies, by leveraging FedRAMP authorization, will save a lot of money and enable rapid acquisition but they're still in control. They get to choose whether or not they leverage it. They can chose if they want to do additional work to assure systems meet the security needs of their agency."

ERIC CHABROW: Please tell us about the Cloud Computing Advisory Council.

PETER MELL: Certainly. A year ago, Federal CIO Vivek Kendra, when he first came into his position, brought all of the agency CIOs together and said let's do cloud computing, let's move the government forward with the intention to reap great benefits, not just to do cloud, to achieve that cost savings, the transparent government, the power savings, and probably most importantly, to increase IT agility. He got the ball rolling with the agency CIOs and then, over the last year, has developed sort of a cloud organizational chart of different groups, doing different aspects of cloud computing.

There is an executive steering committee composed of the top-level agency CIOs and under that is the Cloud Computing Advisory Council, of which I am the vice chair. I sort of view the council as senior technical people trying to get cloud done in the government and discussions therein.

Under that council, there is a there is a security working group that I chair, which is tasked with resolving any of the security hurdles that the federal cloud initiative may be facing. And so, hopefully today Eric, we can talk about what is that primary hurdle we have identified and what we are moving forward with in solving that issue.

CHABROW: Okay, let's do it. What is the primary hurdle and how are you resolving it?

MELL: The federal cloud initiative has identified the primary hurdle in securing the government adoption of cloud computing is this idea that we have a lack of government-wide authorizations capabilities. We are looking at how do we best perform security authorization and continuous monitoring for large outsourced and multi-agency systems. Our scope is somewhat broader than cloud, but cloud is really the initial focus of what we are doing.

When we see the government as increasing its use of the large, shared outsourced systems, there are technical drivers from service orientation, Web 2.0, virtualization in cloud computing. There are cost savings drivers from data center and application consolidation, and so we see the industry in the government moving in this direction. And the question arises, how do we do security authorization and how do we monitor these solutions?

We realized that if agencies continue with the current approach, which is to independently perform risk management, that there are problems and inefficiencies, technical problems and then cost inefficiencies. We would like to propose a better way to do that.

CHABROW: Have you come up with it or are there any ideas that have surfaced about how to do it?

MELL: Yes, we came up with a process for doing government-wide authorization for these systems last October, we have been vetting it and refining it within government and today we have a proposal. It is more than just sort of a PowerPoint proposal, this is the program that has been designed and vetted and works out; we have players and we are ready to do something; we are ready to go.

At this point, we are vetting this proposal within government to make sure that we have portrayed it correctly and that we have focused it correctly because what we are proposing here is to be optionally used by government agencies and we want to make sure that they are going to want to use it. That is the purpose of spending a few weeks to get the word out to the government and to explain what we are doing to get feedback, and then to open the floodgates of the dam and get things moving.

CHABROW: Can you just summarize some of the points?

MELL: Currently, with each federal agency independently doing risk management with these large outsourced systems in cloud computing you have got duplication of effort, but you have got incompatible policies being levied because the Federal Information Security Management Act is all about a framework by which agencies communicate or enforce their policies on a system. So you get 40 agencies together, enforcing their policies on a single system and the interception of those policies is likely not draftable. Likely, they will disagree on the finer points of server configuration, for example, and it just won't be possible and that is a source of great frustration for cloud vendors. It also means that acquisition is very slow, the lengthy compliance processes and then there is inconsistent application of these government-wide security programs.

To solve that, and I think this is common sense, I don't think we are doing anything unexpected or unusual here, it's certainly new, that the proposed solution is found within FedRAMP - the Federal Risk and Authorization Management Program. The idea is to create a government-wide, risk management program that has to be optionally used by the agencies. It provides joint authorization services and continuous monitoring services and again, I will stress that it is optional.

FedRAMP would perform assessment and authorization of these very large systems, these government-wide authorization then can be optionally leveraged by agencies so that they can adopt these services with a minimal of additional security effort required. FedRAMP would perform security, based on an agreed upon government-wide security baseline that agencies can leverage. That is what I mean by most of the work will be done because that baseline will have been assessed and authorized.

Agencies do have unique missions and risk tolerances and security needs, and so agencies are always welcome to do incremental additional security testing, require additional security controls to be implemented and so forth. But again, the idea is to complete the bulk of the work for the agencies; do it once and do it well and thereby reduce an enormous amount of duplication of effort and enable rapid acquisition by federal agencies, eliminate that concern of security requirements not being compatible when multiple agencies levied them on a particular resource pool cloud system. And lastly, ensure consistent application of federal government-wide security programs. The Trusted Internet Connection program or there is ITM, there is Einstein, and the list goes on.

CHABROW: Are you saying that this is going to be a voluntary program?

MELL: That is correct.

CHABROW: Is that because of uniqueness that different agencies would have or is there another reason for it?

MELL: It is voluntary because we do not want to take away the innate authority and responsibility of each agency to secure their systems. What we want to do is reduce duplication of effort, reduce costs, increase security and we believe that we can do that through this unified risk management program called FedRAMP and the agencies, by leveraging FedRAMP authorizations. will save a lot of money and enable rapid acquisition, but they are still in control. They get to choose whether or not they leverage it. They get to choose if they are going to do additional security work or what additional security work they are going to do to ensure that the systems meet the security needs of their agency.

CHABROW: If I understand the need for this is so that the private vendors, who will be providing a lot of the services to the government, would not have to come up with all of these different plans and they could just have a set standard of security measures in place?

MELL: From a vendor perspective, an advantage of this program is that they primarily work with one security assessment and authorization body, or one risk management program, and they don't have to independently meet all of the security requirements of the many, many different agencies. That is an advantage from a vendor perspective.

CHABROW: Who would be responsible? Who would oversee FedRAMP?

MELL: The idea is to have FedRAMP be a distributed interagency capability, so I believe if there was any one agency or person controlling everything that there would be too much power, too much authority concentrated in one hand and we wouldn't have a good separation of duties and we wouldn't have great accountability.

The structure that we have proposed is for FedRAMP to be divided into three major components. The three components are security requirement authorities, the FedRAMP office and the joint authorization board. The security requirement authorities are interagency working groups that come up with government-wide security baselines for specific domains.

That is where we get the interagency developed and approved requirements. That is where we get transparency throughout government and transparency to the vendors. What is the government as a whole? What does the government want as far security in its particular domain? ... The idea here is this will be a small group of authorizing officials (joint authorization board) from a small number of agencies that jointly perform the authorizations that are to be leveraged government-wide. They are the ones responsible for doing that ongoing determination of risk and sign off on the risk acceptance statement for use of the system.

That joint authorization board is accepting risk on behalf of the government, but I want to point out that when agencies choose to leverage that authorization, they are also then accepting that risk, too. The responsibility of security is never completely taken away from the agencies, but we are providing services to enable them to reduce their need to do duplicative security work and to leverage the work that has already been done government wide.

Lastly, the FedRAMP office. The FedRAMP office does program management for FedRAMP, which involves receiving proposed authorization packages from vendors and their sponsoring agencies, managing a public list of authorized systems, distributing authorization logos to the vendors so that when they sell to the government, they can communicate that yes, they have a government-wide authorization that can optionally be leveraged.

The other half of the FedRAMP office is doing that deep technical security review, analyzing the authorization packages, basically doing security measurement, determining what is that residual risk still posed by a system, and then providing oversight on continuous monitoring.

Those are the three bodies again and they working independently but collaboratively in order to distribute the security responsibility and authority and provide sort of checks and balances in akin to how our federal government operates.

CHABROW: Will there need to be any kind of authorization, whether it be legislation or Office of Management and Budget action to get this working?

MELL: That is such an interesting question. It turns that all of this fits perfectly within existing law, OMB policy, and even NIST security guidance. What we did do is in the new NIST risk management framework, in particular the NIST Special Publication 800-37, we added an Appendix s.6. That appendix talks about this notion of joint authorization being performed by the joint authorization board and then this concept of leveraged authorization where the agencies are leveraging the outcome of this joint authorization. We put the sort of foundational underpinnings of FedRAMP into the new NIST management framework.

And by the way, FedRAMP is designed to follow that NIST risk management framework and focus a lot on that continuous monitoring aspect.

CHABROW: Anything else you would like to add about FedRAMP?

MELL: This unified risk management process is about creating interagency, agreed upon security requirements, ensuring compatible security requirements on these shared systems through really eliminating that duplication of effort that we see in these very large outsourced, government wide systems, and associated costs savings and enabling that rapid acquisition that is possible by leveraging the preauthorized solutions, the better integration with government-wide security efforts, and this idea of increased security through having focused assessments; doing it once and doing it extremely well, but having distributed responsibility. So having a different group produce the requirements, a different group doing the technical analysis, and a different group doing the final authorization.

We see this not just for outsourced systems, but also for government wide systems. An agency that develops a system that they then decide that they want to sell to the rest of the government, FedRAMP offers a real value factor there. Currently, the agency develops their own security requirements, they implement those requirements, they assess the system, then they authorize their own system and then they do the continuous monitoring, and then they want to sell this to other federal agencies. They may show their authorization packages to customers, but there isn't a lot of independent accountability and oversight there.

Whereas in the FedRAMP model, you have an independent group producing the security requirements that the agency implements, you have independent assessors performing assessments, you have an independent FedRAMP office doing the security measurement and oversight of the monitoring, and you have a separate group of authorizing officials who are completely independent of the system and unbiased, performing this final risk acceptance and authorization so we have much greater accountability and oversight and ultimately I believe then much better security and a great ability for agencies to trust the output of the process.

CHABROW: How long do you think it will take before all of this could be in place?

MELL: I am casting this as a proposal, but to be honest we are ready to go. So far the agency response has been very, very positive. The vendor response, especially in the cloud space, has been extremely positive. They are frustrated working with the many agencies trying to limit different security requirements all in the same shared system. As soon as the federal executives say go we will be ready in a matter of weeks I would believe to talk publicly about the specifics and the submission process.

I should say that we are planning on doing a smaller scale pilot, test and authorize systems to exercise the machinery to make sure this all works as expected once a few systems have been authorized and expanded out to its ultimate full deployment.

CHABROW: Having this in place should not be interpreted as widespread deployment of cloud computing in government, is that correct?

MELL: That is true. Having this in place will enable the authorization of cloud systems, large cloud systems, that will enable rapid acquisition by the federal government. It won't mandate the acquisition. It won't be acquisitioned, but it is an enabler for rapid acquisitioning and associated costs savings in doing the security compliance work.

CHABROW: But there is still I would gather many challenges to see widespread use of cloud computing in government.

MELL: We see the security compliance hurdle as one of the major barriers to government adoption and should we solve the security problem, one of the largest if not the largest barrier, will have then been removed and I would expect to see agency usage of these government wide authorizations.

CHABROW: Cloud computing on a widespread scale could be closer than many people realize once this goes into effect?

MELL: I believe so.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing govinfosecurity.com, you agree to our use of cookies.