Resources Blogs Office 365 Governance in the DOD: Explained

Office 365 Governance in the DOD: Explained

Post Date: 07/29/2020

Learn how to safeguard your information in Office 365 with our webinar “Protecting Sensitive Data in Office 365 at the Team and Data Levels!”

This is the 2nd installment in a series addressing the challenges facing the DOD as they move into Microsoft 365. The others are here:

Two weeks ago I shared my thoughts about DISA’s post-CVR Office 365 plans supporting the 4^th Estate and COCOM’s. I want to expand on that post and talk further about governance.

Establishing an Office 365 management framework that allows for delegated administration opens the door for each command to bring their own policies and decide how to govern their corner of the tenant.

Collaboration in Office 365 for DOD

The DOD has been leveraging Microsoft’s solutions for decades and is very familiar with Exchange for email and SharePoint for collaboration, but CVR introduced a new technology with Microsoft Teams that changes the dynamic for how these services are used.

For instance, in traditional IT management teams we often find dedicated groups managing email, collaboration, storage, and messaging/conferencing. I’ve seen even further segregation between Operations and Knowledge Management as to who owns SharePoint and who governs/manages the data that resides within.

The CVR was specifically limited to Teams, but let’s take a look at how creation of a Team in CVR will effect the rest of the DOD 365 environment come December.

Did you know that creating that Team in CVR created an exchange element (Office 365 Group with an inbox and calendar, to be specific) and a SharePoint Site Collection (not subsite) specifically tied to itself? It made the requester an administrative Owner in Teams AND a Site Collection Administrator in SharePoint. Any controls available to highly-trained SharePoint Administrators (at the Site Collection level) are available to the one who created their Team. And, as the “Hub for Teamwork” it also optionally connected users to a shared OneNote, Planner, and other Office 365 services.

Figure 1. Teams is the Hub for Teamwork and thus connects business users to tools across Microsoft 365. It also makes often un-trained business users Owners and Administrators across the platform.

This creates management challenges because if Teams touches all these traditional IT management teams…who owns it? Who sets the policies? Who sets governance? Who is the authority?

Governing Your Corner of the Office 365 Tenant

My previous post focused on the concept of “one tenant, one rule,” meaning that in Office 365’s centralized IT structure all tenant users and collaborative workspaces (SharePoint Site Collections, Office 365 Groups, and Microsoft Teams) abide by the same policies. While the DOD is built upon top-down governance, each command is not only traditionally used to managing their own Collaboration systems, but they have their own policies and procedures. Hence, I recommend that the DOD plan for a model which takes into account each command’s requirements and allows them to combine a scope of content with RBAC (Role-Based Access Control).

With all that settled, what exactly are we talking about? What has Microsoft Teams changed?

As the catalyst through the CVR and a central element of Office 365, Microsoft Teams brings a model of administration that focuses on the end user. By default, creation of workspaces is at the end user level. Administrative privilege is set by the requester, not a trained KM or J6 technologist. Decisions on the template used, policies set, specific uses and design of the Team, and much more are pushed down to the end user. After all, the end user knows best what they need to be successful, right?

We’ve helped many organizations kick off their Microsoft Teams Governance plans, and the starting questions are universal across commercial, state and local government, federal civilian, and defense; here’s just a few to kickstart the ideation:

Have questions about governing DOD 365? Check out this post: Click To Tweet

Provisioning
- Who can create a Team? How much burden can we place on IT to do this?
- Is there a naming convention to follow? More than one?
- Is the Team public or private? What about Private Channels?
- Do some workspaces require an approval process? Management? Cybersecurity?
- How does Teams integrate with our SharePoint intranet and existing workspaces?
Management:
- How will permissions and access to workspaces be re-evaluated?
- Can we setup an approval process for changes to permissions? Do the right people continue to have access?
- Does IT need to be engaged for every change to the Team?
- Can we trust the end user with administrative control over their Team?
Lifecycle:
- How often do Teams need to be reviewed?
- When should a Team be retired? What qualifies as “retired?” Who owns this decision? What’s the process like?
- Do we care about Teams sprawl? SharePoint sprawl? How do we manage it?
- Do Teams contain CAPSTONE material or Records? Can we retire a Team with Records?

office 365

These may seem innocuous, but let’s look at a simple one to showcase the potential pitfalls facing DOD 365: Naming Conventions.

When an end user creates a Team, they create a SharePoint Site Collection and an Office 365 Group (that pesky Exchange element). In IL5 that group is visible in the Global Address List, too. This is important because SharePoint teams and Exchange teams generally each have their own naming conventions, so step one is to ensure their naming conventions now match.

On top of that, with the bottom-up model of Microsoft Teams, anyone can name their Team as they wish—titles earmarked for CIO or Operations could be (and have been) taken by users downrange focused on their collaboration circle and not factoring in the whole enterprise. Operations is a pretty common term—even in the DOD where everyone knows Operations is the J6, we saw Operations Teams created by end users in the CVR not only result in naming policy issues but also confusing end users who have expectations about those specific names and how they ‘ll be used.

Naming Convention tools in Microsoft 365 can help some here; blocked words lists are available, and customizable. And you can set up a policy, such as COMMAND_ORG_UserProvidedName, and we would end up with CENTCOM_J2_Operations. However, what if CENTCOM and DTRA have different policies they want enacted? And what exactly would it take for a central governing body to manage the intake requests of an estimated 700,000+ users in DOD 365?

We could follow this path on any number of topics: permissions recertifications, approval processes, public vs private spaces, and so on. Governance is a robust and challenging topic but not insurmountable. There is hope!

Automating Governance and Self-Service

In the last article, we broke down Delegated Administration as a solution to command autonomy. That approach focuses on the administrator and IT staff performing their management jobs, but it still requires a significant onus on that small group to manage many users.

Now let’s talk about Automated Governance.

AvePoint started in the SharePoint management space providing administrators the ability to create a catalog of self-service operations that had pre-defined governance rules. For example, a user that wanted a new SharePoint site could enter the service catalog and fill out a form, capturing all the information IT needed for that site. If the request is standard and requires no additional approvals the software would create the site, apply the policy rules, and add the members all without IT intervention.

The growth of Office 365 encouraged us to expand this capability beyond SharePoint and address all Microsoft 365 collaboration workspaces (Teams, Groups, and SharePoint). This catalog provides end users the tools they need to meet mission requirements while staying within predefined IT policies and providing automated approvals. Automated, conditional approvals. Automated, conditional, multi-stage approvals. You get the point.

To the end user, they are simply using a service catalog to request new workspaces, manage their existing workspaces, or working with built-in lifecycle management actions. It’s seamless, and it ensures they follow the right IT processes without needing to KNOW the policies.

In recent discussions with a COCOM that is in Office 365, they expressed the frustration that’s involved with using permission recertification because if it’s applied to one Site Collection it’s applied to all. Consequently, Site Collection admins are getting bogged down with continuous approval requests even for low risk sites.

In the above example, AvePoint’s Governance platform would give this particular command the ability to tailor Microsoft 365 to their management strategy without affecting the policies of other commands. It would leverage automation to not only proactively enforce governance, but also granularly apply that permission recertification policy solely to the sites that require it, lessening the management burden to the whole of DOD 365.

Governance is difficult, but software can make end users productive, secure the workspaces, and not overwhelm Operations teams. Have questions about anything we went over today? Drop them in the comments below!