Task Publishing – Champion Scenarios and Walk Through

by Contributed | Feb 23, 2021 | Technology

This article is contributed. See the original author and article here.

What is Task Publishing

Your community has just come up with some new champion campaigns to drive awareness and new adoption scenarios, how is the best way to communicate out the action items for the new campaign and track the status? With task publishing you can now send out tasks to a variety of teams and have those tasks tracked centrally for assignment and completion. We think you will really be able to see the power of this versatile new option for several different examples. Let us dive into a walkthrough talking through this process. Also checkout this article for a simplified walkthrough.

Imagine the scenario above where you have come up with two new campaigns to deliver champion value back into your organization, these two campaigns consist of the following:

Campaign 1:  Socially Distanced Lunch & Learns for immersive meetings

Campaign 2: Virtual Team Building: Bingo Squares

Great! You have got some campaigns that your core team has developed and now we want to distribute the tasks for running these campaigns. Enter Task Publishing via Tasks by Planner and To Do in Microsoft Teams to publish your tasks out to the teams responsible for execution.

Task Publishing works off developing a targeting hierarchy for Microsoft Teams to publish content to a large set of teams.  The team targeting hierarchy defines how all the teams in your hierarchy are related to each other, which users can publish tasks, and which teams users have permissions to publish. Publishing features are disabled for all users unless a team targeting hierarchy is set up for your organization. To set up a team targeting hierarchy, you will need to create a file that defines the hierarchy and then upload it to Teams to apply it to your organization.

Note that some of these next steps will require some IT Administrative assistance. To publish a hierarchy file, you will need either Global Admin or Teams service admin. See more about the requirements here

Thinking about your Teams Hierarchy

Let us have a look at my sample Team environment which will serve as the base of our hierarchy development in this scenario.

In my Contoso organization there are 13 teams for my champion community. I have our topmost team, where I have people from around the organization contributing to ideas, scenarios, etc. – Contoso Global Champions – M365. From there I have regionally established teams that help serve my broader but a bit more specific region of champions (Region 1 / 2 / 3 Champions – M365). Finally, I have teams at each site that my champions there use to discuss specific site needs (these could be large physical locations, central geography regions, etc.), like Site (A – I) Champions – M365.

I have laid out the assumptions of why I have teams organized this way to specifically serve this example. You could apply this to several scenarios, such as in a Healthcare scenario where you are wanting to publish tasks out to a variety of local hospitals or clinics or a Retail scenario where you are providing tasks to a collection of stores.

Task Publishing Terminology

Now that we have a base for why my teams are thought about in this hierarchy, lets discuss some items we will want to understand around the actual buildout of the hierarchy file – the terminology.

Continuing our example with our distributed champion teams we are applying some Task Publishing terminology to our Teams. A quick note here that any actual Team will be referred to as a node in the terminology.

Each node that we eventually define out in our hierarchy plan will represent a Team that will be designated to receive the tasks that we want to publish.

In our scenario we only have one root node, however we could expand this to encompass many more. In our same examples we could build out a hierarchy file to accommodate for our champion needs as well as other business needs by providing more root nodes and their related dependencies (see below visual to think this process out with a healthcare facility keeping the region to site values):

Building out the hierarchy file

Now that we have got our mental images of how our hierarchy is set for these scenarios, we need to build out the actual file to support the vision we are laying out. To build out the hierarchy file we will need to use a CSV file and have some required and optional columns to support this. You can find out more information about the requirements here but let’s also dive into them as it relates to our current champions team scenario.

The required fields are DisplayName, ParentName, and TeamId.  Additionally there are two types of attribute columns that are supported as well as the notion of bucket columns (for task organization).

Get-Team | Export-Csv TeamList.csv

Let us look now at my CSV file to get a better understanding of how we are leveraging these values:

You can see I have captured my Teams (nodes) as TargetName in the file that I’ll have represented here for potential task publishing, linked to a ParentName I have determined. For ease of understanding I’ve simply linked my Region Champion Teams into a “regions” and Site Champion Teams into “sites”. Next, I have the ID of the related teams entered. That rounds out my required fields.

Optionally I have included three attribute columns, as well as two bucket columns. Where 1 value in the attribute row is the equivalent of yes and a 0 is the equivalent of no.

Feel free to leverage the snippet below for a simplified starter CSV file that follows the above scenario. Just enter this into a notepad and save as CSV file.

TargetName,ParentName,TeamId,Location,On-Site Assets:Conf Room w/Surface Hub,On-Site Assets:Dining Options, #On-Site Campaign, #Virtual Campaign
Contoso Global Champions - M365,,TEAM-ID,,,,,
Regions,Contoso Global Champions - M365,,,,,,
Sites,Contoso Global Champions - M365,,,,,,
Region 1 Champions - M365,Regions,TEAM-ID,North America,1,1,,
Site A Champions - M365,Sites,TEAM-ID,North America,1,0,,

Applying your hierarchy

This will be the part where you will need either a Global Admin or Teams service admin to complete this step. You can refer to more details here. Additionally, you’ll need to ensure (as of this post writing) that you are using the Teams PowerShell public preview module in order to leverage the supported commandlets.

Once you have created your CSV file you need to upload it to Teams. For now only one hierarchy file is supported so you will want to ensure you are incorporating the terminology and hierarchy decisions discussed above if you have multiple areas looking to leverage task publishing.

Run the following command to publish or to update our hierarchy. Updating replaced the old one using the same command:

Set-TeamTargetingHierarchy -FilePath "C:ContosoTeamSchema.csv"

To see the status and remove your hierarchy please refer to the expanded information located on the docs page here.

Start simple with your sample to get the hang of the creation of the hierarchy file. As we get into the next sections certain elements may not appear if there was an error updating or applying your hierarchy file.

Creating a new publishable task list

Alright – we have now gotten our hierarchy created, published, and applied to our Teams environment – now onto the fun stuff! The powerful notion of being able to publish tasks to Teams now comes into view as we look to create out tasks based on our champion scenarios we talked about earlier.

Since we have published a Teams Hierarchy, we will now see a new option in Tasks called Published lists which will be empty when we click over to it. Let us go into it and select a new list:

We are going to build out our first campaign (Campaign 1:  Socially Distanced Lunch & Learns for immersive meetings). You will notice that we are publishing from the root node we defined in our hierarchy file. Since we only defined one I only have that option, however considering the thoughts above where we had another root node for our hospital locations, we could have multiple options to select here as a home.

Now that we have made our first list we will see it under the drafts column. We can add tasks as you would expect and assign titles, priority, due dates, bucket assignments, as well as additional notes and attachments by clicking in on the tasks.

Let us go ahead and build out our second campaign list – Campaign 2: Virtual Team Building: Bingo Squares

So, we are able to have multiple drafts ongoing at the same time while we build out the tasks that will be associated with each item. We will be assigning these out to our teams we defined earlier so that the teams can all share in completing the same task items while we maintain a centralized view of the progress towards the completion of each.

