Defining Your FedRAMP Authorization Boundary

Obtaining Federal Risk and Authorization Management Program (FedRAMP) authorization is required for Cloud Service Providers (CSPs) wishing to be listed on the FedRAMP marketplace and to do business with  Federal government agencies.

An important step in achieving FedRAMP authorization is to define the scope or “authorization boundary” of your CSP environment that will be authorized for operation. While this may sound simple, it can be surprisingly complex.

In this blog post, we’ll provide guidance for defining a FedRAMP authorization boundary to help ensure the success of your FedRAMP authorization journey.

What is FedRAMP?

FedRAMP is a United States government-based program that provides a standardized approach to security assessments, authorization, and continuous monitoring for cloud products and services. It is based on the National Institute of Standards of Technology (NIST) Special Publication 800-53 baselines and adds additional controls that specifically address elements of cloud computing.

What Are the Benefits of FedRAMP Authorization?

The benefits of FedRAMP authorization include:

• Enables you to do business with  Federal government executive agencies.
• Strengthens your security posture, which helps to guard against cyberattacks and ensure the privacy of your data.
• Demonstrates to your government and non-government clients and partners that you take security seriously.

What is a FedRAMP Authorization Boundary?

The NIST 800-37 standard defines an authorization boundary as “all components of an information system to be authorized for operation by an Authorizing Official[1] and excludes separately authorized systems to which the information system is connected.”

The authorization boundary establishes the scope of operation and protection for an information system. This includes people, processes, and information technologies that are a part of the system supporting business functions. It also defines what entities are authorized to access and process federal information.

The authorization boundary should:

• Describe a cloud system’s internal components and connections to external services and systems.
• Account for the flow of all Federal information and metadata.
• Illustrate a CSP’s scope of control over the system.
• Identify system components or services that are leveraged from external services or controlled by the customer.

FedRAMP requires the authorization boundary to be depicted in visual documentation, including Authorization Boundary Diagrams (ABDs), Network Diagrams, and Data Flow Diagrams. This documentation must be maintained as systems and services are modified.

Timeline of FedRAMP Authorization Boundary Guidance

Here’s a summary of recently published authorization boundary guidance:

• May 2018—Original Authorization Boundary Guidance document (version 1.0) released.
• May 2021—Executive Order 14028 on Improving the Nation’s Cybersecurity issued.
• September 2021—Latest draft of Authorization Boundary Guidance document (version 2.0) closed for public comment.

The following helpful information has been added with the 2021 Authorization Boundary Guidance draft:

• Appendices providing guidance on developing ABDs, Network Diagrams, and Data Flow Diagrams.
• Handy checklist for ABD fundamentals.
• A FAQ section.
• Data type use cases.

Who Should Work on Defining the Authorization Boundary?

Per NIST SP 800-37 Task P-11, the Authorizing Official determines the authorization boundary of the system, supported by the following roles or equivalents:

• Chief Information Officer
• Mission or Business Owner
• System Owner
• Senior Agency Information Security Officer
• Senior Agency Official for Privacy
• Enterprise Architect

What’s In Scope for the Authorization Boundary?

The authorization boundary includes:

• Federal information that is processed, stored, or transmitted by or for the Federal government, in any medium or form.
• External services that impact the confidentiality, integrity, and availability of Federal information.

Here are some examples of things that are in scope:

• Federal HR/personnel information.
• Taxpayer/citizen information.
• Federal court information.
• Configuration data.
• Incident response data.
• Interconnections and access methods.

What’s NOT In Scope for the Authorization Boundary?

The following are not in scope for the authorization boundary:

• Corporate services that do not affect the confidentiality, integrity, and availability of Federal information.
• Development environments that do not process, store, or transmit Federal information.

Examples include:

• Sales data.
• IT utilization and performance data.
• Marketing materials.

It’s important to note that data outside of the authorization boundary must still be protected. This data must “be accounted for, adequately protected, and documented by the Cloud Service Provider within applicable FedRAMP deliverables”.

Authorization Boundary Diagrams Guidance

FedRAMP provides the following guidance for ABDs:

• CSPs must clearly define the authorization boundary of the Cloud Service Offering (CSO) by creating an ABD.
• ABDs should provide a clear visual representation of what is being secured, tested, and authorized.
• Every tool, service, or component that is mentioned in the System Security Plan (SSP) should appear on the ABD.
• Additional FedRAMP diagrams like Network and Data Flow diagrams should be based on the ABD.
• ABDs should depict areas that may require risk-acceptance or where the agency has responsibility (e.g., devices that reside in the customer’s environment, system interconnections, APIs, external cloud services, etc.).
• External systems/services that provide functionality to the CSO, or are used to manage and operate the CSO, should be included on the ABD. This includes underlying IaaS/PaaS/SaaS offerings, system interconnections, APIs, external cloud services, and corporate shared services.
• System components, services, or devices that reside in the customer’s environment may be in boundary or out.

