This article is the second of a series in the Microsoft Tech Community Public Sector Blog and touches on several key principles for compliance, including data residency versus data sovereignty. For the first article in the series, please refer to History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government.
We will focus on each of the US-based cloud offerings from Microsoft and compare the differences in compliance. In order to keep this article concise, I will refrain from repeating content from the first article.
You can demonstrate compliance with the FedRAMP Moderate Impact Level in Microsoft 365 Commercial. It is even more impressive to note that you can demonstrate compliance with FedRAMP High in Azure Commercial. We do have accreditation from the Department of Health and Human Services (DHHS) for “Microsoft - Office 365 Multi-Tenant & Supporting Services”. This Provisional Authority to Operate (P-ATO) is for a GCC tenancy, but GCC is a data enclave of Commercial, effectively extending the accreditation to the whole of the Commercial cloud.
Note: For context of what a ‘data enclave’ is, please refer to the History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government
We advertise that we have FedRAMP Moderate ‘equivalency’ in Microsoft 365 Commercial. Microsoft validates the controls for Microsoft 365 into FedRAMP holistically because we operate all instances of Office 365 employing a consistent control framework and uniform implementations of controls based on NIST 800-53 (a requirement of FedRAMP).
I often get pulled into customer conversations on suitability for Controlled Unclassified Information (CUI) in the Commercial cloud. The common misconception by many is regarding FedRAMP. Yes, you can demonstrate compliance with FedRAMP Moderate in Microsoft 365 Commercial. However, not all FedRAMP / NIST 800-53 implementations are the same. The way Microsoft implements FedRAMP Moderate in Commercial is not the same as other Cloud Service Providers (CSP’s). Ultimately, FedRAMP Moderate is not the high bar for compliance with any CSP. It does not guarantee fulfillment of US Persons nor US Citizenship requirements, nor does it confer data residency in CONUS.
However, customers think they are getting something that they are not, just from that label.
Commercial was not built for the regulations and standards that govern CUI. Thus, in the table above, you can observe that CUI is presented as ‘No’.
The way I frame this out for customers is this: your higher bar for compliance to gain coverage of CUI is in alignment with other controls above and beyond FedRAMP. If you are affiliated with law enforcement and the criminal justice system, you will likely require CJIS adjudication from the FBI or from the US State you are in. If you are affiliated with the Internal Revenue Service or Department of Revenue, you will likely require IRS 1075 for coverage of Federal Tax Information. If you are affiliated with U.S. Defense or Military, you will likely require export controls that include the International Traffic in Arms Regulation (ITAR) and Export Administration Regulations (EAR). Each one of these require screened US persons and data residency/sovereignty in CONUS. These are what will direct you to our Government cloud solutions and diminish Commercial as an option.
This is for the Defense Industrial Base (DIB) including aerospace and defense contractors of the US Department of Defense (DoD). To contract with the DoD, you must demonstrate compliance with the Defense Federal Acquisition Regulation Supplement 252.204-7012 (DFARS). DFARS mandates the implementation of NIST 800-171 and FedRamp Moderate Impact Level for Commercial clouds. It is a set of controls that are used to secure Non-Federal Information Systems (commercial systems). NIST 800-171 is derived from NIST 800-53. Think of it as a subset of the controls that apply to the DIB. Given Microsoft uniformly implements NIST 800-53 in all of our clouds, undoubtedly, we have coverage for NIST 800-171 controls in Commercial. However, there are differences in the System Security Plan (SSP) Organizational Defined Values (ODV’s) for Commercial than you will find in our Government cloud solutions. Namely, the ODV’s in Commercial are designed for a global service. There are control differences that make supporting DFARS clause 252.204-7012 sub-paragraphs (c)-(g) much less tenable in Commercial. Log retention is not in compliance across all services in Commercial; tenant guidance for log configurations differs, incident response times differ and other ODV’s differ that contribute to how we could enable support for (c)-(g). We say ‘Maybe’ because it’s not completely out of the question that you could supplement our service, such as log retention in a customer managed Security Information and Event Management (SIEM) solution (e.g. Azure Sentinel, Splunk, etc.). However, Microsoft does not demonstrate compliance with NIST 800-171 out-of-the-box in Commercial.
As I mentioned, there are guidance, operational and support differences between the services provided for Commercial as opposed to those built for the US Government. There is no way to identify a government tenant within the Commercial service.
This is a painful learning curve when a customer discovers this post sale/deployment while in the middle of an incident. I have been on calls assisting such customers that were routed through our global support staff and were frustrated that ‘Microsoft’ did not understand that they had US Government requirements and shouldn’t have been routed to offshore support personnel in Asia. That is how the Commercial service works. If you have requirements for screened US Persons, Microsoft built services exclusively for the US Government that are suitable to sovereignty requirements.
GCC is a data enclave of Commercial. A data enclave in this context is a logically segregated environment, with servers residing in regional Azure data centers. In the case of GCC, the data enclave is in CONUS. There is a contractual commitment to ensure data residency for the primary Office workloads administered by screened US Persons for access to customer data. This includes data processing specific to the covered workloads (e.g. Exchange Online Protection).
The service description for all Microsoft 365 US Government offerings may be found at http://aka.ms/o365usgovservicedescription
At the time of this writing, the service availability for GCC covered workloads are:
Given GCC is a data enclave of Commercial, there are several shared services. These shared services may have data processing Outside the Continental United States (OCONUS) and leverage a global follow-the-sun support model. Most notably, this includes a global network and a global directory. For example, Azure Active Directory (AAD) in Commercial is shared with GCC. AAD replicates globally and may have data processing (authentication) occur OCONUS along with service management by global support personnel. For this reason, Microsoft will not contractually commit to export controls in GCC.
As a result, you may observe a ‘No’ in the column for ITAR & EAR for GCC.
There is an outstanding benefit for the shared services with Commercial. GCC has ubiquitous access to the global catalog of integrated applications, including the AAD App Gallery and the Azure Marketplace in Commercial. The best illustration of this benefit is access to Microsoft solutions to include Visual Studio Online, the Microsoft Developer Network (MSDN) and Azure DevOps in Azure Commercial. This is not the case with the US Sovereign Cloud. Consequently, tenants in the US Sovereign Cloud must deploy Commercial or GCC tenants to provide access into these Commercial services that are not deployed into the US Sovereign Cloud accreditation boundary.
In GCC covered workloads, we can demonstrate support for DFARS clause 252.204-7012 sub-paragraphs (c)-(g). We have an auditor’s attestation letter that shows on two pages summarizing how those sub-paragraphs are supported, but we will not sign a contractual flow-down. Why? Because we did not build GCC (nor Commercial) for this purpose. You will not get a contractual agreement from Microsoft to support DFARS in GCC, nor to demonstrate DFARS compliance with your customers, vendors and partners. The primary gap includes the scope of services that fall outside the covered workloads for GCC.
The NIST 800-60 Volume 2 registry is rather large. There are 20 CUI categories as of the latest revision, to include many information types. The question is, which CUI category is in scope? Several categories may not require data sovereignty, such as Privacy, Legal, etc. Is it permissible to rely on data residency in GCC? Maybe. However, many of the CUI categories to include Defense, Export Control, Nuclear, etc. undoubtedly require the US Sovereign cloud and are not appropriate for storage within GCC. Ultimately, customers are responsible for ensuring that they review the relevant regulations and Microsoft's offering prior to determining which Microsoft Government Cloud Service is the best fit to support their obligations for CUI.
The most predominant tenant populations in GCC include State and Local Government (SLG) entities, such as highway patrol, sheriff, local law enforcement, etc. that require CJIS. The CJIS security policy provides 13 areas that should be evaluated to determine if cloud services can be used and are consistent with CJIS requirements. These areas correspond closely to the NIST 800-53 control implementation for FedRAMP Moderate with a security policy aligning with CJIS.
Microsoft will sign the CJIS Security Addendum in states with CJIS Information Agreements. These tell state law enforcement authorities responsible for compliance with CJIS Security Policy how Microsoft's cloud security controls help protect the full lifecycle of data and ensure appropriate background screening of operating personnel with access to CJI. Microsoft continues to work with state governments to enter into CJIS Information Agreements.
Microsoft has assessed the operational policies and procedures of Microsoft Azure Government, Microsoft Office 365 U.S. Government, and Microsoft Dynamics 365 U.S. Government, and will attest to their ability in the applicable services agreements to meet FBI requirements for the use of in-scope services.
36 states and the District of Columbia with management agreements, highlighted on the map in green include:
Alabama, Alaska, Arkansas, Arizona, California, Colorado, Florida, Georgia, Hawaii, Illinois, Indiana, Iowa, Kansas, Kentucky, Maine, Massachusetts, Michigan, Minnesota, Missouri, Montana, New Jersey, New York, Nevada, North Carolina, Oklahoma, Oregon, Pennsylvania, Rhode Island, South Carolina, Tennessee, Texas, Utah, Vermont, Virginia, Washington, Washington D.C., West Virginia.
Microsoft's commitment to meeting the applicable CJIS regulatory controls allows Criminal Justice organizations to implement cloud-based solutions and be compliant with CJIS Security Policy V5.7.
Current as of 04/18/2019
This service was built for export controls in the US, to include ITAR and EAR. I have customers interpret that GCC is suitable for export controls. I've even had customers decide that Commercial is sufficient. I tell them that I am not a lawyer, and I cannot give you legal counsel, but I think that is extremely unwise. I can't stop you from leveraging Commercial or GCC for CUI categorized as Export Control, especially for ITAR. I hope you take advantage of every data protection feature that we offer you! GCC High was created to give you a contractual assurance for export controls in the US. This includes a US Sovereign Cloud accreditation boundary encompassing all services attached to GCC High. For example, the network is sovereign and constrained to CONUS. The directory services with AAD are provided by Azure Government and are sovereign to the US.
We have evolved the US Sovereign Cloud to include PII protections. PII protections are now all the way up to IL4 in GCC High. This is significant. If you know you will have PII on a contract and going after new business, are you going after it with IL4, or just IL2? This can be a competitive advantage if you can demonstrate IL4. There is a good likelihood that your customer will be more IL4 oriented, or already consuming our IL4 and IL5 clouds.
Microsoft will sign a contractual Flow-Down for DFARS in GCC High. This translates to a contractual commitment where we demonstrate DFARS compliance in the US Sovereign Cloud. This includes DFARS alignment with NIST 800-171 in a shared responsibility model with the Customer. Given that Microsoft uniformly implements NIST 800-53 in all of our clouds, the SSP ODV’s for FedRAMP High in GCC High are designed to demonstrate compliance with DFARS.
GCC High complies with DFARS clause 252.204-7012 sub-paragraphs (c)-(g), except as follows:
At the time of this writing, GCC High currently has a FedRAMP Agency ATO at the Moderate Impact Level from the Department of Justice (DOJ) and successfully completed two FedRAMP High Impact Level audits. We have several Federal Agencies actively deployed in GCC High, demonstrating compliance with FedRAMP High. The FedRAMP High ATO is pending finalization in the FedRAMP Marketplace.
Today, you can demonstrate compliance with FedRAMP High in GCC High and in Azure Government. However, the High Impact Level is not a requirement for DFARS Compliance. FedRAMP Moderate is specifically required for DFARS. And for that, we do have an Agency ATO currently in place covering GCC High.
Microsoft has engaged with multiple entities obligated to demonstrate compliance requirements of the North American Electric Reliability Corporation (NERC) and/or the Federal Energy Regulatory Commission (FERC). They find M365 GCC High and Azure Government to be the closest match of Microsoft cloud service offerings to fulfill their requirements. Due to the dynamic scope of applicability that an entity may define, we recommend you request explicit support from your Microsoft account team if you have compliance requirements in this area.
If you are not in the DoD, don't worry about it. You're not getting into the service. Only the DoD and those approved by them (such as service providers or entities authorized by the DoD) are allowed into the IL5 environment.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.