The Risk Management Framework (RMF) Security Assessment and Authorization (SA&A) Processes for Cloud-hosted Applications
As of June of 2014, all federal organizations are restricted to using CSPs that have been FedRAMP authorized, or that are in the process of obtaining their FedRAMP authorization to operate. Visit the GSA's FedRAMP site for more information and for a listing of currently approved and in-process CSPs.
Security Assessment and Authorization (SA&A) are just two of the six steps that comprise the risk management framework (RMF) as defined by the National Institute of Standards and Technology in NIST Special Publication 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems. The RMF is the full life cycle approach to managing federal information systems' risk and includes these steps: 1) categorizing the system; 2) selecting security controls; 3) implementing security controls; 4) assessing controls; 5) authorizing systems; and 6) monitoring security controls.
Because your system will be hosted by a cloud service provider (CSP), the SA&A process is more involved and, therefore, will be more expensive and time consuming to complete than for internally (aka federally) hosted applications. According to FISMA, all federal applications/systems must be authorized in writing before they are placed into operation. This applies to both internally- and externally-hosted (and cloud) applications.
According to NIST's Special Publication 800-145, The NIST Definition of Cloud Computing, Cloud based systems are typically leased infrastructure and use one or more of the following service models: Platform as a Service (PaaS); Software as a Service (SaaS); or Infrastructure as a Service (IaaS). System owners who use a CSP should understand the compliance requirements for such environments because they do vary some from traditional infrastructure solutions. Federal agencies that use cloud services fall under the auspices of both the Federal Risk Authorization Management Program (FedRAMP) program, which is managed by the GSA, and by NIST's 800-37 Risk Management Framework, which outlines how traditional FISMA assessments are conducted. When choosing a cloud service provider you should first ensure that the provider has a FedRAMP issued or recognized Authorization to Operate (ATO). Please visit GSA's list of authorized CSPs to find the current list of FedRAMP authorized CSPs.
The information below will help you understand how to prepare for and conduct the SA&A for your cloud-based application.
1. Categorize the Application
Use the NCI Security Starter Kit for templates and guidance on completing the Federal Information Processing Standard (FIPS)-199 form, the e-Authentication Threshold and Risk Analysis (eTA/eRA) forms, and the Privacy Impact Assessment (PIA). All three forms are required to ensure that you select the appropriate security controls for your application based on its security-impact rating, authentication needs, and privacy concerns. This step is consistent with other types of federal information systems whether hosted internally, externally, or in the cloud.
2. Select Security Controls
Once you have completed categorizing your application you can determine which system specific and portions of shared controls are needed for your system. Since your application is hosted in a cloud environment, many of the controls are likely to be inheritable partially or fully from the CSP and should already have been assessed under the CSPs FedRAMP authorization. Any portion of a hybrid control and any system-specific controls that are not provided by the CSP will need to be separately implemented by you for your application, and evaluated during your application's assessment step (Step 4). Since you are using a cloud based solution, you must follow the appropriate FedRAMP control baseline rather than the normal FISMA/NIST baseline that would be used for non-cloud systems. This control selection matrix can be used as a starting point, but you need to review both FedRAMP guidance and work with your cloud service provider at the project initiation to ensure you identify all controls that they provide and those that you will be responsible for.
3. Implement Security Controls
As part of the implementation, you may need to update your application's design requirements to account for new or modified security requirements. You may also need to implement or develop specific tools to satisfy required controls. If the cost of developing or implementing a new security control is impractical or if it is not cost effective when compared to the potential risk of not implementing the control, you can apply for a security waiver to the NIH chief information security officer (CISO). You should discuss any waiver requests first with your Contracting Officer Representative (COR), and with the NCI ISSO (nciirm [at] mail.nih.gov) before actually submitting the request, to determine if there are any compensating control options and whether the waiver is likely to be approved.
4. Conduct the Security Assessment
It is important to note that FedRAMP's Joint Advisory Board (JAB) may directly act as the authorizing official for a CSP, or a federal agency may sponsor a CSP's assessment using the FedRAMP controls, templates, and processes. In either case — whether a JAB or an agency sponsored ATO is sought – all CSP assessments must be carried out by an approved third party assessment organization (3PAO) and all documentation and artifacts must be deposited in the FedRAMP repository.
In addition to the FedRAMP assessment process that all CSPs are to follow, which focuses solely on the common (i.e., inheritable) controls from the CSP, federal application owners are also responsible for conducting an assessment of non-inherited controls in their applications to ensure the privacy and security of data and applications implemented and deployed in the cloud. Together, the FedRAMP authorization decision (of the inheritable controls) and the application specific security assessment (of the non-inheritable and hybrid controls) that are conducted form the basis of the final federal authorization package and decision.
During this phase of the Risk Management Framework, (RMF) a qualified – and usually an independent 3rd party – security assessor will evaluate the effectiveness of your application's non-inherited security controls. This process must be completed before your application goes into production (i.e., is live with real data being collected, processed, or stored). Because your system is hosted in the cloud, your organization will likely bear the full cost of assessing these residual non-inherited CSP controls. The security assessor shall be experienced in using the National Institute of Standards and Technology (NIST) RMF as outlined in NIST 800-37.
Your final SA&A package must contain the minimum set of artifacts required by NIH. Visit the NCI SA&A Package Checklist for more information.
5. Authorize the Application
In addition to the required JAB or Agency sponsored FedRAMP assessment and ATO, you are required to obtain an application specific ATO from the designated authorizing official (AO) for your application. This application specific ATO takes into account the CSP's existing provisional ATO as well as the application specific security control assessment. Your designated AO will review the assessment package in total to determine if identified residual risks are acceptable to the organization before issuing a written formal authorization to operate (ATO) your application, which is valid for up to 3 years.
Your AO will most likely be either your Contracting Officer Representative (COR) or your Federal Program Manager (PM), sometimes one and the same. If you have trouble determining who the AO will be for your system, email the nciirm [at] mail.nih.gov (NCI ISSO) for assistance in making a determination.
6. Conduct Continuous Monitoring and Reauthorization
Continuous monitoring (CM) is the sixth and final step in the RMF, and includes both automated and manual security monitoring and remediation activities. The routine security-control monitoring and remediation that occur after an application has been authorized to operate often includes a combination of automated diagnostics services such as vulnerability management, intrusion detection and prevention, system and application event log collection and analysis, and patch management. Along with these, manual assessment and remediation procedures such as annual assessments (AA), security impact reviews, plan of action and milestones (POA&M) management, and ongoing authorization (OA) or re-authorization must be performed.
The NIH SA&A policy requires application owners to assess the selected controls that align with the Critical Security Controls for Cyber Defense list, which represents a consensus of government and industry security experts. This approach helps owners address the most prevalent security threats on an ongoing basis while maximizing efficiency. These controls need only be assessed to the extent they are not already covered under the FedRAMP inherited controls or those that are separately measured by the CSPs ongoing authorization model, which is required of all FedRAMP CSPs to maintain their ATO.
Security Impact Reviews
Any time a significant change to your application is proposed while it is operational, you must ensure that new security risks are identified, evaluated, and addressed before those changes are implemented. This may require re-testing of any new or modified controls and, possibly, reauthorization of your application.
The Plan of Action and Milestones (POA&M) is a key management tool that lists, prioritizes, and tracks an application's identified weaknesses and progress. Any new security findings that are generated from ongoing security assessment and risk impact reviews should be added to the application specific POA&M and remediated in a timely manner. You should not track the CSPs POA&M items as those will be monitored by the FedRAMP Project Management Office (PMO) or by the agency that sponsored their FedRAMP assessment.
Ongoing Authorization or Reauthorization
The NIH is currently developing its ongoing authorization (OA) model for externally hosted applications. Because of the numerous technical challenges associated with automating security analyses and remediation activities outside of the NIH network boundary, this process will most likely include a hybrid of automated and manual activities. NIH is now able to conduct AppScans of applications hosted external to the NIH firewall. Please review the AppScan procedure for instructions on how to setup external scans and reporting. Also, please check back here periodically for updates on NIH's continuous monitoring efforts.