Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings

RichardWakeman Thank you!

John_Igbokwe The accreditation boundary for the US Sovereign Cloud surrounds all of Azure Government and Microsoft 365 Government (GCC High).  Think of Microsoft 365 as being the superset of SaaS solutions, packaging Office 365, EMS and Windows 10 Enterprise.  As such, any of the components (e.g. Office 365) may be transacted separately, but are still within the same accreditation boundary for GCC High.

Terry_Hebert - apologies for length of time to answer your 6/20 question and thanks for the reminders 😉

Rephrased: "How do we address the DFARs 7012(e) requirement regarding image retention and packet capture?"

This was initially an area of concern for exactly the point you brought up. Cloud data architecture for hyperscale providers typically cannot fulfill this requirement _as written_ in any commercially feasible manner. That said; the objective of the requirement can be met. This has often been a 'fundamentals' topic of discussion as it supports many other discussions than just this DFARs rule. So let's walk through the details for a deeper understanding to enable y'all to have this discussion and understand both why & how this is achieved differently than written. 

Data Architecture Challenge: Cloud data architecture often involved various forms of 'chunking' data into small portions and distributing it across a wide array of infrastructure. This actually results in improved performance and resiliency. It has an added benefit of providing another layer of abstraction against attackers due to the data 'chunks' often being encrypted and therefore requiring decryption and indexing for any meaningful reconstruction. An unintended benefit is that now a single blob object such as a file of interest from a CUI/DFARs/CDI perspective may be stored across dozens or hundreds of physical devices depending on the size of the document. Multiply this by the number of documents possibly impacted in the investigation of an incident and it can result in thousands of physical &/or virtual devices being 'in scope' in the literal translation of this requirement. So let's keep that in mind as we discuss the next point. 

Forensic/Investigation scope of analysis Challenge: Another 'fundamentals' issue is clear understanding of the difference between the scope of responsibility in the investigation of an incident from the tenant vs service provider perspective. Pulling back a bit the first important concept to embrace when assessing scope of responsibility is to understand scope of management responsibility (think section 9 of a SSP where the accreditation boundary is defined by the entity). This understanding allows a bright line to be accepted between the scope of tenant management of the service versus service provider management of underlying systems and infrastructure. Applied to investigation this naturally progresses to where the tenant is responsible to analyze all application level log data regarding configuration and use and the service provider would analyze all system level data regarding management of the underlying infrastructure. Each party defines the context surrounding data lending itself into comprehending what an anomaly or deviation is in the context of their management of their scope of responsibility. This is important to embrace because it means that when a tenant experiences an event or incident and conducts investigation that they understand they are equipped to perform this independent of the service provider i.e. the tenant owns the data necessary to identify anomalistic, unauthorized or otherwise concerning behavior from application telemetry they should be analyzing under their scope of control responsibility already. This is also true of the service provider. And both parties possess a unique context of comprehension that cannot be easily shared i.e. even if a service provider shared all the underlying system log data (often inappropriate for multi-tenancy systems) the tenant lacks the architectural understanding of service construction and deployment to accurately assess issues. The same is true for the service provider as they cannot identify what the tenant has (or has not) authorized for appropriate configuration, exception, deviation, muse patterns for groups or specific users, etc. The primary difference being that the likelihood of a tenant incident requiring notification of the service provider is much smaller than the converse. The intent of most service providers is to ensure as much autonomy of the tenant as possible and to commit to notification of the tenants if impacted by an incident in the scope of the service providers responsibility. 

