Now that we can define some protection controls with a sensitivity label definition for SharePoint sites, Microsoft Teams, and Microsoft 365 Groups (referred to as the “container” for the remainder of this post), this starts to give us more control over the container once a sensitivity label has been applied.
[June 2020] This feature is in Public Preview. It can be enabled on your tenant using PowerShell using instructions in the link above. Microsoft has provided this roadmap for sensitivity labels in SharePoint and OneDrive.
[October 2020] If you want to turn off the email notification for notifying a user/owner when a document with a higher sensitivity level is stored on a site with a lower sensitivity level, you can use the following cmdlet: Set-SpoTenant -BlockSendLabelMismatchEmail <boolean>
[June 2021] Included the ‘external sharing’ setting that is now a property of a sensitivity label definition for site and group settings.
The roadmap below is included to highlight the changes that have been implemented since this post was originally published. Item 4 under ‘Top of mind’ is still not implemented.
This post focuses on the current interplay between a container’s sensitivity and the documents sensitivity living within it… something important to understand.
Currently, you cannot “lock in” the sensitivity setting for a container nor ask for a justification when changing it; however, this activity is logged in the Unified Audit log with the activities circled. You will see the old and new value when you change the sensitivity label.
Container Sensitivity
The 4 controls highlighted in the sensitivity label creation wizard shown below are applied to the container when the sensitivity classification is assigned at either container creation time or after-the-fact:
- Privacy of a Microsoft 365 group-connected team site (Is it public or private?)
- Guest access – whether external users can be added to the site. Remember, the ability to add external users must be enabled at the tenant level first in Azure Active Directory.
- External sharing to control if site content can be shared externally.
- Conditional Access for unmanaged devices when accessing the container. In preview, you can associate an authentication context with the label to enforce, for example, MFA, under certain circumstances.
A few important things to understand about this:
This is placing controls at the container level providing some access control. The 4 controls do not automatically assign that same sensitivity label to all documents within the container (although Microsoft is considering some capability to do this based on the roadmap). Because of this, you will still want to ensure individual documents within the container have the correct sensitivity label applied to implement the required controls and protection at a granular, document level.
Note: This will continue to hold true even if documents will eventually “inherit” the container’s sensitivity classification as there may still be times when you will store a file with a different sensitivity classification than the container it’s stored in.
Ways to set a document’s sensitivity
Here are some ways to ensure your documents have the right sensitivity setting:
- set a default sensitivity label in the label policy published to a user (warning: doing this, you run the risk of your default label being less sensitive than your container classification may be since this is not a container-specific setting, but a user setting)
- leverage client-side labeling: use auto-apply functionality to apply sensitivity labels to content where sensitive information type(s) are detected right when you’re working with a document from within Microsoft 365 apps (Office 365 ProPlus/Business client apps)
- leverage service-side labeling: use auto-labeling policies to apply sensitivity labels to content at rest in SharePoint Online (and OneDrive for Business) based on sensitive information type(s)
- leverage Microsoft Cloud App Security: by integrating this with Sensitivity labels you can automatically apply sensitivity labels on a specific library location. Note that there are limitations to this approach. (Reference: Microsoft Cloud App Security and Sensitivity Labels)
- Eventually… maybe… although not sure how this will be implemented: documents within a container may inherit the sensitivity classification of the container. Microsoft is considering this option.
End-user education
To help end-users safely handle their sensitive content, let’s look at what happens if a document was created/uploaded to a container with a sensitivity label more sensitive than the container it was uploaded to…
Below I’m showing a SharePoint communication site called Legal Affairs that has been classified with a Confidential sensitivity label.
I created a new document in Some Random Library in the site and decided to set the sensitivity of the document to Super Secret. In this tenant, the Super Secret sensitivity label is MORE sensitive (higher priority) than the Confidential sensitivity classification assigned to the Legal Affairs site (image):
Nothing prevented me from assigning the Super Secret sensitivity label and storing the document on the site, however a few minutes later I received an email advising me/warning me of the potential risk of what I had just done.
Two variants of the email text are shown below – the wording may change over time (circled), however I believe the intent of the message is to highlight to the end-user that either they (or a guest on the site if they’re an owner) has added/uploaded a document with a higher sensitivity than the site is set at.
Why would this matter?
What’s the risk? The sensitivity label on a document protects the document regardless where it is stored, or whatever device it is accessed on because the sensitivity is stored with the document. Why would it matter if you stored it on a site with a lesser sensitivity control?
Although the protection controls would still be applied to the document based on its sensitivity label, there are a few scenarios I can think of where it would matter:
Scenario 1: If the site’s classification allows guest users to be added to the site and you store a document with a higher classification on it that should prevent external to access it, an external user won’t be able to open the document (they’ll receive the ‘Sorry, you don’t have permission to open this document’ message), however they will still be able to see the document listed in the library. Sometimes just seeing the title/properties of a document is a security risk.
In this example, an external user invited into a site classified as General can still see the Top Secret documents in the library even though they do not have permission to open them. (assuming the Top Secret sensitivity label has been configured with Rights Management to prevent access)
Scenario 2: Imagine you have the following 2 sensitivity labels defined with the following unmanaged device settings (image):
- General: allow full access on unmanaged devices
- Top Secret: block access on unmanaged devices
If you were to upload a document labeled as ‘Top Secret’ to a site classified as ‘General’, you would still be able to open this document from an unmanaged device simply by it being stored on a site with a lower classification (assuming you had sufficient rights to open it).
This is because, at the current time, the unmanaged device controls are at the site (container) level only and NOT at the document level.
Scenario 3: Reinforcing good end-user behavior when handling sensitive content.
It’s always a good idea to let a user know they’ve done this in case it was not intentional or if they don’t realize they’ve stored a document that is considered more sensitive than what the site will allow. It’s the pause this creates that allows an end-user to validate/acknowledge their action. Although an end-user is free to ignore the warning, the email suggests some follow-up actions for the end-user to take:
- move the file to a different site
- change the sensitivity label on the file if it was the incorrect label
- change the sensitivity of the site
I’m looking forward to the additional controls that will be associated with a sensitivity label over time at both the granular, document level, as well as at the container level.
Thanks for reading.
-JCK