Depending on the state of your tasks list you can also copy, rename, edit, and delete them. For more information about those actions please visit here. Next, we want to dive into publishing our task list to the teams we identified in the hierarchy earlier.

Publishing your task list

Now that we have our task list ready let’s go and publish it to the teams we would like to have receive these tasks. To do this we will go back to Tasks, select published lists, select our Draft, and then click on publish to walk through the publishing steps.

What we are doing is publishing all the above tasks into some Teams. We filtered based on their on-site assets and chose to publish to all the region and site teams that were available that matched that filter. At the conclusion we now have that list we created moved into the published category, as well as several received task lists that were inbound since our account is also a member of all these teams.

A user does not necessarily have to be a member of the target team where the list is being published. Let us look at the permissions to publish below, as well you can find out more information here:

Permissions to publish

Permission to publish depends on whether a user is a member of any teams in the hierarchy plus the relationship of that team or set of teams to other teams in the hierarchy.

 Note The owner of a team is also granted publishing permission.

• If a user is a member of at least one team that has descendants in the hierarchy, that user can publish to those descendants without being a member of all teams they want to publish to.


• If a user is a member of at least one team in the hierarchy but is not a member of any team with descendants in the hierarchy, that user can see and receive published content from their organization.


• If a user is not a member of any team in the hierarchy, that user won’t see any publishing-related functionality.

Viewing the task list from a team

Now that we have published our task list for our champion teams lets go see what they see. Ideally, we would expect they can go and work against these tasks – assigning and completing them within their group, and for us to have a view into that centrally within the published list window.

I am exploring Site D Champions and see the following have been populated for me within the team. Keep in mind that how you want to define buckets and other elements during the design phase would also impact on how these tasks are seen and consumed.

I designated the use of buckets to look at the difference between virtual or onsite events. This could be more powerful in these scenarios for the actual campaign buckets of tasks, or even the location avenue. You have a lot of choices in this matter!

I have gone through a few teams now and assigned tasks to some team members as well as mocking the completion of some tasks that were assigned out. Let us see what it looks like back on our dashboard!

I have two powerful views I can swap between here, a task-oriented view so I can see percentage assigned and completed by the task – as well as an all-up team view that shows me the percentage broken out by my regions and sites. Remember in my example my regions are actual teams as well that I have assigned tasks out to. I am imagining them running their own campaigns just like I have asked my site level groups to do. In other scenarios I may not want my hierarchy to break out like this and would instead prefer to depend on attribute filters, etc.

Wrap up

There are some awesome things we can think about doing once we see what tasks publishing is capable of. In my scenario I tried fitting this in with the notion of delivering tasks out to your champion teams. Envisioning you have created the required tasks to complete a certain campaign targeting a champion scenario and easing the distribution of those tasks out to your network just got a whole lot easier.

There is a bit of work to get this initially setup and your hierarchy / buckets / attributes defined to your liking, however once you get those basics completed the practical applications should be numerous for delivering and tracking task list assignments!

Let us know what you think about the feature and how you are thinking about or have leveraged it in our driving adoption forum!

#Champions

/Josh

Weekly Secure Score Progress Report

by Contributed | Feb 23, 2021 | Technology

This article is contributed. See the original author and article here.

With the increasing number of resources in your Azure environment, you need a way to understand and prioritize the security hygiene of your environment and that’s where Azure Security Center comes into picture. Azure Security Center continuously assesses Azure resources, within a subscription to identify security issues and provides a list of security recommendations which leverages Azure Security Benchmark. Recommendations are grouped in Security Controls and some security controls will have a score attach to it. Each control is a logical group of related security recommendations and reflects your vulnerable attack surfaces. 

From the continuous improvement perspective, it is imperative that you keep track of your Secure Score progress. This blog post, introduces an automation playbook that you can leverage to receive a Weekly Secure Score Progress report via email.  

Requirements

To deploy this automation, you will need to: 

• Create a new Logic App 


• Authorize the API connection to connect to the workspace 


• Authorize the Office 365 API connection to send emails 


• Authorize the Logic App managed identity

How does it work

The automation playbook is a Logic App that runs weekly, queries your Log Analytics Workspace and gathers data to send you weekly notification email that will update you details on your current Secure Score as well as Secure Score overtime progress report displayed in a beautiful graph format. In case you notice a spectacular change in the graph, you can continue to review the current security controls that are open and that needs to be prioritized along with the top five most important Security controls that needs to be fixed as early as possible – all in one email. Having this kind of detailed visibility is super important for Security analytics to keep track of the environment’s security hygiene. A sample email from the automation’s run is shown below:  

Image 1: Example Email output

The sections that follow will go in details on each one of those steps.

How to deploy the automation playbook

You can find an ARM template that will deploy the Logic App Playbook and all necessary API connections in the Azure Security Center GitHub repository.

The ARM template uses your Log Analytics workspace and creates two API Connections, O365 and an Azure Monitor Logs API connection. As part of the template parameters, you will need to enter your Log Analytics Workspace Subscription ID, Log Analytics Workspace Resource Group Name and Log Analytics Workspace Name. During the deployment, it is highly recommended to create a new resource group, which will contain all the required resources for the playbook.

Once you have deployed the ARM template, you will have some manual steps to take before it works as expected.

Authorize azuremonitorlogs API Connection 

This API connection is used to connect to your Log Analytics workspace. To authorize the API connection:

1. Go to the Resource Group you have used to deploy the template resources.


2. Select the azuremonitorlogs API connection and press ‘Edit API connection’.


3. Press the ‘Authorize’ button.


4. Make sure to authenticate against Azure AD.


5. Press save

Authorize Office 365 API Connection 

This API connection is used to send weekly secure score progress report email. To authorize the API connection:

1. Go to the Resource Group you have used to deploy the template resources.


2. Select the Office365 API connection and press ‘Edit API connection’.


3. Press the ‘Authorize’ button.


4. Make sure to authenticate against Azure AD.


5. Press save.

Authorize the Logic App’s managed identity

The playbook uses a Managed Identity. You need to assign reader permissions to the subscriptions you want to export for the Manage Identity (explained in detail below). Notice you can assign permissions only as an owner and make sure all selected subscriptions registered to Azure Security Center.

To grant the managed identity reader access, you need to:

1. Make sure you have User Access Administrator or Owner permissions for this scope.


2. Go to the subscription/management group page.


3. Press ‘Access Control (IAM)’ on the navigation bar.


4. Press ‘+Add’ and ‘Add role assignment’.


5. Choose ‘Reader’ role.


6. Assign access to Logic App.


7. Choose the subscription where the logic app was deployed.


8. Choose the Logic App you have just deployed.


9. Press save.

GitHub Sample

You can leverage This logic app as well as many other can be found here: this automation from our GitHub repository using the links below: 

