Site Sensitivity and the Documents within

Reading Time: 6 minutes

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.

Roadmap

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.

Audit activities


 

Container Sensitivity

The 3 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:

  1. Privacy of a Microsoft 365 group-connected team site (Is it public or private?)
  2. 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. Note: This setting is NOT referring to the ability to externally share content from the site. This is (currently) not controlled by the sensitivity classification of the container. You would still be able to share a file with an external user on a site that doesn’t allow external users at the container level if your tenant/site is configured to allow external sharing.
  3. Conditional Access for unmanaged devices when accessing the container

Define sensitivity label controls

A few important things to understand about this:

This is placing controls at the container level providing some access control. The 3 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 (Reference: Microsoft Cloud App Security and Sensitivity Labels)
  • Eventually… maybe… although not sure how this will be implemented: documents within a container will 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.

Site Sensitivity

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):

Sensitivity label priority

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.

Email warning

Guest message
If a guest has added a file with higher sensitivity

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)

This slideshow requires JavaScript.


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.

This slideshow requires JavaScript.


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. For instance, coming soon will be the ability to enforce MFA on a site based on its sensitivity classification. A good thing.

Thanks for reading.

-JCK


Credit: Photo by Ann H from Pexels

4 comments

  1. I am waiting for MS to provide platform or service level publishing of labels. Because the label controls may only apply to sites and have no reference on a site level. If a company has a classification “General” this may be public/private (I know they have added None) or external/internal, you cant guarantee the external access based on classification, and applying this label “blocks” graph api from overriding allowexternalaccess

  2. Great article as always. It is worth noting that the Sensitivity Labels are applied at the Site Collection level, and although you can currently set them at the subsite level, they will apply to the whole collection. So, if your architecture has many different classifications of site docked inside a collection then this may need to be rearchitected to make use of these labels.

    Also, there is currently no way to disable the automated email, or customize it. I believe MS are planning to offer the ability to turn this off at a tenant level to enable adoption without it.

    1. Hi James,
      This is yet another reason for avoiding subsites. If an org has decided to use subsites, then they need to realize they have to be the same sensitivity classification.
      When I find out about how to disable the message, I’ll include something in the post.
      -JCK

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.