When it comes to managing FedRAMP-compliant systems, it helps to understand the entirety of the system that will fall under this jurisdiction. Unfortunately, with the complexity of cloud systems being what they are, mapping out IT systems with the right granularity can provide a challenge. This is why FedRAMP guides determining an organization’s authorization boundary.

How Does the FedRAMP Program Define an Authorization Boundary?

Cloud service providers preparing to run their offerings through the FedRAMP process must first determine the authorization boundary of their system. This boundary will include all the platforms, software, hardware, security components, and other infrastructure within which federal data and metadata will be stored, transmitted, or processed. 

The CIO Council’s Circular OMB A-130 states that an authorization boundary should inventory a cloud system’s internal components and external connections–both of which present unique challenges and requirements to the CSP.

Federal Data in Your Cloud Infrastructure

OMB A-130 defines federal information as “information created, collected, processed, maintained, disseminated, disclosed, or disposed of by or for the Federal Government.” 

With this relatively specific definition in place, it follows that any component of a cloud infrastructure containing this data would fall under FedRAMP and thus be part of the authorization boundary. 

Federal Metadata in Your Cloud Infrastructure

In common parlance, metadata is literally “data about data” or data that describes functions or features of other information. According to NIST SP 800-53, metadata may include descriptions of data architecture, formats, contents, or security labels. 

Under FedRAMP authorization boundary guidelines, metadata will fall under two different classifications:

1. Data that describes information about a federal customer and their activities on a cloud offering, including activity logs and scripts, or 
2. Information that impacts the confidentiality, integrity, and availability (CIA) of that federal customer’s information and the system it is contained in. This information can include audit logs, scripts, or vulnerability reports.

Cloud systems must be secured if they handle federal metadata, just as they would if they managed traditional data. Providers must account for those handling federal metadata in FedRAMP inventories to determine the CSP’s authorization boundary. 

Cloud Interconnections

NIST SP 800-47 defines interconnections as the direct connection between two more IT systems to share data and resources. The “interconnection” is the mechanism that connects two systems and can be represented as an integrated software service, an API service, an Ethernet or fiber optic connection, or any combination of hardware and services. These interconnections can provide data streams for automated IT systems, online and always-on communications, online training, and data backup. 

External Cloud Services

According to NIST 800-53, external services are systems that are used by, but are not part of, an organization system. These systems are under partial or complete control of a third-party vendor, and there are typically trusted relationships between authorized parties across the primary organization and the vendor. 

Because modern technology relies so heavily on augmenting technical capabilities through cloud platforms and managed services, it isn’t realistic to think that every CSP’s offering is 100% contained on-premise. However, because the third-party system essentially extends the authorization boundary, that vendor (and their offering) must meet minimum FedRAMP requirements (and have authorization) commensurate with the data they process for their client.

How To Determine Your FedRAMP Authorization Boundary

With these criteria and definitions in place, it’s somewhat straightforward to determine your authorization boundary. This process will include tallying the systems that touch sensitive FedRAMP information. 

The simple rules that FedRAMP puts forth to help organizations include the following:

• Internal Services Processing Federal Data: organizations should conduct due diligence in order to determine their internal IT systems and how they interact with regulated federal data. There should be a clear delineation between the inside and outside of that system when it comes to internal services (on-premise systems, applications, cloud infrastructure, etc.). That is, systems governed 100% by your organization, those not governed by your organization, and systems that aren’t interacting with federal data. 
• External Services Impacting Federal Data: If you work with an external service provider that contains federal data or provides services that impact the CIA of data or metadata, these external services must be considered inside your authority boundary. Providers must report these services to their Authorization Officer. If they don’t have their own standing FedRAMP ATO, they must provide a scope of assessment to provide your AO with the information they need for appropriate risk management. 
• Corporate Services: Corporate services support daily business operations and stand somewhat outside the scope of mission-critical IT infrastructure. These can include ticketing and customer service operations, billing, marketing, etc. So long as these services do not impact the CIA or federal information, they can be considered outside your authorization boundary. However, ensuring that these services don’t potentially open security vulnerabilities through unintended interactions (like an accidental release of vulnerability information via insecure channels) is critical. 
• Development Environments: A development environment mirroring an existing IT system or software products for customers may be considered outside the authorization boundary so long as it does not contain federal data or metadata. The AO must review these environments to see if any interconnections exist between them and regulated systems.

With all of these different instances of what sits inside and outside an authorization boundary, FedRAMP recommends that organizations have a network diagram highlighting all the systems that make up that boundary. This Authorization Boundary Diagram (ABD) helps JAB and assessment organizations not only understand the components that make up that boundary but also how to assess risk management issues related to the interconnections of boundary systems and the relationships between CSPs and third-party managed service providers. 

Is Your Cloud Infrastructure Ready for FedRAMP Authorization?

Platforms, software, user interfaces, third-party vendors–each component of a cloud system can potentially impact FedRAMP compliance. It takes serious attention to detail regarding inventories, component interactions, and proper security protocols to ensure that every device and module within your FedRAMP boundary is adequately protected.