Protecting Office 365 Groups and Microsoft Teams with Sensitivity Labels (Preview)

I often end up in one of two conversations around Microsoft Teams governance with customers, the “Users can manage them themselves so we don’t need to worry” group, and the “Nobody gets a Team unless we follow this 20 step approval process and our service desk needs to set them up and lock them down” group.

Both options have their merits, but also their pitfalls. If we let everyone create teams we end up with sprawl and have no idea where our data is stored (why are there six “HR Teams”, and which one contains the right data?). On the other hand, if we don’t let our users use Teams without jumping through hoops while saying the alphabet backwards, in Latin, then we are preventing people from using some of the most powerful collaboration features available to them.

We usually end up finding a good middle ground in these discussions that leverages automation and some of the cool Information Protection features of Microsoft 365. My opinion on Teams provisioning process has been the same as it was for SharePoint sites, “I don’t care if we have ten thousand Teams, as long as they are named and protected correctly, the number doesn’t matter”.

This opinion was idealistic in the early days of Microsoft Teams as the governance features just weren’t where I wanted them to be. In the past year, Microsoft have taken strides in the features available and I’m pretty happy (albeit still a few features I’d like) with what’s available. I might even do a follow up post where I can rant about my Teams security and governance opinions down the line.

One feature that has made my life much easier since it was made available (in Preview) is the ability of Sensitivity Labels to be applied to Office 365 Groups / Teams / Sites . This feature allows us to define Sensitivity Labels which, when applied to a Group, can control the privacy level of the Group, the level of functionality available to unmanaged devices, and even the external access configuration.

During some early Teams projects I had automated scripts which changed these group settings in Azure AD, SharePoint sharing settings on the site level at the time of provisioning. That was a nightmare as it had to be maintained and knowledge transferred to the incumbent IT Teams.

When this feature is enabled, we just need to specify the settings in our sensitivity label and it’s all taken care of for us.

The site and group settings tab

To enable this feature for your tenant now, connect to the Azure AD Preview PowerShell Module and run the below to update the Directory Setting and enable MIP Labelling in Office 365 Groups.

##Copy Current Settings to $Settings Variable
$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id

##Change EnableMIPLables setting
$Setting["EnableMIPLabels"] = "True"

##Write back changes to directory
Set-AzureADDirectorySetting -Id $Setting.Id -DirectorySetting $Setting

Next, connect to the Security & Compliance PowerShell Module and run the below to start the synchronization process between MIP and AAD.

Execute-AzureAdLabelSync

After a little time to replicate, you will be able to see the above page when configuring a new sensitivity label and then apply them to Teams/Groups/Sites and once the labels are deployed (usually 24 hours after creation) you’ll be able to apply them at provisioning time!

Using Sensitivity Labels as Conditions in DLP Policies (Preview)

Sensitivity Labels have quickly become a core component of any Enterprise level Microsoft 365 tenancy. Information Governance is becoming more and more relevant in the Cloud space where we potentially have a enormous amount of disparate unstructured data in various Teams, SharePoint Sites, OneDrive etc.

Depending on the license SKU, Sensitivity labels can allow manual or automated protection of data – at an item level – based on predefined or even Machine Learning modeled classifications (Trainable Classifiers). We can even classify Office 365 Groups/Microsoft Teams for some cool features.

Another piece of the Information Governance puzzle is Data-Loss Prevention (DLP). DLP allows us to Prevent data leaving the organization via file sharing and/or Email. We typically define DLP policies to protect data based on contents such as keywords or particular patterns.

As of this month, we get access (in Preview) to the ability to use Sensitivity Labels as criteria in DLP Policies! This not only prevent double up of work aligning sensitivity and DLP policies, but allows us to protect that data that users classify themselves or even as a result of our Trainable Classifiers.

In the below example we are creating a custom DLP Policy which we will configure to detect a particular sensitivity label added to our content.

