Project 1: FedRAMP and GovRAMP Authorization Boundary Diagrams

01 Scope

01a Authentication = First Ingress Point

Questions:

• How do you authenticate into your system?
• Do you use just a username and password or does your site have MFA?
• Do you use a SSO that you built or do you rely on a 3rd party SSO?
• Are you using tools that belong to your site’s infrastructure service provider like Azure Entra?

Let’s draw it and discover:

For this project I am using draw.io without any subscription. This is not a good option for diagramming an actual sensitive system. You will want to use a subscription based tool (Draw.io has some options, but so does Visio, and Lucidchart) so that your data is isolated from the data of other entities.

In this diagram I have included some basic concepts:

• a diagram title–this is a UML diagram overview container
• a symbolic system– this will get more detailed as we go
• the login, aka authentication methods, of the expected users to the system
  • an employee–someone who works to develop, maintain, or protect the system and has Role Based Access
  • any other user–this would include the expected customers of the web-based product and/or the public viewers in the case of a website
    • Some of these are going to be privileged users like customer administrators
    • Some will be just visitors or potentially unauthenticated users. Unauthenticated users should never have access to the system. If you have some, well full stop. That must be corrected. And your attempt at drawing an Authorization Boundary Diagram has just proven exceptionally valuable to the security of your system.
    • You may need to add additional users to encompass all the user types

A deeper dive

Now that you have identified who authenticates and some basic details as to how they authenticate. Let’s determine if any of your process should be inside the authorization boundary of your system. Remember the red dotted line shows everything you have control over. So if you have developed the authentication process yourself, for example a self-built login page with a password and MFA email, this will need to be inside the boundary. The servers associated with hosting that page and the email server should be inside the boundary.

Stuff you don’t manage is outside the boundary. What we are looking for here is information on what data is shared with 3rd parties and if those 3rd party identity providers live in secure systems. For the purpose of FedRamp/ GovRamp, those IdP providers must have their own FedRamp or GovRamp certifications for you to become authorized with FedRamp/ GovRamp. What that means, is it shows you have considered your supply chain and there are no weak links. The infrastructure you use are also certified to meet NIST 800-53 rev 5 guidance. However, if that is not the case, and the Identity provider is not FedRamp/GovRamp Certified, you may still be able to be certified as GovRamp Ready. FedRamp Ready is on the out, so you should discuss plans to remediate your IdP with FedRamp or GovRamp to determine next steps.

Let me show you. You are looking to identify anything that is supposed to be inside the red dotted line. Or identify potential areas of improvement when using external IdPs without their own certifications.

Here we are identifying what goes inside, what is okay staying outside (FedRamp certified IdPs), and what is a potential roadblock to FedRamp/GovRamp.

RETURN TO TOP

01b Where’s the Data?? Fed Data & SLED Ingress/Egress

After considering the people who access your system, it is time to consider the data.

No we are not doing the data flow diagram yet, and yes we are putting the horse ahead of the cart. A Data Flow diagram is a separate but related diagram that we will get into later. However, the reason I state to consider your data, when you think about what data comes into and goes out of the system, it helps you find all the entities that store, manage and process the Federal (Fed) or SLED data. We are talking inventory just yet either…we will get into INVENTORY soon.

For now this is a mental exercise, to get you thinking about what details you need to put in your scope.

When considering Data in relationship to the Authorization Boundary, you must think about how the data enters and leaves the system. Where does it enter and where does it leave? These are your API interfaces, your network gateways, and your connections to any other systems, even a peering connection. To identify the where data enters and exits, we must first identify what data are we talking about? Most of the time you will think of the high value data contained in your system, web content, data belonging to your customers, but this also includes meta data too. Meta data can include message queues used to run your system efficiently, it can include cookies, and it can include SIEM scanning. Identifying the data in your system, will help you know what to look for when identifying the ingress/egress points.

Federal Data

