My thoughts on FedRAMP's "Authorization Boundary Guidance"
Published: 2021-09-14 12:45:20

Ok, this is pretty dry, but I need to start somewhere with blogging again.  As compliance lead for cloud.gov, I'm seeing the biggest opportunity for impact is to start nudging US government on policy, in addition to my work to defend our customers and demonstrate that in our compliance regime. A lot excellent policy proposals desperately need feedback based on real-world experience securing a modestly-staffed, publicly-operated, multi-tenant cloud -- and that's me(!)

This is my response to [FedRAMP's call for comments](https://www.fedramp.gov/blog/2021-07-14-Public-Comment-Boundary-Guidance/) on proposed new [FedRAMP authorization boundary guidance](https://www.fedramp.gov/assets/resources/documents/CSP_A_FedRAMP_Authorization_Boundary_Guidance.pdf).  

---

Thanks for inviting these requests for comments on the FedRAMP Authorization Boundary Guidance (FedRAMP ABD) document. I’m writing as the ISSO and compliance lead for cloud.gov, a FedRAMP JAB-authorized cloud service provider. These comments reflect my perspective working for a government-operated CSP, and are not the views of TTS Solutions or the General Services Administration. 

Key points:

**The document needs to distinguish** between “federal data” and “federal customer data”, “federal metadata” and “federal customer metadata”. Although cloud.gov is the only federally-operated JAB-authorized CSP, there will likely be others as the need grows for the US government to provide cloud services. These services will, by definition, wholly comprise federal data and federal metadata. However, there is a key distinction between the metadata a federal CSP manages on its own behalf and the metadata of the CSP’s federal customers.

As it now stands, the restrictions on “federal metadata” could be interpreted as meaning federally-operated CSPs could not share their own architecture plans, product roadmap, etc.

*Suggestion*: Use the terms “federal customer data” and “federal customer metadata” throughout, but it may suffice to distinguish between “federal CSP metadata” and “federal customer metadata”, etc, when those terms are defined.

**The FedRAMP ABD needs to account** for the exchange of federal metadata that are mandated by law or executive order. For example, CSPs are presently required to exchange POA&M trackers and vulnerability scans with FedRAMP via Max.gov, but Max.gov is not JAB-authorized. Emerging guidance from OMB will mandate exchange of vulnerability data and audit logs with CISA -- which likewise may not have a FedRAMP JAB-authorization prior to those mandates being in effect. 

As the ABD now stands, CSPs would no longer be permitted to share information with FedRAMP via Max.gov. Nor could federal CSPs ship operational logs to CISA, per mandate, until CISA’s services were themselves authorized.

We should support the efforts of cloud.gov and other CSPs to make sharing with CISA a partially- or fully-inherited control. But the ABD as currently written seems to forbid such sharing. 

*Suggestion*: Note which types of mandated data exchanges will be permitted under this guidance, or note that this guidance will see timely updates as new mandates emerge.

**Corporate systems**: In general, these systems need more careful consideration on what types of data are stored or processed by them, and what the potential impacts are. For example, in page two the guidance seems highly burdensome: 


> “Some sensitive federal metadata can be authorized to reside in corporate systems that are wholly owned by the CSO.”


Requiring separate corporate systems for each CSO  is an undue burden and unnecessarily duplicative. If a customer could potentially email a CSP with a question that included federal customer metadata, like “Will this architecture work on your cloud?”, will that entire email system need to conform with all of the data restrictions? Will each CSP have to have a separate email service for each CSO? 

It seems these systems should be wholly owned by by the cloud service provider (CSP)

    
On the other hand, the document indicates that federal customer billing data can reside on “External non-FedRAMP authorized services”, (Appendix C, page 14) but it’s well known that billing data are a proxy for system architecture data: (https://twitter.com/quinnypig/status/1367290581345464321 -- see also https://twitter.com/QuinnyPig/status/1367571707825856512 



*Suggestion*: The FedRAMP PMO should revisit corporate systems usage in conjunction with CSPs to better understand how these systems and data work together and what constitutes acceptable risk.

**Section 5, External Services in the Cloud**
Clarification needed for “Item of Note”. This currently reads:
“External services may or may not have a pre-existing FedRAMP Authorization unless they are processing federal data or metadata”

I think this means: 

> External services processing federal customer metadata or federal customer data must have a pre-existing FedRAMP Authorization. Services that are not processing such data or metadata may not necessarily require FedRAMP authorization.


Suggestion: If the interpretation is correct, please use that language. If the interpretation is incorrect, then please rewrite with the meaning clarified.


**Appendix A**:
The checklist for the ABD should address the following questions:

* For the ABD to be readable, can it be provided at sizes larger than 8 ½ x 11? Larger than 11 x 17? What’s the maximum page format?
* Can components of the ABD be broken out into separate sub-diagrams?


**Appendix C**: 

This appendix needs to differentiate between CSP data, and federal customer metadata. For many of these categories, they will likely both be “Inside FedRAMP Authorization Boundary” but for other categories this isn’t clear. For example, is “DNS Data” referring to the federal customers’ DNS, or the CSO’s DNS? Likewise for change control tickets. 

The last line mentions “High Repositories” but doesn’t define that term.

**General formatting and readability**

While this document is generally clear and readable, more of the principles from plainlanguage.gov could be applied, especially breaking down long lists into bullet points, e.g., the many types of federal customer metadata on page 3, section 3. 

The document has style and grammar inconsistencies. A few examples:

* Page 2, first line: should read “at the same or higher FIPS-199 impact level” (italicized words are missing in the original)
* Page 4, first sentence: words have been omitted or replaced
* Page 4, last sentence: The sentence has no subject (unless “cloud technologies” is the subject, which is nonsensical in context of who “must document, test and monitor”).

*Suggestion*: Make use of the TTS Writing Lab: https://handbook.tts.gsa.gov/getting-started/classes/writing-lab/

--
Ok, that's all. Coming soon will be my response to OMB's Federal Zero Trust Strategy: https://zerotrust.cyber.gov/federal-zero-trust-strategy/. But first I hope to write about how I do character generation when I DM D&D -- so, like life, every character is a combination of destiny, luck and grit.  👋🏻