Who is allowed to work on the system or access SSP documentation?
 

Note: This is part 4 of a multi-part series. See the links below for other topics in the series.

Today we will address questions around handling and security of the FedRAMP System Security Plan (SSP) and related documentation, as well as who is allowed access to components within the system boundary. This includes that ever pervasive question, “can non-US Persons / non-US Citizens work on / in a FedRAMP cloud?”

What about US Citizens / US Persons?

Regarding the citizenship question, the FedRAMP PMO has clarified that there is no overall Federal requirement about citizenship. They did warn however, that the decision to use non-US personnel to support the system may limit the market reach of the cloud service.

The theme here is the same as what we discussed in part 2 of this series.  It is up to the cloud provider to provide a cloud offering that meets the security and functional requirements of its target market. In some cases, a cloud provider may want to have several versions of its cloud service, hosted in enclaves that support the requirements of different federal market segments. With all of this in mind, it is instructive to look to the industry to see what other CSPs are doing in this regard. We will look at the largest IaaS and SaaS providers, Amazon Web Services (AWS) and Office365 respectively.

From the AWS GovCloud FAQ, we can see that AWS GovCloud was built for the express purpose of hosting environments with high security requirements and restrictions to US Persons only including those who need to comply with International Traffic in Arms Regulations (ITAR).

AWS also has a FedRAMP P-ATO for AWS East/West to support customers who have moderate-level systems and do not require these restrictions.

Similarly, from the Office365 US Government Service Description, we can see that the Office365 GCC High and DoD was established for customers hosting DFARS, ITAR and other high security environments. Microsoft also has a moderate P-ATO for its Office365 GCC (standard) offering.

From this pattern we can see a strategy emerge for extending cloud services to the broadest market possible. This strategy is to achieve a moderate sensitivity level P-ATO for the cloud service with a more open community cloud or public cloud deployment model. Then create a separate enclave with a high sensitivity level P-ATO for a restricted community cloud deployment model.

Many organizations face the challenge of having to create an operational unit to handle the US persons only requirement.  InfusionPoints maintains a FedRAMP / ITAR compliant Security Operations Center (SOC) where we have developed, operated, and monitored FedRAMP JAB Accredited Cloud Services and DFARS / ITAR enclaves for our customers for over four years. We can help augment your support team to help you meet these requirements.

What about protecting system documentation?

From our previous topic regarding the classification of the SSP, we learned that the government considers the SSP and accompanying FedRAMP documentation to be Controlled Unclassified Information (CUI). CUI falls under NIST 800-171 data protection requirements and DFARS 7012.

As such, documents that are in draft and that exist prior to an organization achieving P-ATO should begin being treated with appropriate levels of protection as specified by their data classification. Even if sensitive information is not yet available in the documents, it is difficult to track when this threshold has been crossed. An organization should establish the correct data protection procedures / controls and an adequate audit trail to demonstrate appropriate levels of data protection once sensitive information is available in the documentation in later drafts.

Also, because system documentation is categorized as a CI as stipulated by guidance in NIST 800-128, it can be assumed that the system’s categorization and personnel security requirements apply to system documentation as well as it is considered “in boundary” in terms of system scope.  Our best practice recommendation is that access to system documentation should include a full read-in process including;

• any relevant background investigations (PS-3),
• citizenship verification (determined by CSP target market agency requirements as a high-water mark),
• role-based training and security briefings (AT-3),
• review and signature of rules of behavior (PL-4), and
• and debriefings on departure of the program (PS-4(1), PS-6(3)).

Regarding where system documentation may be stored, NIST 800-171 data protection requirements come into scope. While NIST 800-171 has not been interpreted from the civilian side as to how it applies to which cloud systems may be used to store this information, the DFARS 7012 rules establish that external cloud services used to store, process, or transmit covered defense information meet the FedRAMP Moderate baseline:

Note that “covered defense information” (CDI) is considered to align to CUI which corresponds with the classification of the FedRAMP SSP documents. Our best practice, is that storage of the SSP and associated documentation be NIST 800-171 compliant at minimum. If cloud services are used for this purpose, use those with FedRAMP Moderate P-ATOs.

Use the links below for other topics in this series.

• Part 1 - Is an NDA with FedRAMP needed to protect my company’s trade secrets?
• Part 2 - If I follow FedRAMP requirements and get a pATO, my cloud service will be well designed and attractive to Federal Agencies, right?
• Part 3 - Is system documentation included in the system boundary? What classification should be placed on our system security plan and overall package?
• Part 4 – Who is allowed to work on the system or access the SSP documentation? What about non-US Persons / non-US Citizens?
• Part 5 - What is required to accomplish continuous monitoring, and how can we prepare?
• Part 6 - How should I classify my system?