We exclude Teams Chat and Channel messages from the policy as they can’t be applied sensitivity on their own so are not supported for this policy. (Teams file sharing comes from SharePoint so we’re still covered there)

And that’s it, we’ve protected our Sensitivity Label with DLP! All that’s left is for us to assign our actions and we’re done!

This is a really nice addition to the feature set for Microsoft 365 Compliance and helps tie together some really powerful features, giving admins better control over data egress. If you haven’t already, it’s definitely worthwhile checking out some of the other Information Protection features available in the Microsoft 365.

Microsoft 365 Compliance Manager goes GA!

On the 22nd of September the Microsoft 365 Compliance Manager came into General Availability. Available in the Compliance Portal, the Compliance Manager helps organizations with Microsoft 365 to gain control over their compliance and risk state. In this post, we’ll look at some of the features available in the Compliance Manager.

The first think you’ll notice when opening the tool, is the Compliance Score rating. This rating which is based on a range of both Microsoft and Organizational controls, gives a quick metric of the compliance performance in the organization.

Like the traditional Secure Score, this score is relative to Microsoft 365 but may not reflect the overall security posture of the organization. For example, you can gain 27 points by implementing a spam filter, however, Microsoft’s tools will not be aware of a third party spam filter that sits in front of Exchange Online. Note: Automated tests are not available for all actions so it’s important to manually review them. We can enable automated testing on all or a subset of actions in the Compliance Manager Settings.

When we open a particular action, we can see associated regulatory requirements, details on how to go about implementing the action and any uploaded supporting documentation and notes detailed by the actions owner.

From the action itself, we can edit the status to assign someone to update and/or add the detail ourselves.

Once updated ,if completed this will adjust our Compliance Score appropriately.

From the solutions page in Compliance Manager, we can see how the different tools can help us to address our open actions. We can even open the relevant tool directly from this page allowing quick navigation and resolution.

Finally we can create assessments based on existing or custom templates such as EU GDPR assessment to group controls and actions to reach compliance with particular standards.

We can track progress against these assessments separately to our overall Compliance Score and also view any associated controls/actions.

The Compliance Manager brings some really powerful functionality to Microsoft 365 and as more automations for testing become available will help to simply what can be a tedious process to move towards compliance with various standards.

While in Compliance Manager, it’s also worth looking at some of the other great tools in the Microsoft 365 Compliance Portal as it gains more and more functionality and separates itself from the legacy Security and Compliance Portal.

Easily Enhance Microsoft Search with Organizational Data

Microsoft Search, particularly when effort is put in to build metadata and Organizational Information is an extremely useful tool that doesn’t always get the credit it deserves (probably partially stemming from the consumer experience with ‘bing’ over the years).

Organizations can leverage Microsoft Search to help their users locate information extremely quickly and efficiently – Providing the right change management and training plans have been put in place to help change user behavior.

Microsoft have recently made available a host of cool admin tools to assist with configuring Microsoft Search to give users the best experience. Features like the Graph Connectors for Microsoft Search unlock a host of possibilities for extending Microsoft Search outside of just Microsoft 365.

An even easier method of enriching the Search experience is to add some organization data in the Microsoft 365 Admin Portal. In the below screenshots, we have added a few options into the Microsoft Search config:

An Acronym:

A bookmark:

A Q&A entry:

We can even enhance some of our options by linking to PowerApps, external sites and scoping the results to specific user groups.

Our users can then search within Office 365 and find our predefined results:

That’s really cool, our users can search in the Office Portal but it could probably be fancier. This is where Edge (Chromium) comes into play. The built in Microsoft Search functionality allows these result to surface as part of a regular web search:

Once the user is signed into Edge with their corporate account they will see the “Work” option in their search results. The search functionality can be used to search our entire organizations Microsoft 365 data including any Graph connectors to external systems and can even be triggered from Windows 10 machines local search bar. This is an extremely powerful tool for users to navigate very quickly and find the answers they need.