While FedRamp and GovRamp operate in almost identical patterns, the specific rules for the Authorization Boundary Diagrams are almost verbatim, there are a few key differences. For a full visual break down see this page, FedRamp and GovRamp AB Diagram Comparisons, here I want to focus on the subtle differences regarding Data Definitions. NIST Risk Management Framework (RFM), NIST 800-37, does not specifically define data as I will here. It is more focused on the creation of a data map and the proper identification and handling of data as determined by the Information owner/ steward. There is a broad definition of what is included in Federal data available in FedRamp’s RFC-0004 Boundary Policy.

The policy is currently being re-written and may have more specific information listed in the future, but for now, we have this definition:

• handle federal information; and/or
• directly impact the confidentiality, integrity, or availability of federal information

FedRamp is clear that if the data flowing out of the Authorization Boundary affects the CIA triad. The Confidentiality, Integrity, and Availability of Federal Data, it must be in scope of the service provider’s control or only traveling to systems with their own FedRamp Compliance. Thus securing the supply chain. There are exceptions with valid supporting documentation that can be applied for with the Authorizing Official and those should be discussed in detail with an 3PAO auditor.

The gist of SLED and the authorization boundary diagram is any State, Local, or Education Data leaving your system must only be sent to entities that maintain their own GovRamp or FedRamp certifications. This is the bare bones of supply chain due diligence. When it comes to handling SLED data , you must ensure it is only shared with safe systems. In this case, we mean systems certified to meet NIST 800-53 standards.

Now if you do find not all your external systems are credentialed via FedRamp or StateRamp, that is okay. You will develop a Plan of Action to remediate the issue or you may decide the Certifications are too costly to seek at this point in time. Yet, that is a bigger discussion. For now, the diagram will help you figure out any non-compliant connections.

01c External Connections

First consider inbound data (ingress points). Authentication was one type of an interconnected system with inbound sensitive personally identifiable information (SPII), if we are discussing a federal system, this data may have more formalized terms, such as Derived Personal Identity Verification (PIV) Credentials.

Next consider outbound data (egress points.) To become FedRamp or GovRamp authorized you cannot share Federal date or SLED data to any external systems that lack either a FedRamp or GovRamp certification.

RETURN TO TOP

02 Inventory

Before I describe the inventory process, I have an example. This is a hodgepodge and a midpoint level Authorization Boundary diagram.

• Hodgepodge because this is not a real system and clearly, sorry system architects, makes no sense. But it gives examples of different elements that may need to be included in your Authorization Boundary Diagram. I’ve spliced together Azure, AWS and data center elements, so forgive me. It is just a talking point.
• Midpoint because it is not finished but gives you just enough to understand what needs to be included.

What should be included in any Authorization Boundary Diagram:

• The diagram structural elements:
  • A title and date
  • A red dotted line for the authorization boundary
  • A legend (although I didn’t not complete it).
• The system structural elements:
  • Ingress/Egress points including gateways and APIs
  • Cloud architectural items like Vnets, VPCs and subnets
  • Infrastructure items such as Virtual machines, VPNs, specialized gateways, Cache Servers, Web Servers, Database Servers, File Servers, Load Balancers
  • Any environment that does or may contain SLED data: such as a staging environment that has your client’s data to show them the proposed website before it goes to production or the backup-recovery network intended as a cold, warm or hot site but can, when in use, have SLED data.
  • Any external systems and if they are FedRamp or GovRamp Authorized. This will be further explored when we get to the network and data flow diagrams. For now it is enough they just exist on the diagram.

Authorization Boundary Diagram at Midpoint to completion

03 Review

Let’s review all the elements to see if we found them all. Here is my Inventory list for my fictional system.

• Cloud Architecture:
• Systems Leveraged from AWS Infrastructure:
• External systems

Then we check the list against the requirements list in the Authorization Boundary Diagram Guidance.

Finally, satisfied I capture the end result and paste into the OCM….and this is what it looks like:

GovRamp Authorization Boundary Guidance

RETURN TO TOP