Key Teams Governance Gaps to Consider Before Deployment
We recently shared some of the biggest learnings from our customers who were in the midst of piloting Microsoft Teams. One of the major areas of focus centered on Microsoft Teams governance, compliance, and security. While Microsoft Teams has already built in an initial security feature set (one that seems to already be more advanced than that of Slack), it’s important to note that, as with many new apps, the overall security model will need to continue to evolve as new customer requirements and issues surface.
If your team is getting ready to pilot and/or deploy Microsoft Teams, our findings at Unify Square suggest that it’s best for your IT team (or a third party) to be prepared to have a proactive approach anticipating governance and compliance needs and to execute on appropriate solutions before you find yourself in a security pickle.
Key Microsoft Teams Security-Related Areas to Examine
We’ve surfaced the eight most pressing Teams governance issues our customers have continued to work through in their Microsoft Teams pilots:
1. Data residency and multi-geo: Data residency can be a major concern because companies must abide by the data protection and compliance regulations of each individual region and country. Additionally, multi-national companies often need to split their user bases across global datacenters (e.g. EMEA, APAC). Microsoft offers data residency to give enterprises control over where their global data is stored. Microsoft has also introduced Office 365 multi-geo capabilities which focused on using geo-satellite locations based on a central location with information managed in a central Azure Active directory.
Multi-geo services currently exist for Exchange Online and OneDrive, but are in preview or under development for SharePoint Online and Teams.
2. eDiscovery: With large enterprises being at risk for high penalty legal proceedings that require all Electronically Stored Information (ESI) to be submitted, concerns from legal departments arise around 1:1 chats as they create a greater legal exposure surface. Not only is this more data (in addition to the current set of “formal” discussions in email that legal has to manage), but it’s also potentially more risky informal chatter, which may not be as professionally structured by the users – thus leading to even greater exposure. Assuming that customers are even able to become comfortable having the casual persistent chat data exist in an archived state at all, the need is then created for legal hold functionality and/or single employee search and data isolation.
Office 365 allows organizations to perform Content Search and eDiscovery as well as Legal Hold within Teams content, preserving the original content and metadata for ESI in order to eliminate claims of spoliation or tampering with evidence later. However there is little to no additional operational guidance provided by Microsoft. Third party services are available to help with Microsoft Teams compliance, including services that capture all Teams conversations, enable compliance groups to review Teams content, and provide rapid search and legal hold.
3. Data Lifecycle management: Microsoft still has some holes in this part of their model for Teams. The most common questions organizations should ask include:
- How can files in Teams (stored in SharePoint online or OneDrive) be classified and tracked over time, from an Information Classification standpoint?
- How can data assets be auto-expired?
- How can orphaned content be recovered?
- How can naming conventions be put into place to ensure that data isn’t lost or mislabeled?
4. App management: Opening up the App Store for users can pose a difficult question for IT teams: How can IT ensure that certain apps (such as tabs, connectors, bots, or a combination) aren’t sending confidential data to a 3rd party that has not yet been vetted from a security stand point? Currently, Microsoft has Teams admin settings that can be configured in the Office 365 admin center that gives control over which external Apps are allowed.
However, many customers are ideally looking for a Microsoft report which details which teams and/or groups are using which connectors. From there IT also needs a “kill switch” to temporarily quarantine all not-yet-approved connectors until they can be vetted.
5. Permissions Model: Microsoft recently rolled out guest accounts for Microsoft Teams. This means guests (those who are not employees, students, or members of your organization) can access teams, documents in channels, resources, chats, and applications. All of this guest access will occur while covering these guests with the same compliance and auditing protection offered by Office 365. These settings can be managed securely within Azure AD.
The potential issue here is that IT can’t really control whether (or when) the organization is sharing private information with external parties. Further, in general, Teams is missing an overall permissions model (including guest access) between Teams, Office365 Groups, SharePoint, OneDrive, etc. IT teams should take extra precautions to properly configure guests in Azure AD, as well as remind their organization about shared files. Currently, Microsoft does not provide channel exclusivity, meaning that if you’d like to work on a project with a guest, but don’t want them to have access to other files in the Team, you’ll have to make a separate Team for this project.
6. Team and Channel creation and naming: It is, by design, very easy to create and name teams and groups within Teams. A person who sees the glass as half-full likes this approach to help facilitate and drive user adoption. The glass half-empty IT person may fear this tactic because sprawl and duplication, as well as GAL/AD confusion can lead to extra policies and additional headcount to govern (and then enforce) these policies. A few of our pilot customers have considered creating naming conventions for Teams and Channels. We often see large-scale Slack deployments with naming conventions in place (and enforced by champions); a similar model might work well with large-scale Teams deployments.
In either case, IT teams should do the heavy lifting early on to help users understand best practices for team vs channel creation.
7. Hierarchical vs Flat Groups: The previous standard with email and DLs (distribution lists) has been to have hierarchical or nested groups. From a security perspective this allows for enterprise-scale administration of access rights. In Teams, however, everything is currently flat – it’s an all or nothing world. Going back to the permissions model concer with Teams, if someone has access to a team, that means they also have access to all of the channels within that team. This can be a serious security concern because there’s no way to limit information visibility within a team.
This can pose a challenge when incorporating guests or discussing sensitive material. Currently, IT teams should make this clear to their organizations, and encourage document sharing to be taken with precaution on channels with guest access.
8. Exfiltration Risk: Microsoft Teams enables easy knowledge sharing through the use of voice, chat, and file sharing. However, with more than 20 percent of files in the cloud broadly shared, and 71 percent of high risk cloud behavior indicating a data exfiltration risk, it will be crucial for Microsoft Teams to offer similar protection as it does for emails.
While Microsoft has Data Loss Prevention (DLP) capabilities and other security features on its roadmap, organizations should consider third party solutions to monitor and protect potential data leaks.