Prevent Office 365 Groups/Teams from provisioning Power Bi Workspaces

Office 365 Groups/Microsoft Teams contain a host of useful components such as SharePoint, Exchange Online and Planner. Another component of Office 365 groups by default is a Power BI Workspace.

There are two types of Power BI Workspaces: Classic and Modern Workspaces. Modern Workspaces allow for granular permissions and are standalone objects with an enhanced feature set . Classic Workspaces however, are essentially Office 365 groups and access is managed by group membership. For most use cases Modern Workspaces meet all requirements for Power BI.

The impact of having many Classic Workspaces is that you also have many Office 365 Groups, potentially not following governance process that is applied to something like Microsoft Teams. You also do not necessarily want a new Power BI Workspace to be provisioned for every Team, Group, Planner, Modern SharePoint Site etc. that is created in the environment.

Luckily, by setting the option: “Power BI Block classic workspace creation” to Enabled, we can prevent the creation of Classic Workspaces. With this enabled, new Office 365 Groups and any associated objects will not provision a new Power BI Workspace. This helps keep our Power BI environment tidy and limit sprawl.

While here, there are a lot of options that can help us control the Power BI platform and protect against external sharing, data export etc. It’s also worthwhile limiting the creation of Modern Workspaces to a specific group of users who have received training and you can trust to adhere to corporate policy.

There are a lot of configuration items in Power BI that tend to be missed as Power BI itself can be user driven with little IT input into usage. I recommend reviewing these settings periodically to ensure there are no potential risks with the default functionality.

For more information of what makes and Office 365 Group, I highly recommend this page.

Azure AD Sign-ins Conditional Access Policy Details (Preview)

Azure AD Sign-in logs are the go-to place for troubleshooting user sign-ins, tracking malicious login attempts and analyzing Conditional Access policies for Microsoft 365. There are a lot of recent updates which make traversing the Sign-in logs more user friendly and speed up troubleshooting. Some of the recent updates are visibility of refresh tokens and application sign-ins. Another interesting feature currently in Preview is Conditional Access Policy Details.

The new Policy Details slide out gives us a fantastic, easy to interoperate view of the logic behind if a policy has been applied or not. To access the Policy Details feature, simply navigate to a user sign-in as normal and open the Conditional Access tab.

From here, click on the name of the policy and the Policy Details pane will slide out from the right of the page.

Here we can see step by step exactly what happened with our Conditional Access policy. We see the criteria applied in the policy and the results of each step. This feature adds to the already brilliant Azure AD Sign-In logs experience and will save admins a lot of time troubleshooting and testing Conditional Access Policies.

For more information on using the Sign-in Logs, check out this Microsoft Article:

PSA: The importance of disabling legacy authentication in Microsoft 365

This topic seems talked to death nowadays. Almost everyone has come across the strong recommendation to disable legacy authentication in their Microsoft 365/Azure AD tenancy. If you haven’t done this yet then the clock is ticking down to the day Microsoft disable the functionality automatically – October 2020 for new tenants at the time of writing. 2021 for existing.

Something that I find is not as widespread as the recommendation to disable, is the reason behind disabling it. Other than stating it is ‘unsecure’ and vulnerable to password spray and brute force type attacks, there are not a whole lot of real world examples of the issues with legacy auth for Microsoft 365 readily available. A lot of the high level messaging relates to Modern Authentication allowing us to use Conditional Access and MFA but not many examples of why.

To understand, let’s take a typical Azure AD Conditional Access Policy which enforces Muti-Factor Authentication on all Android Devices:

The above policy should enforce MFA on Android devices connecting to our Office 365 service. Now when we log in as this user from an Android device and app/protocol that support Modern Authentication, we can see Conditional Access applies and our user is prompted for MFA.

We can check the Policy Details to see the Conditional Access criteria too.

