On September 14th, 2022, the FedRAMP Program Management Office (PMO), in collaboration with the Joint Authorization Board (JAB) and Office of Management and Budget (OMB), released their draft for version 3.0 of the FedRAMP Authorization Boundary Guidance. This revision aims to improve the scope and categorization of FedRAMP information systems by better defining data types, compliance requirements, and authorization roadmaps that may impact a Cloud Service Offering (CSO) boundary.
Overview of Changes
| Current Sections (Version 2.0) | Draft Sections (Version 3.0) |
| 1. Defining your Authorization Boundary in the Cloud | 1. Defining your Authorization Boundary in the Cloud |
| 2. Federal Information (data) in the Cloud | 2. Federal Data in the Cloud |
| 3. Metadata Associated with the Cloud | 3. Data Produced in Systems Supporting Federal Data |
| 4. Interconnections in the Cloud | 4. Interconnections in the Cloud |
| 5. External Services in the Cloud | 5. External Services in the Cloud |
| 6. Leveraging External Services with a FedRAMP Authorization | 6. Leveraging External Systems with a FedRAMP Authorization |
| 7. Corporate Services | 7. Related Considerations and Requirements |
| 8. Corporate Services | |
| 9. Data Requirements | |
| 10. Additional Agency-Specific Security Requirements |
Defining Your Authorization Boundary in the Cloud
The new draft better reflects the requirements for defining an authorization boundary. NIST Special Publication (SP) 800-37 defines an authorization boundary as “all components of an information system to be authorized for operation by an Authorizing Official (AO) and excludes separately authorized systems to which the information system is connected.” Simply put, a CSP must define all pieces of technology within the information system that would be used to process, store, or transmit federal data, except for information systems that have already been granted authorization.
Section one of the draft guidance elaborates on what is considered in the boundary, and what is excluded. For instance, all external services that process, store, or transmit federal data must be included in the boundary or reside in a FedRAMP authorized system that operates at the same or greater FIPS-199 level as the connecting CSO. Components that are provided by the CSP and run within the customer environment (e.g. agents, applications, specialized hardware) will also be included in the assessment and boundary. Authorized systems that are controlled and managed by the customer are excluded from the CSO boundary.
Federal Data in the Cloud
The Federal Data in the Cloud section has been expanded upon with additional parameters, and updated language better defining what constitutes federal data. Below is the current, and the proposed (draft):
| Current Version | Draft Version |
| CSP’s should account for and include within an authorization boundary all federal data populated or generated by a federal customer within the CSO, including metadata. | CSP’s should account for, and include within an authorization boundary, all federal data populated or generated by a federal customer within the CSO, including direct-impact, indirect-impact and low/minimal-impact data. Any information that the system processes or stores that originates from or is produced for a federal government entity is considered federal data. |
The proposed draft expands upon what the definition of federal data is, in order to reduce confusion and ensure that all applicable data is properly brought into scope. The new version 3.0 language places a priority on identifying the impact level of federal data created or used by a federal customer within the CSO so all required components and connections may be incorporated within the FedRAMP boundary.
Data Produced in Systems Supporting Federal Data
This is a new section that was introduced in the draft of version 3.0. This section compiles data types into impact level groups, that each have their own requirements for compliance and security. Data is categorized by determining the impact that could be made if the Confidentiality, Integrity, or Availability (CIA) of the data is compromised. Proper data identification and categorization is paramount to the FedRAMP process and establishing a complete information system boundary. FedRAMP CSPs must work with the Authorizing Official (AO) for their FedRAMP system to properly scope the potential impact of data compromise and ensure the appropriate levels of protection are in place. This includes identifying all direct-impact data, indirect-impact data, and low and limited-impact data.
Interconnections in the Cloud
One of the notable changes to this section is the removal of the term “metadata”, to be replaced with “data produced by systems supporting federal data.” Version 3.0 of the FedRAMP Authorization Boundary Guidance looks to reduce confusion around what metadata is and how it should be categorized within FedRAMP authorized information systems. Version 3.0 focuses on properly identifying all data that could potentially leave the CSO boundary and the impact level of that data. This revision aims to broaden the scope of system interconnections and help CSPs ensure all interconnections are reviewed with the AO and appropriately secured and monitored.
External Services in the Cloud
The External Services in the Cloud FedRAMP Guidance section has been expanded to require additional documentation and attestation. If this proposed draft is published, it would require CSPs to clearly document how external services work, what federal data goes through those services, ports that are used, security measures in place, and encryption methods used during connectivity to those external services, as well as how federal data could be impacted by the CSP using them.
| Current Version | Draft Version |
| Cloud technologies can augment or support their functionality by leveraging systems, components, and services from external services that are not directly controlled by the vendor pursuing a FedRAMP authorization. The CSP must clearly communicate these external services to the AO and the extent to which federal information (data) can be impacted by the use of these services. CSPs should make their FedRAMP authorization package (System Security Plan [SSP], Security Assessment Plan [SAP], Security Assessment Report [SAR], etc.) reflect this information. | Cloud technologies can augment or support their functionality by utilizing systems, components, and services from external services that are not directly controlled by the CSP pursuing a FedRAMP authorization. The CSP must clearly document these external services including the flow of the data, specific ports, the security and encryption used in all the connections, and the extent to which federal information (data) can be impacted by the use of these services. The use of external services that carry federal data, and data produced by systems supporting federal data, must be depicted as part of the CSO’s authorization boundary and must meet the data requirements for the different data categories. CSPs should make sure their FedRAMP Authorization Package (e.g., System Security Plan [SSP], Security Assessment Plan [SAP], Security Assessment Report [SAR], etc) reflects this information. As part of issuing the Authority to Operate, the AO must review and approve the use of the external systems as part of the CSP’s authorization boundary. |
Leveraging External Systems with a FedRAMP Authorization
This section was expanded upon to clear up confusion with the previous version of the FedRAMP Authorization Boundary Guidance. The draft states that if a CSO leverages an underlying IaaS, PaaS, or SaaS, it is required to be FedRAMP Authorized, and the leveraged CSP is required to demonstrate compliance with all FedRAMP security and privacy requirements commensurate with the criticality of the data processed. These relationships have to be documented within the FedRAMP authorization package, specifically the CSO SSP.
Related Considerations and Requirements
Section Seven – Related Considerations and Requirements, was newly added in version 3.0 of the draft. This section is only applicable to JAB-authorized systems. It adds details around what is required of agents that are both in-boundary and also communicate with external systems that are non-JAB Authorized systems, as well as restrictions that apply to system-to-system integrations/communication. For reference, agents would be considered locally stored software that is communicating with other software/systems. Below is a summary of the restrictions to agents/systems:
Restriction on Agents
The draft boundary guidance provides clarity on the use of agents within the environment and adds the following restrictions:
- Agents must be configured with minimum required privileges within the environment.
- Privileged Agents’ configurations are managed in-boundary, and there are restrictions in place to prevent external configuration changes.
- Externally connected agents are restricted from executing arbitrary or externally-defined code, scripts, plugins, patches, updates, etc.
- FedRAMP authorized Cloud Service Providers provided by the U.S. Government – Agents supporting Federal Department/Agency SOC services and CISA Endpoint Detection & Response as required per M-22-09 or future memorandum are permitted if they are part of a FedRAMP Authorization (JAB or Agency) or traditional Agency ATO. The agent shall be documented within the SSP and validated by the 3PAO.
Restrictions on System-to-System Integration
A persistent area of confusion for CSPs pursuing FedRAMP is the extent of allowed integration with other corporate and / or external systems. The draft guidance provides more specificity on this issue by clarifying the following restrictions.
- Direct Connect, Peering, and persistent VPN tunnels are forbidden between JAB Authorized and non-JAB Authorized systems.
- The JAB Authorized system may make outbound calls to external systems (via agents, embedded services, or code as otherwise configured). This configuration shall be managed within the system boundary and verified by the Third-Party Authorizing Official (3PAO).
- Inbound connections to the JAB Authorized system shall not have privileged access to the system, nor control the operation or configuration of agents within the system. Agents must not be able to make configuration changes that affect the security posture of the systems or change the types of data collected without CSP managed intervention or permission.
- FedRAMP authorized Cloud Service Providers provided by the US Government – Service Integrations supporting Federal Department/ Agency SOC services and CISA Endpoint Detection & Response as required per M-22-09 or future memorandum are permitted if they are part of a FedRAMP Authorization (JAB or Agency) or traditional agency Authority to Operate (ATO). The service integration shall be documented within the SSP and validated by the 3PAO.
Corporate Services
There was a pretty substantial change to the Corporate Services section. In the current version, corporate services were assumed to not process or store any federal data or unauthorized direct-impact data. This has been changed to state that any corporate service that does contain federal data or unauthorized direct-impact data is now considered in-boundary, and must be secured with the same requirements as other systems and components within the CSO. Any corporate system that is being used to process or store federal indirect-impact data must be owned and operated by the CSP and must meet the NIST SP 800-171 security requirements.
| Current Version | Draft Version |
| Services used by a CSP to support their daily business operations and exist outside of the CSO authorization boundary. These services also do not contain any information that would impact the CIA of the CSO. | Corporate services are services used by a CSP to support their daily business operations and exist outside of the CSO authorization boundary. These services must not contain any federal data or unauthorized direct-impact data. Any corporate services that contain federal indirect-impact data must meet the security requirements outlined above. If a corporate system is being utilized to process or store federal indirect-impact data, the CSP must own and operate the system and attest that the system meets the security requirements outlined in the NIST SP 800-171 or be in a CSO at the same security level. |
Data Requirements
Section Nine – Data Requirements, was newly added in version three of the draft. This section defines requirements for each of the different types of data discussed in the FedRAMP Boundary Guidance. Below is a list of all of the data requirements:
- Federal Data: Federal data that is processed, stored, or transmitted by or for the federal government, in any medium or form, must be included in the authorization boundary and must be in a system authorized to the same level as the CSO being authorized.
- JAB Specific Requirement: All JAB systems must only leverage JAB systems of the same or greater FIPS-199 impact level to process, store, or transmit federal data.
- Direct-Impact Data: Data that can directly impact the CIA of an information system that stores, processes, or transmits Federal Data for the Federal Government, in any medium or form, and must be included within the authorization boundary or it must be in a system authorized to the same level as the CSO being authorized.
- JAB Specific Requirement: All JAB systems must only leverage JAB Authorized systems of the same FIPS-199 impact level to process, store, or transmit dynamic federal data and direct-impact data.
- Indirect-Impact Data: Data that can indirectly impact the CIA of an information system that stores, processes, or transmits federal data for the federal government, in any medium or form, must be included within the authorization boundary or must be in a system authorized to the same or greater level as the CSO being authorized or must be authorized to be in a corporate system that is wholly owned and operated by the CSO.
- JAB Specific Requirement: All JAB systems must only leverage JAB or agency-authorized systems (depending on the impact of the data) of the same or greater FIPS-199 impact level or corporate information systems that are wholly owned and operated by the CSO to process, store or transmit static authorized federal indirect-impact data.
- Corporate/No-Impact Data: Data about processes within the authorization boundary, or about federal customers that do not contain federal personal information, and/or information that if compromised could be a threat to the systems supporting the processing and storage of federal or data about the systems supporting federal data or federal personnel data.
Additional Agency-Specific Security Requirements
This section is newly added in version three of the draft. Section ten speaks on how FedRAMP defines a baseline that is used by all agencies to determine what their desired security posture would be. The section mentions that while FedRAMP is used as a baseline, it is important to know that there may be additional requirements that must be met, depending on the customer. It is important for CSP’s to engage regularly with their Federal customers to determine if there are any additional requirements for federal data types that need to be met.
Conclusion
The FedRAMP Authorization Boundary Guidance draft version 3.0 has improved transparency as to what is considered in-scope, as well as what data and components should be removed from the FedRAMP Authorization Boundary. The addition of the “Data Requirements” section assists in explicitly defining the different types of data, as well as which data types are considered in-boundary. While there will undoubtedly be revisions to this document, version 3.0 is much more clear than its predecessors.
Contact Us to Learn More
38North Cloud Security Advisors can help you prepare for future changes to the FedRAMP boundary guidance. Contact us for a free boundary consultation, to talk through these changes and be ready for the future of FedRAMP.
