Microsoft Teams has seen a significant increase due to the ongoing coronavirus pandemic with active daily users now totaling more than 44 million users. Teams was already on an impressive growth trajectory without the impact of a pandemic forcing remote work for all information workers. There’s no doubt that Teams is a phenomenal tool for collaboration, but like any technology providing collaboration and communication, security and governance need to be an integral part of design, implementation and training.
The confusing aspect to Teams governance is the fact that so much of it is not configured or controlled in the Teams admin center – which has enough settings on its own to feel overwhelming. The security and governance settings that impact Teams are found within Azure Active Directory, Office 365 Groups, SharePoint, OneDrive and Office 365 Security & Compliance. It’s important to understand that the files shared, authored and accessed in Teams are ultimately stored in a SharePoint document library. As such, the security and governance controls around those files are managed via SharePoint, not Teams. The same thing goes for OneDrive files shared within Teams.
Microsoft wants to promote collaboration via Teams and Office 365 so almost all of the default Azure AD and Teams settings are set to the most permissive setting and presume that you have other security controls in place such as Azure AD with MFA and Conditional Access, Intune, Azure Information Protection, etc.
So, if you only have time to do 5 things to secure Teams, here’s where you should address first:
- Restrict Azure AD External Collaboration Settings
Azure AD settings are the overarching parent controls that enforce restrictions for the entire Office 365 tenant, regardless of the specific workload or application settings (SharePoint, OneDrive, Teams, etc). As such, the Azure AD settings need to be as relaxed and open as the most relaxed and open workload use case. The default setting allows Office 365 Groups Members and Guests to invite external users (guests) to Office 365 Groups. Office 365 Groups are at the heart of all workloads. Of particular concern is the setting that allows guests to invite other guests. We recommend disabling this setting. Allowing guests to invite guests could allow for exponential sharing of Office 365 content and is nearly impossible to monitor and govern properly. Where feasible, we recommend limiting external sharing to specific domains that represent your customers, partners, vendors and other trusted organizations that you want to explicitly condone and allow external sharing of your Office 365 content.
- Disable Teams Guest Access
The default for Teams Guest access is off, but it’s often changed to “On” during initial pilot testing and before admins really understand the impact. You can still communicate with external organizations via calls, conferencing and chat (see External access settings), but Guest access allows external users to see all the group chats, documents and other Teams content that is part of the non-private Channels within a team. We recommend leaving Guest access off, unless there’s a compelling reason to enable it. If Guest access is enabled, then restricting access by domain in the above Azure AD external collaboration settings becomes imperative.
- Restrict SharePoint Site Sharing
Files shared and presented within Teams are stored in SharePoint so the security and governance around those files is controlled via SharePoint. This makes sense because SharePoint offers content management tools like versioning, co-authoring and managed metadata, but it creates some administrative confusion when it comes to Teams security and governance since securing the files shared within Teams is done via the SharePoint admin center.
From the SharePoint admin center, click on Active Sites:
Check the site external sharing status and note that sites where External sharing is set to on:
If you don’t see the external sharing status column, scroll all the way to the right and click on Customize columns. Check the External sharing column:
If the site does not require external sharing update the site sharing configuration to “Only people in your organization”.
- Restrict SharePoint External Sharing
SharePoint external sharing policies are the root control settings for all SharePoint Online content. The default settings are the most permissive allowed, which means that any external user with a link can view or edit content without the need for authentication. Organizations should carefully review this setting and determine if there’s a strong business case for external sharing with “Anyone”. Decreasing the policy setting to “New and existing guests” is a better option as it requires authentication from external users. The Existing guests setting means that the guest must already exist in Azure AD to access sharing links. This gives IT or administrative personnel the ability to manage users that are added as guests to Azure AD, which then allows users to share content links with those guests as needed.
SharePoint external sharing policies are configured in the SharePoint Admin center under “Sharing” on the left-side navigation menu.
If “Anyone” or “New and existing guests” policy levels are chosen, consider limiting the external sharing by domain and including domains from the customers, partners and vendors your organization needs to collaborate with. The more permissive the sharing policy, the more important it is to train users on security policies for sharing content externally and here’s where the last option to limit external sharing to a security group becomes especially handy. Limiting users who can share content externally to a security group and providing those users with adequate training is key – especially when the other SharePoint external sharing policies need to be set more permissively for valid business reasons.
If “Anyone” settings are used, leverage an expiration policy to automatically expire the links and ensure that they aren’t leaked to unauthorized personnel. Generally, an expiration period of 3 to 7 days for view access and up to 30 days for edit access works well. It’s is better to have users occasionally re-share links due to expiration than to have hundreds or even thousands of content links that never expire. Re-sharing expired links may be a minor inconvenience for end users but the necessary twin of security and compliance is occasional inconvenience.
- Use Data Loss Prevention (DLP) To Protect Personally Identifiable Information (PII)
We are amazed at how little Office 365 DLP is effectively deployed even though it’s included with Office 365 E3/E5, Microsoft 365 E3/E5, and Microsoft Business subscriptions. DLP can be complicated if security standards require it, but there are very basic DLP policies that can be quickly and easily deployed that can go a long way towards protecting confidential and sensitive information from being sent to unauthorized users: internally or externally. Sometimes perfect is the enemy of good and it seems that a lot of organizations don’t put any DLP in place because they want to get it just right. Well, that day never comes and some DLP is better than no DLP.
Office 365 can detect sensitive information types across Exchange, OneDrive, SharePoint, and Teams. Remember, since Teams file content is stored in SharePoint, the DLP policies that apply to those files are based on the SharePoint DLP location rather than Teams. Teams DLP applies only to chat and channel messages.
DLP settings are accessed from the Security admin center, under the Data loss prevention > Policy option on the left-side navigation menu:
Create a new policy by starting with a template or creating a custom policy. A great starting point for US-based companies is to create a custom policy and include the seven sensitive information types that are part of US Financial Data and US Personally Identifiable Information (PII):
Next, choose the workload location. You can choose all four workloads to start with. Note that DLP for Teams chat and channel messages is only available in Office 365 Advanced Compliance, which is available as a standalone option and is included in Office 365 E5 and Microsoft 365 E5 Compliance. Ultimately, separate policies will likely need to be developed for each workload, but to start with we can include all 4 workloads (or 3 workloads if the Teams location isn’t available with the current licensing).
A great way to start with DLP is to set up notifications for any sensitive information being shared outside the organization, without actually blocking it. This will help build a baseline for acceptable activity and help provide the logic to build out the specific DLP policies for different workloads, sensitive information types, and audiences. When the policy triggers, Incident reports can be sent to the Global Admin for review without necessarily notifying users or restricting access to the content.
Optionally, the policy can include user notification and content blocking but can be deployed in either a “test with notification” or “test without notification" status so that the policy can be tested and evaluated prior to making it fully active.
Leveraging DLP and Microsoft's built-in sensitivity types is an important tool for safeguarding confidential information across all workloads.
Of course, there are more than 5 security controls that impact Teams from a security, governance and compliance standpoint and ranking the "Top 5" is subjective. The main criteria considered for this post was the security impact of the setting along with the complexity involved. In other words, the settings that would get the biggest "bang for the buck" if the bang is the improvement in security posture and the buck is your valuable time.