So now taking just these two challenges into consideration lets assess the objective of sub paragraph (e). The intent is to ensure defensible data to facilitate accurate and defensible investigation implying that such defensibility can withstand scrutiny if the service provider or tenant needs to provide such data in support of more formal investigations under regulatory requirements. As we see in the first challenge regarding data architecture; there is no commercially feasible method of retaining 'images' of systems as it would require a complete replication of the underlying service to provide the indexing and decryption capabilities for all impacted systems. Furthermore it violates our principles to perform and packet capture of tenant actions. A service provider might do that for the behavior of their own staff in support of the service but it should be generally unaccepted that a service provider would perform packet capture and inspection of tenant traffic (unless of course that's part of a feature i.e. security features designed to analyze traffic &/or message content). Is an image the only defensible method to amass the data necessary to validate what occurred in an incident? No. Our position is that this is exactly why the AU control family exists and that between the scope of service provider and tenant responsibility that each party already has the _forensically relevant_ data necessary to conduct their respective investigations. This position also aligns nicely with the previous scope of responsibility point; because any packet capture or other retention of relevant data should be constrained to the appropriate scope of control of each party to ensure respect of boundaries. 

What is "forensically relevant" then? 

This term "forensically relevant" is important as it's the term I chose to adopt when constructing our attestation memorandum on DFARs (available for both GCC & GCCH as they rely on the same underlying controls from 800-53). In reading our attestation memorandum it can be noted that we've attempted to be clear that our intent is to support the requirements objective by ensuring retention of all "forensically relevant" information related to an incident. In this way my intent is to demonstrate adherence to the spirit of the requirement rather than the letter as the letter is simply not commercially feasible in most cloud solutions at scale. 

What does this mean for you the tenant? Probably three things: 

1) You will want to ensure you have a copy of the attestation memorandum for the service you reside in stored along with your other accreditation artifacts; and that you are comfortable being able to speak to (e) or your organization knows that if questions arise about the service providers stance that we remain available to help address them with auditors etc. Note: In my experience many auditors have become much more technically competent on these issues in the past 5-7 years but our industry is not renown for agility when it comes to adaptation of change regarding regulatory issues. So feel free to reach out as needed. 

2) You will want to ensure that your IR (Incident Response) processes reflect this understanding i.e. that IR processes regarding cloud service consumption are clear on the scope of data available to the tenants IR team(s) for analysis in contrast to the service providers scope of responsibility. I often recommend this should be rehearsed at minimum *prior* to cloud adoption but annual rehearsal supports control requirements and is a pragmatic (affordable) way to ensure the first time a tenant encounters a major incident that they are not confused about which party owns which data and what scope of investigation and why. Attempting to grasp the impact of these issues the first time in a real world incident tends to be less than ideal.

3) Healthy internal feedback between operations and investigations teams. This last point sounds like common sense but often overlooks implied issues that arise out of discussions like this i.e. the value of rehearsal and operational input on the log data being harvested for analysis. Tenants can often err to either side (too much or too little data retained for too long or not long enough etc.). Healthy internal checkpoints help ensure that the data being harvested from logs remains relevant to ongoing investigations; is retained as needed; &/or is formally modified over time as needed (even if from a lightweight governance process that generates defensible evidence of ongoing management of the data necessary to support investigations). 

I know this response was lengthy; but I hope it helped provide deeper context (for those of you that have read the attestation memos) on why the language of subparagraph (e) (or elsewhere) might deviate from the boilerplate type of language many of us grew up with managing our on-prem systems. Thanks again for your patience and polite reminders of your open question Terry. Always appreciate the keen inquiries as they help many others gain insight into the thinking behind 'why things are different'. 

RichardWakeman The "Microsoft 365 Government (GCC High)" table shows that M365 GCC High has FedRAMP High accreditation. Is the FedRAMP High accreditation for M365 GCC High only for GCC High M365 license or does the FedRAMP High accreditation also apply to other GCC High licenses such as the GCC High Office 365 E3/EMS license?

SvenAelterman Thank you for pointing this out.  I updated the map and even added another state to the list.

Minor note: the map doesn't highlight Alabama in green, though it's listed below the map as a state for CJIS.

https://techcommunity.microsoft.com/t5/public-sector-blog/understanding-compliance-between-microsoft-365-commercial-gcc/ba-p/718445#toc-hId-1125452099:~:text=CJIS%20status%20in%20the%20United%20States 

Hello RichardWakeman and Shawn_Veney.  At an event last year I asked RichardWakeman if there was any difference when declaring an incident in GCC and GCC High.   He stated that the reporting was the same.  I assume that means attestations letters for GCC and GCC High are also the same?  Would you mind providing some background into how Microsoft responds to the (e) of the DFARS 252.204-7012 "preserve and protect images of all known affected information systems?  I am not aware of any large SaaS provider who is able to provide images but wanted to bring it to the forefront for discussion. 