ABD Necessities

Based on our extensive experience helping our clients achieve FedRAMP authorization, here are necessary ingredients for a successful ABD:

• Include a clearly defined authorization boundary (typically a prominent RED border).
• Include system interconnections used to operate and support the intended mission/business functions.
• Depict every tool, service, or component that is mentioned in the SSP narratives.
• Identify those depicted tools, services, or components as either external or internal to the boundary.
• Identify all interconnected systems, and whether they are FedRAMP-authorized or not.
• Depict how the CSP and Customer/Agency accesses the service (e.g., authentication used to access service).
• Depict all major software/virtual components (or groups of) within the boundary.
• Be validated against the asset inventory.
• Show alternate processing site(s).
• Show pulling of updates from external services such as OS and anti-virus updates.

Important of Having a Good Asset Inventory

We cannot emphasize enough the importance of having a good asset inventory. A lot of the ABD effort should be focused on accurately documenting assets. In our experience, many cybersecurity problems can be traced back to having a poor asset inventory.

Boundary Guidance Checklist

The 2021 draft of the Authorization Boundary Guidance document provides a helpful checklist of FedRAMP’s ABD requirements in Appendix A.

Authorization Boundary Diagrams Example

Here’s an example of an ABD diagram:

Network Diagram Guidance

FedRAMP provides the following checklist for developing Network Diagrams:

• Address all components reflected in the ABD.
• Depict subnetting.
• Depict location of DNS servers including:
  • External authoritative servers used by customers.
  • Internal recursive servers used to access domains outside the boundary.
• Both External and Internal DNS servers should support DNSSEC.

The network diagram should mostly be based on the ABD, as they share many of the main requirements. The most significant difference is that the network diagram should illustrate the logical network separation and communication within the organization’s network devices such as routers, firewalls, nodes, etc. It should include both virtual and physical devices within the organization’s environment. Like the ABD, it should be updated and reviewed regularly.

Network Diagram Example

Below is a Network Diagram example. Compared with the previous diagram, we added items specific to the network, showing how network traffic is routed. For example, we now see network access control lists and a network router behind the first firewall.

Data Flow Diagram Guidance

The Data Flow Diagram should be based on the ABD and Network Diagrams, as they share many of the same components. It should depict and identify areas where Federal data is processed, stored, or transmitted. It should also show how Federal data is protected while at rest and in transit and how the organization’s admins and customers access the system, including authentication methods and ports/protocols.

The Data Flow Diagram is the most data-dense diagram, so it’s OK to use several diagrams to show separate layers of information—like a transparency on top of a map.

Data Flow Diagrams should address all components reflected in the ABD. At a minimum, System Security Plans should include diagrams for the following logical data flows:

• Customer user and customer admin authentication, including type of multi-factor authentication (MFA).
• CSP administrative and support personal authentication, including type of MFA.
• System application data flow within the authorization boundary.
• System application data flow to/from:
  • External services, including corporate shared services.
  • Interconnected systems.
  • Alternate processing sites and backup storage.
  • Dev/test environments.

Data Flow Diagrams should explicitly identify:

• Everywhere (external and internal) Federal data and Federal metadata at rest and in transit is not protected through encryption.
• Everywhere data is protected through encryption.
• Whether or not the encryption is using FIPS-validated cryptographic modules.

Somewhere in your documentation, you should describe the encryption protocol(s) and encryption technology used.

Data Flow Diagram Example

Below is a Data Flow Diagram example. We can now see more changes when compared to the past two diagrams. We see how data moves between nodes and subnets and how it comes into and out of the cloud network. We also see what ports and protocols are used to access the system between the admins, security analysts, and end-users.

Data Flow Diagram Example

Common Pitfalls of Data Flow Diagrams

In our experience helping clients develop Data Flow Diagrams, we’ve seen many pitfalls. Here are some of the most common ones:

• Does not depict all access by all parties (e.g., Agency customers, IaaS/PaaS portal).
• Does not indicate MFA tools and protocols (OTP, push, etc.) employed for admin/support personnel and customers.
• Lacks port and protocol information.
• Does not indicate encryption of data in transit and data at rest.
• Does not indicate use of FIPS-validated cryptography.
• Fails to include internal flows such as to data stores, or within a microservices environment.
• Fails to address replication of data to alternate processing sites or to backup storage.
• Does not include a legend.

References

Here are key references with more detailed authorization boundary guidance:

• FedRAMP Authorization Boundary Guidance 1.0.
• FedRAMP Authorization Boundary Guidance 2.0 (July 2021 draft).

Tevora Can Help

If you have questions about the FedRAMP authorization process or would like to engage Tevora as a 3PAO for FedRAMP Certification or  performing a FedRAMP Readiness Assessment, our team of FedRAMP and security experts can help. Just give us a call at (833) 292-1609 or email us at sales@tevora.com.

---

[1] Official with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to agency operations (including mission, functions, image, or reputation), agency assets, or individuals.