In part 1 of this series, we addressed the question “Is an NDA with FedRAMP needed to protect my company’s trade secrets?” In today’s topic we address the question “If I follow FedRAMP requirements and get a P-ATO, my cloud service will be well designed and attractive to Federal Agencies, right?”.

The short answer is no…  But the key to understanding this is to known some backstory on FedRAMP. 

FedRAMP is the Federal government’s solution for enabling compliance with the Federal Information Security Management Act (FISMA) in an efficient way in the age of Cloud Computing. FISMA was signed into law as part of the E-Government act of 2002 and required agencies implementing IT systems to put those systems through a risk management process where controls would be selected, implemented and tested. Then each system would need to be authorized based on residual risk, a decision made by an agency authorizing official.

When cloud computing came along, agencies were left to their own devices to ensure that the underlying cloud infrastructures they wanted to use were authorized. This led to an authorization for each use which was redundant and inefficient. The Federal Government created FedRAMP in 2012 with a mission to enable agencies to “authorize once and reuse many times” for each cloud service.

FedRAMP is a solution to the legal issue of system authorization and reuse of those authorizations from a security and risk management standpoint. With the exception of a few requirements that the Cloud Service Provider correctly describe its Cloud Service in terms of the NIST Cloud Computing Reference Architecture, FedRAMP does not evaluate the fitness of purpose of a cloud service to meet Federal cloud use cases. This is left up to the agencies to evaluate through the normal procurement process. It is up to the cloud provider to provide a compelling and competitive cloud offering and to sell this to target agencies.

So, now we know that FedRAMP is not a specification, and the P-ATO is not a measurement for building a good, functioning, feature-rich, and desirable cloud service. The real nuance here is that FedRAMP even has limitations in its mission to evaluate the security of a cloud in terms of Federal requirements.  This really goes back to what we’ve already described about FedRAMP – it is a single authorization process designed to be reused many times. In a normal agency authorization, the authorizing official (AO) is a stakeholder who can evaluate the residual risks present of operating a system versus the advantages that the system offers in enabling business processes. When you replace the AO with the Joint Authorization Board (JAB), they really cannot know what risks can be accepted and which cannot, because they can’t foresee every cloud consumer that will be leveraging that P-ATO and make the appropriate risk based decision. Likewise, with an agency accreditation, an AO can only evaluate the risk/rewards of their specific system, not the next one for the next agency who will re-use the P-ATO.

For this reason, the FedRAMP PMO has specifically stated that their mission is to help describe the residual risks in each system so that agency AOs can make the appropriate decision as to if they will leverage the P-ATO. It doesn’t take much imagination to see that this can ultimately lead to a P-ATO decision for a cloud with too many risks for the average agency to accept. It is possible to end up with a pre-authorized cloud with a very small market reach.

FedRAMP is a significant investment, and you want the broadest reach possible for your Federal Cloud P-ATO. By working with a trusted advisor like InfusionPoints, you can leverage our experience to help discern what is (and is not) acceptable for the markets you are targeting.

Next in our series, we will address the question “Is system documentation included in the system boundary? / What classification should be placed on our system security plan and overall package?”.

Use the links below for other topics in this series.

• Part 1 - Is an NDA with FedRAMP needed to protect my company’s trade secrets?
• Part 2 - If I follow FedRAMP requirements and get a pATO, my cloud service will be well designed and attractive to Federal Agencies, right?
• Part 3 - Is system documentation included in the system boundary? What classification should be placed on our system security plan and overall package?
• Part 4 – Who is allowed to work on the system or access the SSP documentation? What about non-US Persons / non-US Citizens?
• Part 5 - What is required to accomplish continuous monitoring, and how can we prepare?
• Part 6 - How should I classify my system?