Direct Link to GitHub sample 

Azure Security Center GitHub Repo 

Make sure to take advantage of this automation artifact and stay on top of your environment’s Security Posture.  

Let us know your feedback using any of the channels listed in the Resources. Your feedback is highly appreciated.  

Reviewer

Thanks to the amazing Yuri Diogenes, Principal Program Manager for envisioning this wonderful automation idea and for his feedbacks on this automation and the article. 

History of Microsoft Cloud Offerings leading to the US Sovereign Cloud – February 2021 Update

by Contributed | Feb 23, 2021 | Technology

This article is contributed. See the original author and article here.

This article is the first of a series in the Microsoft Tech Community Public Sector Blog and touches on several of the key principles for compliance, including data residency versus data sovereignty.  For a more in-depth explanation, please refer to Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings.

I chose to start with this history lesson, as it puts our cloud offerings into perspective and enables an understanding of why, as we go levels deeper when explaining compliance between the various cloud offerings.

I outline principles throughout this article. Please keep in mind these principles are specific to the overlying emphasis on compliance.

Microsoft 365 started with Office 365 Commercial.

What’s it called?  Internally, we call the Office 365 Commercial environment ‘Public Multi-Tenant’ or ‘Public MT’ for short. Back in 2010, we had a set of dedicated clouds as well, which is why we often differentiate the clouds as Multi-Tenant, meaning not dedicated nor private clouds.  And the term ‘Public’ indicates that it’s available on the public internet and is often interchangeable with ‘Global’.  Thus, if you hear someone from Microsoft refer to Public or Public MT, they are talking about our Commercial environment.

For purposes of this conversation, I will use the term “Commercial” which refers to the environment as opposed to “Enterprise” which refers to licenses. Office 365 Commercial originally shipped with the four primary workloads.  Today those workloads are branded as Exchange Online, SharePoint Online, OneDrive for Business Online, and Skype for Business Online.  It has evolved to include many new products including Advanced Threat Protection, Teams, Yammer, Power BI, Stream, the Security & Compliance Center and many more.

Office 365 Commercial pre-dates many of the Enterprise Mobility + Security (EM+S), Azure IaaS and PaaS services we are familiar with today, including the directory services solution we know as Azure Active Directory (Azure AD).  Back in 2010, Office 365 shipped with a native directory service called Microsoft Online Directory Store (MSO-DS).  The term ‘tenant’ can be described in a simplified fashion as being the security boundary defined by an instance of MSO-DS for a specific customer enrollment.  Thus, an enrollment of MSO-DS (now Azure AD) directory services is a ‘tenant’.

Three primary principles emerge with the first release of Commercial:

1. Global Directory. Starting with MSO-DS and now with Azure AD in Commercial, directory services are supported globally OCONUS (Outside the Continental United States).  In other words, directory data transmission and data processing, including authentication and authorization, may be OCONUS.  A tenant can be homed in a specific geo (e.g. the US), but the directory may be supported globally.  That said, a tenant’s directory data storage may be restricted to a specific geo such as in the United States (where Azure AD data is stored solely in the United States) and in Europe (where Azure AD data is stored in Europe or the United States). Learn more here.


2. Global Network.  Data transmission and data processing is global.  Most Commercial endpoints are *.com and may resolve to the closest geographical location of the Microsoft network.  For example, when you sign into Commercial from Australia, it may resolve your client to our data centers in Sydney or Melbourne.  Of course, if your data is elsewhere, such as in the US, your client will connect to the US over our high-speed fiber network backbone from Australia.  But there is data transmission and data processing on systems OCONUS.


3. Global Support Personnel.  Office 365 Commercial support personnel are not restricted to US Persons.  We have a follow-the-sun support model in Commercial where support personnel from India and elsewhere may have limited access to services to provide 24/7 support for our customers.

Keep these principles in mind as we continue to discuss the evolution of our cloud services as it’s the reason we ended up with several different clouds.

A word about Office 365 Multi-Geo

As Commercial has evolved, we now have regions, or ‘Geos’ in Public MT that offer data residency in multiple geographies, often aligned with countries.  Our Office 365 Multi-Geo solution addresses your data residency requirements for workloads including (and limited to) Exchange Online, OneDrive for Business Online, SharePoint Online and Office 365 Groups.  We will soon have a multi-geo solution for Teams as well.  From a compliance perspective, this translates to having data stored at rest within a specific country or region. 

At the time of this writing, we have available Geos in Australia, Brazil, Canada, European Union, France, Germany, India, Japan, South Korea, Norway, South Africa, Switzerland, United Arab Emirates, United Kingdom, and the United States.  We are adding new Geo’s frequently.

A Geo in Office 365 is a data enclave for a defined region.  Internally, a Geo is a data enclave of Commercial.  A data enclave is segregated environment, with servers residing in regional Azure data centers.  For example, the US Geo may be selected in Exchange Online for specifically assigned users that require mailboxes at rest within CONUS (Continental United States).  Many governments, financial services, healthcare providers, etc. often have requirements for data residency in a specific country.  This Multi-Geo solution often meets these compliance requirements in Commercial, especially in conjunction with the alphabet soup of industry standards and government regulations in the US and abroad.

History Sidebar: The often-forgotten true predecessor to Office 365 is the first public multi-tenant Office solution we delivered to Education customers called Live@edu.  It began in 2005 and served as something of an early adopter program for Office 365, on-boarding over 50 million faculty, staff, and students to Outlook Live, SkyDrive and other Office solutions.  Interestingly, I was the first solution architect for Live@edu starting back in 2007.

Some may dispute that BPOS (Business Productivity Online Suite) is the predecessor to Office 365, but in truth it was a parallel environment built and supported by BPOS engineering.  Conversely, Live@edu was built and supported by each respective workload product group (e.g. Exchange), identical to Office 365. Regardless, both Live@edu and BPOS pre-date Office 365.

Introducing the US Government Community Cloud.

What’s it called again?  Office 365 GCC should not be confused with GCC High.  They are two separate clouds.  Historically, we often referred to GCC as ‘GCC Moderate’ for its alignment with FedRAMP Moderate.  That is less relevant now that GCC is FedRAMP High.  I’ve also heard it called the ‘IL2’ environment, for its alignment with the DoD CC SRG Impact Level 2.  But ‘Moderate’ and ‘IL2’ are confusing nicknames, and we try to avoid calling GCC anything other than ‘GCC’.

US Government customers have a variety of accreditations and industry standards for Cloud Solution Providers.  Most notably, FedRAMP and NIST come to mind.  Certain government entities extend beyond the accreditation with regulations such as CJIS and IRS 1075 that require screened US Persons.  As such, it’s not good enough to simply have data residency within CONUS.  The cloud service offering must impose restrictions so that only authorized personnel may access customer content.  Ultimately, this data enclave for GCC not only ensures data residency and data processing for the primary workloads are in CONUS, it also restricts customer content access to authorized screened US Persons.