Great, our user is protected by our Conditional Access policy, we’re secure….right? We can sleep soundly knowing we have the extra protection needed…

Well, now lets try sign in with a third party app using POP3 and Legacy Authentication.

Looks like our user got in without issue and Conditional Access checked the sign-in attempt successfully, however when we look at the details of the policy applied, we see a problem…

Our Conditional Access policy didn’t apply! Looking at the Conditional Access Policy Details we can see that the Device Platform condition wasn’t met.

When we look at the sign in logs we see why.

We don’t have any of the additional details we would generally see with a sign-in using Modern Authentication. As this detail is missing (In this case, Conditional Access is unaware we are coming from an Android device), our Conditional Access policy doesn’t know it should apply and the user bypasses our MFA requirement.

This is just one of many real world examples of where Legacy Authentication creates gaps in our security policy. By now, hopefully almost every tenancy is disabling or working to disable Legacy Authentication. As it stands Microsoft will enforce this change in the very near future so there is still time for anyone who hasn’t taken this step to prepare for that date.

Hopefully this post helps to put the associated risk into real world context. For information on how to disable Legacy Authentication, check out the Microsoft Documentation.

Turn off message preview for Teams notifications

With the extraordinary uptake of Teams in recent months, a lot of users are still finding their way around what they can and can’t do and how to customize their Teams client settings. One thing I’ve seen cause problems (particularly on screen shares during meetings) is the Teams notification message preview.

When sharing a screen through Teams or any other app, there’s always the possibility that something might pop up that not everyone should see. I’m always nervous when I see something like this pop up during a meeting screen share:

Sharing a single app can help to minimize this risk but it’s not always practical. It also doesn’t help when presenting a screen in person. Beginning in October 2020, Microsoft are rolling out the ability to turn off the message preview function to Teams clients. This will be available in the Teams client settings notifications section.

Teams notification settings

This is another great quality of life feature that users will enjoy. It may help prevent some embarrassing pop ups going forward. I’d also recommend looking at the focus-assist settings in Windows 10 to minimize notifications.

Auto-Forwarding Default Change for ATP Outbound Spam Policy

A very popular attack upon breached email accounts since the forwarding feature became available is for the attacker to create a auto-forwarding rule in the users mailbox to essentialy receive a copy of all mail that is sent to that account. This forwarding is extremely quick to set up and not easily found as most users do not regularly check their mailbox rules.

It has become common practice to disable external auto-forwarding as part of a standard build of any mail system and for Exchange Online, it has been built in as an option to disable. Previously this needed to be changed for most tenancies as the default setting “Automatic”, allows auto-forwarding.

As of 16/09/20, Microsoft are rolling out a change to this default setting. Going forward, the “automatic” setting will disable auto-forwarding. Any tenancies which have the default setting should review their requirement for auto-forwarding and assess if it is required.

If auto-forwarding is unavoidable in the organization, there are several options to help protect against malicious attacks.

New inbox rules which set up auto-forwarding can be detected using an alert policy in the Security and Compliance Center to help give visibility of when forwarding rules are enabled. This is a default alert but I’d recommend increasing the severity.

Existing inbox rules can be assessed with some quick Exchange Online PowerShell. For large environments it may be worthwhile exporting this out to CSV for review.

Get-mailbox -ResultSize unlimited | foreach{get-inboxrule -Mailbox $_.identity | ?{($_.redirectto -ne $null) -or ($_.forwardto -ne $null) -or ($_.forwardasattachmentto -ne $null)}}

Finally, if auto-forwarding is a must, we can lock down who we auto-forward to. We can do this by first creating a new remote domain in Exchange Online and allowing auto-forwarding on that domain. Then we can freely disable auto-forwarding on the Default remote domain.

Ideally the changes Microsoft are making do not affect your environment as auto-forwarding is not enabled currently but if it is a business requirement, hopefully the above suggestions will help to secure and control auto-forwarding.