Under the NIST RMF (SP 800-37 Rev. 2), how does a federal agency authorize a SaaS vendor's cloud service, and where does FedRAMP fit?
answer
- seven steps, Prepare first
- package: plans, assessments, POA&M
- risk acceptance stays with the AO
- authorization to use for shared systems
- reuse, not blanket approval
basics
~20 sUnder SP 800-37 Rev. 2, an agency's authorizing official reviews the service's authorization package and accepts the residual risk. For cloud services the agency can issue an authorization to use, relying on a provider authorization such as FedRAMP's instead of reassessing from scratch.
solid answer
~50 sThe **RMF** in SP 800-37 Rev. 2 has **seven steps**: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. In **Authorize**, the system owner submits an **authorization package** - executive summary, system security and privacy plans, security and privacy assessment results, and relevant **POA&Ms** - and the **authorizing official (AO)** determines whether the risk is acceptable. Decisions are an authorization to operate, a common control authorization, an **authorization to use**, or a denial. Only the AO can make the risk-acceptance decision; it cannot be delegated to a designated representative. For a cloud service, the customer agency's AO can issue an authorization to use after reviewing the provider's package; SP 800-37 treats a FedRAMP authorization issued through GSA as a valid basis for that. FedRAMP applies SP 800-53-based baselines to cloud offerings so the package is reused, but each agency still accepts risk for its own data.
go deeper
Recall the seven RMF steps in order and that an authorizing official issues the authorization decision.
Explain what goes into the authorization package, the four decision types, and why the risk acceptance cannot be delegated.
Show how you would take a SaaS service to a federal customer: impact level, boundary, customer responsibilities, POA&M and continuous monitoring that keep the authorization alive.
Discuss the trade-off of pursuing a higher impact level up front versus a narrower first authorization, given which agencies and data you are targeting.
## The scenario A SaaS vendor wants its first federal agency customer. The agency cannot simply buy a subscription: federal policy expects external providers that handle federal information to meet the same security and privacy requirements as agencies, and a named official must accept the risk. The framework for that decision is the **Risk Management Framework (RMF)** in **NIST SP 800-37 Revision 2** (December 2018). **FedRAMP** is the government-wide programme that applies it to cloud services. ## The seven RMF steps SP 800-37 Rev. 2 has a preparatory step and six main steps: 1. **Prepare** - establish context, roles, risk strategy, common controls and the authorization boundary. 2. **Categorize** - categorize the system and its information by impact of loss (FIPS 199). 3. **Select** - select, tailor and allocate controls from SP 800-53, documented in security and privacy plans. 4. **Implement** - implement the controls and record the as-implemented state. 5. **Assess** - a selected control assessor determines whether controls are implemented correctly, operating as intended and producing the desired outcome; findings feed a **plan of action and milestones** (task A-6). 6. **Authorize** - a senior official decides whether the risk is acceptable. 7. **Monitor** - continuously monitor controls and changes, report posture, and support ongoing authorization. ## The authorization decision In the Authorize step (tasks R-1 to R-5) the system owner assembles the **authorization package**. At a minimum it contains an executive summary, system security plan, privacy plan, security control assessment, privacy control assessment and any relevant plans of action and milestones. The **authorizing official (AO)** analyzes the risk, decides on a response, and issues one of these decisions: | Decision | Meaning | |---|---| | Authorization to operate (ATO) | Risk accepted; the system may operate under stated terms and conditions | | Common control authorization | Controls offered for inheritance by other systems are authorized | | Authorization to use (ATU) | A customer organization accepts a provider's already-authorized shared or cloud system | | Denial of authorization | Risk unacceptable; the system is not placed into operation, or halts if already running | The AO may delegate much of the RMF work to a designated representative, but not **the authorization decision and signing of the decision document** - that is, the acceptance of risk. An ATO may carry an **authorization termination date**, which an organization may drop when the system is under **ongoing authorization** backed by continuous monitoring. ## Authorization to use and FedRAMP SP 800-37 Appendix F describes the **authorization to use**: a customer organization's AO reviews the provider's authorization package and issues an ATU instead of a fresh ATO. The customer can issue it only after a valid authorization exists for the provider's system, and it considers: - the time elapsed since the assessment results were produced; - whether its own environment of operation differs from the one assessed; - the impact level of the information it will process; - its own risk tolerance, and any integration with its other systems. SP 800-37 states that a provisional authorization issued by the **General Services Administration (GSA)** under **FedRAMP** is considered a valid authorization for customer organizations that want to issue an authorization to use for cloud services. FedRAMP authorizations are granted against baselines built on SP 800-53; the CMMC rule, for example, accepts cloud offerings that are FedRAMP Authorized at the Moderate baseline or higher. ## What this means for the vendor - **Pick the impact level from the customers' data**, since the baseline follows categorization. A Moderate authorization will not cover a customer whose data is high-impact. - **Define the boundary** carefully; FedRAMP provides guidance on cloud authorization boundaries, and everything inside it is assessed. - **Document customer responsibilities**: controls the agency must operate itself stay in the agency's own plans. - **Plan for monitoring**: POA&Ms, continuous monitoring and significant-change handling keep the authorization valid after day one. - **Expect each agency to decide separately**: reuse removes duplicate assessment work, not each agency's own risk acceptance. A vendor that treats the authorization as a one-time audit usually loses it: the Monitor step, with ongoing assessments and reporting to the AO, is what keeps an authorization current. FedRAMP's own procedures and document templates are set by the programme and change over time; the RMF vocabulary above is what stays stable across them.
- What does an authorization package contain under SP 800-37 Rev. 2?At a minimum: an executive summary, the system security plan, the privacy plan, the security control assessment, the privacy control assessment, and any relevant plans of action and milestones. The AO bases the risk decision on it.
- What happens if the AO denies authorization for a system already running?Under SP 800-37 Rev. 2 a denial means the system is not authorized to operate; if it is in operation, all activity is halted. The AO works with the system owner to revise the POA&M so the deficiencies are corrected.
- Does a FedRAMP authorization let every agency use the service automatically?No. It gives agencies a reusable package and a valid basis for an authorization to use, but each agency's AO still reviews it against its own data, environment and risk tolerance and issues its own decision.
saying these in an interview costs you the question
- Says a FedRAMP authorization removes each agency's own risk decision
- Lists six RMF steps, leaving out Prepare
- Believes the designated representative may sign the risk acceptance
- Treats the ATO as permanent regardless of monitoring or change
- Confuses RMF steps with the CSF Functions