For Microsoft to capture the market for US Government entities, GCC is required.  We have onboarded thousands of US government agencies and departments, especially in SLG (State & Local Government) and Federal Civilian.  There are a few principles for GCC to keep in mind:

1. GCC is a data enclave of Commercial.  Shared services, such as outlined in the principles for Commercial apply to GCC as well (e.g. Global Directory, Global Network, Global Support, etc.)


2. GCC offers data residency as opposed to data sovereignty.  It’s paramount that you understand data residency applies to the GCC covered workloads (e.g. Exchange, OneDrive, etc.).  Other workloads may not support data residency.


3. US Government accreditation for GCC.  The FedRAMP Moderate Agency ATO from the Department of Health and Human Services (DHHS) is specifically for a tenant in GCC.  GCC is ultimately a data enclave of Commercial, thus FedRAMP Moderate accreditation has ‘equivalency’ across all our Public MT environment including Commercial tenants.  Ultimately, it’s regulations (e.g. CJIS & IRS 1075) that drive government entities into GCC as opposed to Commercial.

Keep these GCC principles in mind, along with the Commercial principles.  It’s the reason many government customers with stricter regulatory requirements (e.g. ITAR, Nuclear, etc.) do not choose GCC.

Then along came Microsoft Azure.

Office 365 pre-dates Microsoft Azure.  We did have Windows Azure around about the same time as the first release of Office 365, but the Windows variant did not have many of the EM+S, PaaS and SaaS components that are included today.  For the purposes of this conversation, we’ll focus on Azure AD and EM+S.  Many of the native features evolved out of Office 365 and into Azure.  MSO-DS became Azure AD and provides directory services, authentication and authorization beyond Office 365, including Azure Resource Manager and 3^rd-party applications. Azure RMS spun out and is now bundled with Microsoft Information Protection (MIP). And the list goes on.  Azure now provides a platform for many workloads, and we’ve continued to build on top of that.  For example, Dynamics 365 and Visual Studio Online are now built on top of the Azure platform and integrate into services such as Azure AD in Commercial.

The one key principal of Azure Commercial as it relates to Office 365 is:

1. Office 365 Commercial and Office 365 GCC are both paired with Azure AD in Commercial.  Office 365 GCC cannot be paired with Azure AD in Government (more on that to come).

To distill this down, compliance for Azure Commercial aligns closely to what is offered for Office 365 Commercial.  The same three principles of Office 365 Commercial (Global Directory, Global Network, Global Support Personnel) apply to Azure Commercial.  In other words, data residency is available, but data sovereignty is not.

In fact, many of the US SLG and Federal Civilian agencies will not deploy IaaS nor PaaS into Azure Commercial without US Persons support, regardless of the fact that we have a P-ATO for FedRAMP High in Azure Commercial.

To capture the market for US Government entities for IaaS and PaaS, Microsoft built Azure Government.

What’s it called?  The initial release of Azure Government for IaaS and PaaS was the introduction of what we call the ‘US Sovereign Cloud’.  Azure Government has internal code names including the first architecture called ‘Fairfax’ and the next generation sovereign architecture called ‘Arlington’.   We also call it ‘MAG’ for Microsoft Azure Government.  Most people just call it ‘Azure Gov’.

Azure Gov is a fully isolated cloud environment, that is both physically and virtually isolated.  It’s a separated instance of Azure within a compliance boundary dedicated to US government workloads. It’s built exclusively for US government entities and their solution providers, to include the Defense Industrial Base (DIB).  Azure Gov is designed for highly sensitive data such as Controlled Unclassified Information (CUI) that requires true data sovereignty.  This enables Microsoft to contractually meet the compliance accreditation for FedRAMP High and requirements for US Defense regulations including DoD CC SRG IL4/5, DFARS 7012, ITAR and EAR.

For purposes of this discussion, several key principles include:

1. US Sovereign Directory Services.  Unlike with Commercial, Azure AD in Azure Gov is not global.  No matter where your client connects from, you will always get authentication and authorization rendered from Azure Gov data centers located in CONUS.  For example, you will always see a login page with a .US URL (e.g. https://login.microsoftonline.us/…)


2. US Sovereign Network. Data Transmission and Data Processing is CONUS only.  As opposed to Commercial endpoints that are all *.com, Azure Gov endpoints are all *.us or *.mil.  For example, when you sign into Azure Gov from Australia, it will always resolve your client to Azure Gov data centers in the US.  There is no probability of you connecting to data centers in Australia.  If your internet peering is in the US, you can rest assured that no data transmission will occur OCONUS.
   Note: You can implement public peering with Microsoft to enter our network in a geographically closer location to take advantage of our global high-speed fiber network backbone to route to the US, but there is no data processing OCONUS.


3. Screened US Persons.  Support personnel is restricted to screened US Persons.  This includes background checks as required by multiple regulations, including checks against export-related lists maintained by the Departments of Commerce, State and Treasury.  Coverage is offered on all services in Azure Gov isolated within the compliance boundary where only screened US Persons are permitted.


4. Azure Government supports US export-controlled data.  True data sovereignty allows Microsoft to contractually commit to export controls, including US Defense regulations for DoD CC SRG IL4/5, DFARS 7012, ITAR and EAR. This includes coverage for Controlled Unclassified Information (CUI) and Covered Defense Information (CDI).

Now that we have Azure Government, it gave us a platform to begin deploying additional workloads into the US Sovereign Cloud.

Now introducing Office 365 DoD paired with Azure Government

After achieving a Provisional Authorization (PA) from DISA for DoD Cloud Computing (CC) Security Requirements Guide (SRG) Impact Level 5 (IL5) covering Azure Government, we began the construction of Office 365 for the US Department of Defense (DoD).  To deploy Office 365 to the DoD, they required IL5 across the entire platform and services, to include Microsoft Peering with the DoD’s Cloud Access Point (CAP).  We have delivered the full suite of services to Office 365 DoD, but we had one catch.  Only the DoD and those approved by them (such as service providers or contractors working on behalf of DoD) are allowed into the IL5 environment.  It does preclude other entities from being eligible to procure their own tenant of Office 365 in the US Sovereign Cloud.  This includes the service providers for the DoD, such as the DIB.  It also includes other government entities that require data sovereignty, such as cabinet-level agencies (e.g. DHS, FBI, DOJ, etc.).  There was a tremendous demand from these entities as well.

To capture the market for the DIB and cabinet-level agencies, a mirror copy of Office 365 DoD was constructed and branded Office 365 Government (GCC High).

What’s it called?  GCC High?  Environment and SKU name aligns with its accreditation of FedRAMP High. This should NOT be confused with the defense Industry term a ‘high-side environment’ which is a designation for classified information.  To be clear, GCC High is not a ‘high-side environment’.  GCC High is a ‘low-side environment’ regarding classified information.  GCC High has also been called an ‘IL4’ environment, for its alignment with the DoD CC SRG Impact Level 4 controls.  We avoid calling GCC High anything other than ‘GCC High’.

If you look for a DoD Provisional Authorization (PA) from DISA for a DoD CC SRG Impact Level 4 environment, you will not find one.  That’s because we have equivalent IL5 environments.  We have the IL5 PA on the Office 365 DoD environment, where GCC High is a near copy of.  We can consider GCC High an IL4 environment for a couple of reasons.  First, IL4 controls are derived from IL5 that we are accredited for.  We have a consistent control framework and uniform implementations of controls in both environments; thus, we can say GCC High has IL4 ‘equivalency’.  Second, no one besides the DoD proper is allowed into IL5.  We call it an IL4 equivalent environment where the Defense Industrial Base and Cabinet-level agencies are allowed.

In alignment with the key principles for Azure Gov, several key principles of both the Office 365 DoD and GCC High environments include:

1. US Sovereign Directory Services.  Unlike Office 365 GCC that is paired with Azure AD in Commercial, Office 365 DoD and GCC High are paired with Azure AD in Azure Gov.


2. US Sovereign Network.  Data Transmission and Data Processing is CONUS Only.  As opposed to Commercial endpoints that are all *.com, Office 365 DoD and GCC High endpoints are all *.us or *.mil.  This is fundamentally important and a major talking point for compliance with export controls.  For example, for email to be compliant, you must have all data processing in a US Sovereign solution.  Microsoft offers Exchange Online Protection and Office Advanced Threat Protection within the compliance boundary keeping all data processing of email in CONUS.  This includes logging and telemetry captured in the process of scanning email.


3. Screened US Persons.  Support personnel is restricted to screened US Persons.  This includes background screening as required by multiple regulations, including checks against export-related lists maintained by the Departments of Commerce, State and Treasury.  Coverage is offered on all services (no exclusions) in Office 365 DoD and GCC High isolated within the compliance boundary where only screened US Persons are permitted.


4. Office 365 DoD and GCC High supports US export-controlled data.  True data sovereignty allows Microsoft to contractually commit to export controls, including US Defense regulations for DoD CC SRG IL4/5, DFARS 7012, ITAR and EAR. This includes coverage for Controlled Unclassified Information (CUI) and Covered Defense Information (CDI).  Microsoft will not commit to export controls anywhere else!  This is especially true for ITAR.

We also have additional services that are branded GCC High.  We now have Dynamics 365 GCC High, the Power Suite for GCC High, and many more services to come.

Appendix

Please follow me here and on LinkedIn. Here are my additional blog articles:

Understanding Compliance Between Commercial, Government and DoD Offerings – February 2021 Update

by Contributed | Feb 23, 2021 | Technology

This article is contributed. See the original author and article here.

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.  To keep this article concise, I will refrain from repeating content from the first. I recommend that you review the first article if you are unfamiliar with the architectural relationships between Azure, Microsoft 365 and Dynamics 365.

In this article, we will focus on each of the US-based cloud offerings from Microsoft and compare the differences in compliance, including the compendium of common factors customers may use to decide which of our offerings align with current and future requirements in demonstrating compliance with US Government regulations and underlying cybersecurity frameworks.

Microsoft 365 Commercial + Azure Commercial

FedRAMP in Azure

The US Federal Risk and Authorization Management Program (FedRAMP) was established to provide a standardized approach for assessing, monitoring, and authorizing cloud computing products and services under the Federal Information Security Management Act (FISMA), and to accelerate the adoption of secure cloud solutions by federal agencies.

You can demonstrate compliance with the FedRAMP High Impact Level in Azure to include both Azure Commercial and Azure Government.  Azure has a Provisional Authorization to Operate (P-ATO) from the FedRAMP Joint Authorization Board (JAB). The JAB is the primary governance and decision-making body for FedRAMP. Representatives from the Department of Defense, the Department of Homeland Security, and the General Services Administration serve on the board. The board grants a P-ATO to Cloud Service Providers (CSP) that have demonstrated FedRAMP compliance.

You can find a full list of Azure services that meet the requirements of FedRAMP High in the Azure audit scope documentation.

For more information, please reference:

• Microsoft FedRAMP Documentation (https://aka.ms/fedramp)


• FedRAMP Marketplace:  Microsoft – Azure Commercial Cloud


• FedRAMP Marketplace:  Microsoft – Azure Government (includes Dynamics 365)

FedRAMP in Microsoft 365 Commercial

You can now demonstrate compliance with the FedRAMP High Impact Level in Microsoft 365 Commercial.  In fact, you can demonstrate FedRAMP High compliance in all Microsoft cloud offerings (in scope of this article).  At the time of this writing, we have successfully completed a FedRAMP High Impact Level audit, including a SAR (Security Assessment Report).  This is sufficient for purposes of us advertising FedRAMP High, as it completes Microsoft’s scope of responsibility towards FedRAMP accreditation for a Federal agency ATO. In other words, we support accreditation with Federal agencies at the FedRAMP High Impact Level.

The FedRAMP Marketplace for “Microsoft – Office 365 Multi-Tenant & Supporting Services” will be updated as Federal agencies are issued an agency ATO and work with the JAB to publish it.  In addition, we have accreditation from the Department of Health and Human Services (DHHS) for the FedRAMP Moderate Impact Level as formally acknowledged in the FedRAMP Marketplace.  DHHS and other Federal agencies are hosted in GCC tenancies, but GCC is a data enclave of Commercial, effectively extending the accreditation to the whole of the Commercial and Government clouds.

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 ‘equivalency’ in Microsoft 365 Commercial.  Microsoft validates the controls for Microsoft 365 into FedRAMP holistically because we operate all instances of Microsoft 365 employing a consistent control framework and uniform implementations of controls based on the U.S. National Institute for Standards and Technology (NIST) Special Publication (SP) 800-53 (NIST SP 800-53 – a requirement of FedRAMP).

A word about FedRAMP in Commercial and how it relates to CUI

A common misconception by many is regarding FedRAMP as ‘the’ requirement to protect Controlled Unclassified Information (CUI) in a cloud service offering.  It is important to note that FedRAMP is just one component of overall compliance relative to CUI in a shared responsibility model.  For example, International Traffic in Arms Regulation (ITAR) imposes an additional set of standards from the US Department of State that requires data sovereignty (e.g. US Persons). Export-controlled data such as ITAR technical data is one of the categories of CUI, hence ITAR is one of the components of overall compliance to holistically safeguard CUI.

I often get pulled into customer conversations on suitability for CUI in the Commercial cloud.  Yes, you can demonstrate compliance with FedRAMP.  However, not all FedRAMP / NIST SP 800-53 implementations are the same.  Each CSP has their own individual approach to FedRAMP control implementations. In addition, a CSP may even have multiple FedRAMP control implementations depending on their cloud service offerings.  For example, Microsoft has the same control ‘scope’ employing a consistent control framework across our cloud service offerings.  However, there are different control ‘values’, or what’s called “Organizational Defined Values” (ODV’s) that differentiate our Government clouds from our Commercial clouds. 

The most notable difference in a Government cloud ODV is the requirement for US Persons.  Ultimately, FedRAMP by itself is not the high watermark for compliance with any CSP.  It does not guarantee fulfillment of US Persons nor US Citizenship requirements, nor does it confer data residency in the Continental United States (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 watermark 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 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 offerings and diminish Commercial as an option.

Note: There is an entire article for Microsoft US Sovereign Cloud Myth Busters – CUI Effectively Requires Data Sovereignty

New Feature Releases in Commercial

Here is another aspect of Commercial to keep in mind.  Although the FedRAMP packages cover both Commercial and Government service implementations, release of new features and services into Commercial clouds is not predicated on FedRAMP compliance the same way it is for release into Government clouds.  For example, a new feature can release to Commercial cloud tenants before it has FedRAMP compliance.  However, the new feature will not release to Government cloud tenants until it complies with FedRAMP.  In my opinion, this is another compelling data point for our customers trying to decide on “Commercial vs Government”, as there is a risk of users organically adopting new features in your tenant before the features are authorized for FedRAMP.

Note: First-party products and features developed by Microsoft follow the NIST SP 800-53 control framework out of the starting gate, accelerating the path to FedRAMP authorization and reducing the risk of using such features before authorization.  However, this may not hold true for all products we ingest through 3rd-party acquisitions that could require a much heavier lift to achieve the same levels of compliance.

DFARS 7012 and NIST SP 800-171 in Microsoft 365 Commercial

This is for the Defense Industrial Base (DIB) including Aerospace and Defense (A&D) contractors of the US Department of Defense (DoD).  To substantially contract with the DoD, you will likely need to demonstrate compliance with the Defense Federal Acquisition Regulation Supplement 252.204-7012 (DFARS 7012).  If you have the requirement, your contracts will have a DFARS 7012 Clause, or you will be notified of a “flow-down” in sub-contracts to you.  DFARS 7012 mandates the protection of CUI with an implementation of NIST SP 800-171, and FedRAMP Moderate Impact Level for clouds used to store, process, or transmit CUI.  It is a set of controls that are used to secure Non-Federal Information Systems (commercial systems). NIST SP 800-171 is derived from NIST SP 800-53.  Think of it as a subset of the controls that apply to the DIB.  Given Microsoft uniformly implements NIST SP 800-53 in all our clouds, undoubtedly, we have coverage for NIST SP 800-171 controls in Commercial.

You will observe a caveated ‘Yes’ for both NIST SP 800-53 and 800-171. 

However, there are key differences in the System Security Plan (SSP) ODV’s for Commercial as compared to what 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 7012 sub-paragraphs (c)-(g) much less tenable in Microsoft 365 Commercial.

You will observe a ‘No’ for DFARS 7012 in Microsoft 365 Commercial. 

Why?  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).  This is especially true for demonstrating coverage for Forensic/Investigation scope of analysis. 

You may potentially demonstrate compliance with NIST SP 800-171 in a shared scope of responsibility model in Microsoft 365 Commercial.  For example, you may apply compensating controls for protection of CUI.  However, Commercial was not built for the regulations and standards that govern CUI.  Many in the DIB believe it is a moot point though.  If you cannot demonstrate compliance holistically with DFARS 7012 in Microsoft 365 Commercial, NIST SP 800-171 compliance will not be the governing factor in demonstrating your compliance to the DoD.

DFARS 7012 in Azure Commercial

As mentioned in the previous section, Microsoft 365 Commercial has a ‘No’ for DFARS 7012.  However, we are announcing that Azure Commercial can now demonstrate support for DFARS clause 252.204-7012 sub-paragraphs (c)-(g).  We have an auditor’s attestation letter summarizing how those sub-paragraphs are supported for Azure services.  This translates to a contractual commitment where we demonstrate DFARS 7012 compliance in Azure Commercial. 

Note: For more details on how we implement DFARS 7012 in Azure, please see https://aka.ms/DFARsAzure.

The introduction of DFARS 7012 in Azure Commercial offers you more choice in the selection of Microsoft cloud offerings that best suit your requirements for the protection of CUI. For example, those organizations that choose Microsoft 365 Government (GCC) deployed on top of Azure Commercial cloud regions in the US may now have paired Azure services that meet DFARS 7012 requirements.  While we do not offer this same contractual commitment for Microsoft 365 Commercial, we do offer DFARS 7012 compliance in Microsoft 365 Government (GCC) that operates in conjunction with Azure Commercial.  See below for more details in the GCC section.

Commercial will not always recognize US Government requirements

As I mentioned, there are guidance, operational and support differences between the services provided for Azure Commercial and Microsoft 365 Commercial, as opposed to those purpose built for the US Government.  There is no way to identify a government tenant within the Commercial service. 

Unfortunately, there 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 should not have been routed to offshore support personnel in Asia. That is how the global Commercial service works.  If you have requirements for screened US Persons, Microsoft purpose-built cloud offerings exclusively for supporting US Government obligations that are more suitable to sovereignty requirements.  See below in the GCC High + Azure Government section on support commitments for US Persons.

FCI in Microsoft 365 Commercial

In general, all US Government contractors have a requirement in their contracts to comply with 15 safeguarding requirements and procedures for Federal Contract Information (FCI) in the Federal Acquisition Regulations (FAR) 52.204-21 Basic Safeguarding of Covered Contractor Information Systems. These safeguarding requirements and procedures are also contained within NIST SP 800-171 controls.  Thus, you may demonstrate compliance with this requirement in Commercial and Government cloud offerings.

Cybersecurity Maturity Model Certification (CMMC)

One of the most common questions I get is, “What cloud offerings meet the requirements for CMMC”?

Cybersecurity frameworks are applied to all Microsoft cloud offerings consistently across the spectrum of services. Cybersecurity ‘maturity‘ is often represented as the efficacy of process and automation of practices. There are specific control requirements and ODV’s that are unique to each cloud offering. For example, sovereign clouds such as Microsoft 365 Government (GCC High) and Azure Government have controls in place for restricting data access to only screened US persons with data processing and storage only within CONUS. Sovereign clouds are more restricted in terms of the specificity of control requirements in relation to other cloud environments.  Even though control requirements may vary from one cloud environment to another, each may demonstrate a level of cybersecurity maturity in alignment with CMMC.

In other words, you may demonstrate compliance with CMMC in the Commercial cloud.   However, CMMC by itself will not be the decision factor on choosing which cloud offering is most appropriate.  For example, CMMC Level 3 and higher is intended for protection of CUI.  I have captured details regarding CUI throughout this article to help you make a more informed decision.

To net it out, Microsoft recommends the following: 

• You may demonstrate compliance with CMMC Levels 1-2 for the data protection of FCI in Commercial and in our Government clouds.


• We recommend the US Sovereign Cloud with Azure Government and Microsoft 365 Government (GCC High) for data protection of CUI in alignment with CMMC Levels 3-5. 

We understand you may have a different risk appetite and choose a different basis for your cybersecurity program. We do have customers that chose GCC (versus GCC High), in cases where they have CUI that does not require explicit commitments to protect CUI Specified and ITAR export controlled data.  Others have added additional compensating controls, such as FIPS 140-2 validated end-to-end encryption to protect ITAR export controlled data. However, many in the DIB (especially the larger tier 1 prime contractors) have chosen the US Sovereign cloud due to the comprehensive data protection offered holistically across all categories of CUI.

Ultimately, this is a risk decision made by the customer in meeting their current and future requirements. 

It is important to note that while cost and risk are prime decision criteria for our customers, many also consider future changes to their business strategy and scope of competition. Our Government cloud offerings are segregated environments where it is neither a short nor inexpensive customer project to relocate from one to another. If opportunities arise in the future to pursue business requiring a higher watermark for compliance, or a potential increase of work in other regions or industries, you may promote such criteria to assess in a decision of which cloud to choose.  There are many criteria to assess in such a decision, but we have attempted to portray the keys ones in context of this article.

For more information, please see my blog Accelerating CMMC compliance for Microsoft cloud

Microsoft 365 Government Community Cloud (GCC)

Scope of Services in GCC

The Microsoft 365 Government (GCC) cloud offering is a data enclave of Commercial.  A data enclave in this context is a 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 and data processing is in CONUS for the primary Office workloads.  In addition, only screened US Persons are authorized for customer content access.

The service description for all Microsoft 365 Government offerings may be found at http://aka.ms/o365usgovservicedescription

At the time of this writing, the service availability for GCC covered workloads are:

• Exchange Online & Exchange Online Protection


• SharePoint Online & OneDrive for Business Online


• Skype for Business Online


• Teams & Voice (Phone System & Audio Conferencing)


• and more as documented in the Service availability for each plan

Given GCC is a data enclave of Commercial, there are several shared services.  These shared services may have data processing globally 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 is supported globally and may have data processing (authentication) occur OCONUS along with service management by global support personnel. This is one of the reasons Microsoft will not contractually commit to export controls in GCC.

As a result, you will 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), Azure DevOps and GitHub 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.

Customer Support for GCC and Azure Commercial

Microsoft 365 Government (GCC) customer support is provided under the same terms and conditions offered to Microsoft 365 Commercial, without assurances for agent physical location nor citizenship.

The latest version of the Customer Support Terms and Conditions for GCC (referencing the above statement) can be found here.

GCC operates in conjunction with Azure Commercial, which is supported with a global follow-the-sun support model as well.  For products and services that fall under Azure Commercial, such as IaaS and PaaS deployments in the same tenant as GCC, the Azure Online Services Terms (OST) outlines coverage for customer support.

Many people are confused by this.  After all, I mentioned above that GCC restricts access to customer content to authorized screened US Persons only.  This is true of datacenter personnel who request temporary permission elevation under management oversight, granting access to customer content only when necessary.  While datacenter personnel are restricted in their access to customer content, customer support personnel have no direct standing access to the datacenter nor to customer content.  They can only be exposed to sensitive information when it is provided directly by the Customer during a customer support ticket.  We remind you not to share any controlled, sensitive, or confidential information with support personnel as part of your support incident, and follow your own internal data sharing controls, policies and procedures when engaging with Microsoft customer support.

Note:  Customer Lockbox for Office 365 is a popular feature to moderate access to your data.   We even have Customer Lockbox for Azure releasing to more and more Azure services.

DFARS 7012 in GCC

Microsoft 365 Government (GCC) and its conjunction with Azure Commercial can now 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.  Microsoft will sign a contractual Flow-Down for DFARS 7012 in GCC.  This translates to a contractual commitment where we demonstrate DFARS 7012 compliance in GCC.  As a result of the Flow-Downs commitment, you will observe a ‘Yes’ in the GCC column for DFARS 7012.

Note: For more details on how we implement DFARS 7012 in GCC, please see https://aka.ms/DFARsGCC.

Controlled Unclassified Information is a Maybe in GCC

The NIST SP 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 they review the relevant regulations and Microsoft’s offering prior to determining which Microsoft Government cloud service offering is the best fit to support their obligations for CUI.

As not all CUI Specified can be supported, you will observe a caveated ‘Yes’ in the GCC column for CUI.

CMMC in GCC

You may demonstrate compliance with CMMC Levels 1-2 in GCC for protection of FCI.  You may also demonstrate compliance with CMMC Levels 3-5 with notable exceptions.  The intent of CMMC Levels 3+ is to safeguard CUI.  As mentioned in the previous section, GCC is not permissible for all categories of CUI.  Most notably, GCC does not support export-controlled data, such as ITAR and EAR natively.  As such, we recommend the US Sovereign Cloud with Microsoft 365 Government (GCC High) and Azure Government for CMMC Levels 3-5 to holistically safeguard all categories of CUI.  Please see the CMMC section above in Commercial for more rationale.

You will observe a ‘Yes’ in the GCC column for CMMC L1-2.  However, as not all CUI Specified can be supported, you will observe a caveated ‘Yes’ in the GCC column for CMMC L3-5.

FedRAMP High in GCC

You can now demonstrate compliance with the FedRAMP High Impact Level in Microsoft 365 Government (GCC).  Please see the section above on ‘FedRAMP in Microsoft 365 Commercial’ for more information.

DoD CC SRG in GCC and Azure Commercial

The Defense Information Systems Agency (DISA) is an agency of the DoD that is responsible for developing and maintaining the DoD Cloud Computing (CC) Security Requirements Guide (SRG). The SRG defines the baseline security requirements used by the DoD to assess the security posture of a CSP and establishes a baseline requiring a FedRAMP Moderate authorization for all information Impact Levels (IL).

SRG Section 5.1.1 (DoD use of FedRAMP Security Controls) states that IL2 information may be hosted in a CSP that minimally holds a FedRAMP Moderate authorization.  Given that Microsoft 365 Government (GCC) and Azure Commercial are both FedRAMP Moderate authorized (and higher), you may demonstrate compliance for IL2.  As such, there is effectively ‘equivalency’ between DoD CC SRG IL2 and FedRAMP Moderate.

For more information, please see Microsoft SRG Documentation.

Criminal Justice Information Services in GCC

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 SP 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 Azure Government, Microsoft 365 Government (GCC), and Dynamics 365 Government (GCC), and will attest to their ability in the applicable services agreements to meet FBI requirements for the use of in-scope services.

Download the CJIS implementation guidelines for Microsoft Government Cloud Services

CJIS status in the United States

43 states and the District of Columbia with management agreements, highlighted on the map in green include:

Alabama, Alaska, Arizona, Arkansas, California, Colorado, Connecticut, Florida, Georgia, Hawaii, Idaho, Illinois, Indiana, Iowa, Kansas, Kentucky, Maine, Massachusetts, Michigan, Minnesota, Mississippi, Missouri, Montana, Nebraska, Nevada, New Hampshire, New Jersey, New York, North Carolina, North Dakota, Oklahoma, Oregon, Pennsylvania, Rhode Island, South Carolina, Tennessee, Texas, Utah, Vermont, Virginia, Washington, West Virginia, Wisconsin, and the District of Columbia.

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.8.

Current as of January 2021 – Criminal Justice Information Services (CJIS) Security Policy – Microsoft Compliance

Note: This section also applies to CJIS in Azure Government as well.

Microsoft 365 Government (GCC High) + Azure Government

ITAR in GCC High and Azure Government

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 and Azure Government were 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 Azure Government, Microsoft 365 Government (GCC High) and Dynamics 365 Government (GCC High).  For example, the network is sovereign and constrained to CONUS.  The GCC High directory services with AAD are provided by Azure Government and are sovereign to the US.

DoD CC SRG Equivalency in GCC High

We have evolved the US Sovereign Cloud to include PII protections.  PII protections are now all the way up to IL4 in GCC High.  In fact, we manage the GCC High environment with the same set of control scope and ODV’s as the DoD environment.  This translates to SRG ‘equivalency’ of both IL4 and IL5 in GCC High.

However, for most Federal contractors and the DIB, SRG impact level is a moot point.  Technically speaking, the SRG only applies to Federal information systems.  IL4 is not an authorization the DoD will provide to a non-Federal nor private-sector entity, nor is it for a CSP cloud environment not in use directly by the DoD.  For the DIB, DFARS 7012 and CMMC is what applies to non-Federal information systems.  As such, Microsoft has pivoted away from advertising the SRG impact levels in alignment with Microsoft 365 Government (GCC High).  We now focus on how our DIB customers may demonstrate compliance with CMMC leveraging our cloud service offerings.

DoD CC SRG in Azure Government

Cloud services in Azure Government are authorized for DoD CC SRG IL2 and IL4.  In addition, Azure Government has 120 services accredited at IL5 (as of the time of this writing).  These services include a broad range of IaaS, PaaS and SaaS capabilities.  When supporting IL5 workloads on Azure Government, the isolation requirements can be met in different ways. Isolation guidelines for IL5 workloads documentation page addresses configurations and settings for the isolation required to support IL5 data with specific service instructions.

You can find a full list of Azure Government services that meet the requirements of the DoD in the Azure Government audit scope documentation.

For more information, please see Microsoft SRG Documentation.

DFARS 7012 and NIST SP 800-171 in GCC High and Azure Government

Microsoft will sign a contractual Flow-Down for DFARS 7012 in GCC High and in Azure Government.  This translates to a contractual commitment where we demonstrate DFARS 7012 compliance in the US Sovereign Cloud.  This includes DFARS 7012 alignment with NIST SP 800-171 in a shared responsibility model with the Customer.

Note: You may request our Attestation of Compliance with DFARS by submitting a support ticket and asking for a copy.

FedRAMP High in GCC High

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 including a SAR (Security Assessment Report).  We have several Federal Agencies actively deployed in GCC High, demonstrating compliance with FedRAMP High.  The FedRAMP High Agency 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 7012 compliance.  FedRAMP Moderate is specifically required for DFARS 7012.  And for that, we do have a Federal agency ATO currently in place covering GCC High.

FedRAMP High in Azure Government and Dynamics 365 GCC High

As described above for Azure Commercial, Azure Government has a P-ATO for FedRAMP High from the FedRAMP JAB.

You can find a full list of Azure Government services that meet the requirements of FedRAMP High in the Azure audit scope documentation.  You may even observe that Dynamics 365 Government (GCC High) falls under the scope of the Azure Government P-ATO in the FedRAMP Marketplace.

CMMC in the US Sovereign Cloud

You may demonstrate compliance with all maturity levels of CMMC in the US Sovereign Cloud.  We exclusively recommend our US Sovereign Cloud with Microsoft 365 Government (GCC High) and Azure Government for data protection of CUI in alignment with CMMC Levels 3-5.

CJIS in Azure Government

CJIS in Azure Government is aligned with the same description as provided above in the section “Criminal Justice Information Services in GCC”.

CJIS in GCC High

Criminal Justice Information Services in Microsoft 365 Government (GCC High) is described as for “Federal” only.  CJIS Information Agreements are signed primarily at the US State level.  Most US States have Information Agreements established for both Microsoft 365 Government (GCC) and for Azure Government.  However, those agreements are not in scope for Microsoft 365 Government (GCC High).  This is because no State nor local government entities deploy into GCC High.  To date, only Federal agencies and the DIB deploy into GCC High.  Thus, a US State has not had the need to sign a CJIS Information Agreement for GCC High.  It doesn’t mean that GCC High is non-compliant with CJIS.  That is evident as the US Federal Bureau of Investigation (FBI) is deployed in GCC High.  Hence, the FBI has authorized the use of GCC High for CJIS at the “Federal” level.

NERC and FERC in the US Sovereign Cloud

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 the US Sovereign Cloud with Microsoft 365 Government (GCC High) 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.

Customer Support for the US Sovereign Cloud

The US Sovereign Cloud with Azure Government, Microsoft 365 Government (GCC High) and Dynamics 365 Government (GCC High) offer differentiated support staffing, with technical support provided 24×7 by screened US Persons in a US Location.  However, these terms do not preclude the use of global support staff in customer support escalations. It is not uncommon for Microsoft customer support to rely on support engineers that specialize in specific services or technologies and are experts in niche areas.  These support engineers might be located anywhere in the world and could be introduced to provide subject matter expertise and guidance on a specific customer support ticket. Since customer support personnel have no direct standing access to the datacenter nor to customer content, they can only be exposed to sensitive information when it is provided directly by the Customer during a customer support ticket.  We remind you not to share any controlled, sensitive, or confidential information with support personnel as part of your support incident, and follow your own internal data sharing controls, policies and procedures when engaging with Microsoft customer support.

Important:  Within the US Sovereign Cloud, you may request your ticket to remain limited and restricted to “screened US Persons in a US Location” only.  However, availability of the engineer may be limited to US time zones as opposed to 24×7 support.  This may negatively impact the response and mitigation of the Customer support ticket.

Note:  Customer Lockbox for Office 365 is a popular feature to moderate access to your data.   We even have Customer Lockbox for Azure releasing to more and more Azure services.

Microsoft 365 Government (DoD)

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 DoD regions for Microsoft 365 and Azure Government.

Appendix

Please follow me here and on LinkedIn. Here are my additional blog articles: