Establishing a system boundary is the single most important step when categorizing and securing a system. Regardless of the compliance regimen you are using, laying out a system boundary is the first step to determine what needs protection. While some system owners might have flexibility in defining what constitutes their information system, others, like cloud service providers (CSPs) looking to achieve FedRAMP authorization to operate (ATO), will have a prescribed path to follow.

What is the difference between a system boundary and an authorization boundary? A system boundary is simply the security parameter around what you are protecting, while an authorization boundary is the system boundary for which you are looking to achieve an ATO. Authorization boundaries allow you to establish the scope of protection for information systems, including people, processes, and technologies.

When it comes to cloud environments, determining the authorization boundary is a complex task. According to the FedRAMP PMO, “Defining the authorization boundary is by far the hardest non-technical component of a security package.” Even though cloud computing is not a new concept, understanding cloud dependencies and the shared responsibility model can be challenging.

For example, a software as a service (SaaS) provider can leverage different configuration models to design its cloud stack. SaaS providers can choose to leverage either an infrastructure as a service (IaaS) or platform as a service (PaaS) model, which will ultimately drive the responsibility model and the scope of controls. A control responsibility starts where the underlying provider’s responsibility ends. Depending upon which model they choose, their responsibility and the scope will vary significantly. Therefore, leveraging a PaaS will leave significantly less controls for the inheriting CSP to implement. The underlying CSP must clearly define where their responsibility ends so the inheriting CSP is clear on where its boundary begins.

CSPs must provide transparency into where their information systems transmit, process, or store federal government data and the accompanying metadata. Metadata is any data used to describe federal data or data that could affect the confidentiality, integrity, and availability (CIA) values of the cloud service offering (CSO). This can be audit logs, vulnerability scans, incident response data, and more.

In light of these challenges, FedRAMP issued authorization boundary guidance using four “rules of thumb” to help CSPs determine their responsibility:

Rule of Thumb 1: All information system components that process, store, or transmit federal government data must be within the authorization boundary.

Rule of Thumb 2: CSPs must disclose all external connections and any risk associated with them. In the event the external system is affecting the CIA values of the CSO, those external services must be brought inside of the authorization boundary. For example, a vulnerability scanner or a ticketing system hosted outside of the authorization boundary falls under this rule and must be moved inside the boundary. No metadata of the system can leave the authorization boundary.

Rule of Thumb 3: Corporate services may stay outside of the authorization boundary as long as they are not affecting the CIA value of the CSO. For example, if you are using a corporate email service to support your daily business functions without transmitting any information about your FedRAMP environment, it can remain outside of the boundary.

Rule of Thumb 4: The development environment is excluded from the authorization boundary as long as this environment does not process, store, or transmit any federal government data.

According to this guidance, the first step would be to understand where the data resides and where it flows within the system. The next step is to delineate the control responsibility between the underlying provider (IaaS or PaaS) and the customer. Once the CSP is clear on all the components that need protection then the technical, administrative, and management controls can be implemented to protect the data hosted within the information system.

Below are a number of specific questions to consider when defining your authorization boundary:

• Will the boundaries leverage any underlying infrastructure or platform as a service? Does the underlying provider have a FedRAMP ATO at the same or higher level as the respective CSO?
• Is the CSO environment a multi-tenant or a single tenant? If multi-tenant, will the U.S. federal government data reside in the same environment with the data of non-government entities? How are tenants isolated?
• Will multiple tenants share the same VLAN(s)? Are there controls that prevent VLAN hopping?
• Is unique network segmentation used to isolate virtual machine (VM) zones?
• Is traffic encapsulation used?
• How do firewalls provide isolation between tenants?
• Is the CSP using network filters to control packet traffic to or from a VM?
• Is network address translation (NAT) used and how does it play a role in containing network traffic within the boundary?
• Are geo IP location boundaries used?
• Will it be possible for agency tenants to know the geographic location (city, state) where their data is stored?
• How many interconnections do you have? Is there an Interconnection Security Agreement (ISA) in place for each one of them? Do the connecting systems have FedRAMP authorization?
• Which corporate services are you leveraging? Do any of them transmit government data?

Answering all these questions and addressing the rules of thumb offered by the FedRAMP PMO will take some time and effort, but it will be well worth the investment in the long run. A good place to start your journey is with our FedRAMP Tip Sheet, which provides valuable insights into getting started with cloud offerings for the federal market. You can also request a demo of Xacta 360™ from Telos, which helps reduce the time and cost needed to achieve and maintain FedRAMP compliance.