Thank you for both again for creating this blog.  I reference it often.

Terry

(e)  Media preservation and protection. When a Contractor discovers a cyber incident has occurred, the Contractor shall preserve and protect images of all known affected information systems identified in paragraph (c)(1)(i) of this clause and all relevant monitoring/packet capture data for at least 90 days from the submission of the cyber incident report to allow DoD to request the media or decline interest.

Klaw; good question and not the first time I have heard it. I think though its easy to conflate some issues. Export data is typically associated or aligned with NOFORN requirements although NOFORN can be applied to far more than export data. O365 provides GCCH with explicit intent to support export data. When I use the term export data I am referring to DDTC standards and ITAR. NOFORN is orthogonal. And anecdotally; since we do not yet offer any features to perform a direct backup the data resident in the human mind I think your colleague is safe with their ITAR knowledge 😉 I have spoken before to the fact that the _maturity_ of the services is not what is fundamentally different when you contrast MT, GCC, GCCH & DoD. What does change is (a) the scope of controls being added for each 'higher' level as well as (b) the increased 'rigor' of the control values. This is where a customer should focus on making a decision on what service is most appropriate for them since risk acceptance is ultimately their decision i.e. do they require the added controls, or the added rigor at available in GCCH? They may require such for different reasons. Some customers see explicit interpretations of requirements satisfied in GCCH compared to GCC. Others see benefits of competitive differentiation. Etc. Those that have heard me speak on this know I have no desire to police our customers. My intent is always to ensure they can make the most informed decision. Because migration is not fun. And the unfortunate reality is that I have experienced far more customers that decide to migrate part or all of their business to GCCH than I have seen decide to 'down level'. In summary: 

I came to this page trying to understand the architecture of Azure ("commercial" and "government") and its impact on our planned implementations of MS Teams/InTune as well as on compliance to CJIS for our Office 365 and for our new backup solution (which the vendors are telling us could use either Azure commercial or government).  Anyone at Microsoft: please correct me if i am wrong in my reading of this article. As an SLTT:

1. our Azure AD is in the Azure Commercial (it is) as it should have been 
2. building out virtual servers for InTune in Azure GCC is wrong since it cannot use our existing Azure AD (we are being told this, but it seems like it would work from what I read here)
3. establishing an organizational root CA should be done now for both MS Teams (and either now or future AIP deployment) and for the new backup solution.  The root CA could be on-premise or in Azure (Commercial or GCC).  If on-premise, it could also be "tied" to an already pubic ally trusted certificate authority (e.g., Entrust).  And, if InTune/MS Teams in GCC cannot make use of our Commercial Azure AD, that root CA would dictate the use of Azure commercial for both MS Teams and the new backup solution.
4. We've confirmed that control of our encryption key within the organization is sufficient for CJIS on the backup solution.  #3 does not break such compliance only if we use/set up an on-premise root CA.
5. Is establishing an organizational root CA now additionally necessary for ensuring police emails, devices managed by InTune, files in SharePoint and OneDrive, and files moved by MS Teams (all in our existing Azure Commercial cloud) are protected up to CJIS standards, or do the police need to move to the GCC of the Azure government series? And, if the latter, what all needs to be in there?
6. What else is needed to of the current Office 365 (in commercial) in order to meet CJIS requirements? (this may be a question for our State)

Please feel free to reply and post here as well as directly to me.  Thank you.

In my organization I find that there's a lot of confusion and concern surrounding CUI, CMMC (L3-L5 requirements), and the rationale for choosing "GCC High" over "Commercial" 365 licensing.

Here's a comment I received from a colleague just the other day:

Is it Micosoft's directing to industry that in order to obtain CMMC level 3 certification in a Microsoft Cloud environment, it will require both Azure Government and M365 GCC High implementation?  ... if you read the DOD Instruction 5200.48, NOFORN is a distribution marking which may be added to CUI, C, S, TS, TS/SCI.  CUI is not NOFORN by definition plus not all ITAR Defense Information is CUI - a significant portion of ITAR Defense Information is held commercial as Corporate Proprietary Information.  I hold ITAR informatrion by virtue of my service in the army, nuclear weapon construction and Joint C4I System engineering by ITAR Definition the know-how in my head is ITAR Controlled.