In preview now: A simpler protection framework for Teams and other Group-connected SharePoint sitesAlex Fields
Microsoft has previously published a framework for protecting Teams. There is another very much like it for SharePoint. The goal was to create some recommendations that “balance security with ease of collaboration.”
It is a fine balance indeed. The most interesting feature of this framework is that Microsoft suggests using retention labels to classify Teams/Sites based on their sensitivity.
“But wait a minute,” you might ask… “Isn’t that what Sensitivity labels are for?”
Well, one might think that. But in practice it has proved difficult to use Sensitivity labels in this manner for several reasons. The main reason is that Sensitivity labels have the power to encrypt the contents of any file to which they are applied using a unique “tattoo.”
And on the one hand, that’s great–because it means the “tattoo” will travel with a protected document wherever it may roam, so that prying and unauthorized eyes can’t read the content whether its in Microsoft 365 or any other cloud, or on local media, or external media, or whatever–the content is always protected.
On the other hand, that level of protection means that SharePoint can’t read the content either. Therefore stuff breaks. Important stuff. Search. Data Loss Prevention. Delve. Co-Authoring. Autosave. Web apps. The list goes on.
By contrast, retention labels do not encrypt content, and so they can still be used in conjunction with other protections, such as DLP. In fact, Retention labels can be used to trigger DLP.
Therefore if your retention label can indicate the sensitivity of a SharePoint library, for instance, you can apply a DLP policy to warn or block users when they attempt to share content from a sensitive, labeled location.
So this is why retention labels are being used in Microsoft’s recommended framework as the basis for sensitivity–because they are visible to DLP, and they don’t destroy other collaboration features.
For the same reason, we are advised to apply Sensitivity labels (manually) only on the most sensitive, Highly Confidential content–and even then the protection is listed as optional. Why?
Because file-level encryption was (until recently) highly disruptive to the Microsoft 365 productivity experience.
This is all going to change…
We had two important previews drop very recently that I encourage you to go and test drive when you get a chance. The first is Sensitivity labels for SharePoint, OneDrive and Office Online.
While they are quick to point out that some limitations / known issues still exist in this preview, a lot of functionality has opened up, and I think we can see the general direction this is all going–Sensitivity labels are going to become a much more integrated and seamless part of the native Microsoft 365 experience–and a more important cornerstone in our Data governance strategy. (We’re not all the way there yet, but its coming).
Integration with DLP is partially included as well (DLP can find content in an encrypted file). And the natural next step of course–if DLP can already read the content within the file–then we should also be able to use the label itself to trigger some action like incident report or notify/block (like we can with retention labels). FYI: so far this feature has yet to light up, even with the preview enabled.
The second big announcement and preview is Sensitivity labels for Teams, Groups and Sites. This is my favorite part–because it means we can allow end users to quickly classify their own content and apply policies like Conditional Access that they would have had to rely on admins for in the past, AND they can do this at the Group/Team/Site level.
Now it is important to note that if a label contains both encryption settings and Group/Site based settings, applying the label on the Group level will not actually apply the label and its encryption settings to the files within. It’s just something to be aware of (you may still want to label individual files for further protection, even inside of a “Confidential” Team, for instance. Remember:
- Encryption = File-level settings (does not affect Groups)
- Site and group settings = Group-level settings (does not affect files)
After building and publishing your labels to include Site and group settings, they will be visible in applications like Outlook and Microsoft Teams. For instance, based on the settings in my Public label, we are restricted from creating a Private team.
So now the whole game changes, right? Retention labels can do what they do best: retain and dispose of information based on compliance requirements and corporate policies. Meanwhile, Sensitivity labels may someday soon live up to their namesake as well!
In the future…
The recent leaps forward with Sensitivity labels effectively democratize security (a theme we’re seeing more and more with Microsoft) and enable self-service data protection, like so:
We’re almost there. In a single label selection users can now define: their own privacy settings, external collaboration/guest access, device-based Conditional access–WOW–this is huge!
It would be nice to tie DLP in here as well, although again at this time I don’t see the option. Even though we cannot build DLP policies based on a Sensitivity label just yet, be patient–it’s sure to turn up eventually.
In the meantime, we could potentially design some Conditional Access App Control policies in Microsoft Cloud App Security that could, for instance, apply a label automatically on download, or block certain downloads from happening outright.
On the other hand, maybe DLP is becoming less relevant in a world where we can apply strong identity-based encryption and access controls to the files and groups themselves without giving up the rich collaboration experiences that we’ve come to love in Microsoft 365.
If a Sensitive file were downloaded to a non-corporate location (if that were even allowed via the label to begin with), just to open the data you would need to pass through Azure AD, MFA, Conditional Access, etc. And if the security boundary gets brought down to the level of the data itself, I think that’s really a unique thing to be able to offer your customers.
What do you think, reader?
Thanks for the great article.
After searching for 2 hours on reliable content of the new functionalities in Sensitivity Labels on SPO,
this article provided some good insight.
However a few questions remain:
– Is it correct that I can still not automatically apply a sensitivity label to files that are uploaded to a specific SharePoint library?
– I cannot see the IRM settings on SPO. Could it be that these are removed when this Preview for Sensitivity Label is enabled?
Had you previously enabled IRM settings? I did not check for this in my testing, but it wouldn’t surprise me if IRM goes away w/ Sensitivity in full effect?? I guess it is another blog for another day! As for auto labeling, in the current preview the only app that is working is Word, so when you edit a document in Word Online, then the online version of Word will apply the label based on the criteria specified. To my knowledge there is not anything yet that “crawls over” content in the repositories online and applies labels. You have to actually open/edit the file, and then the app (e.g. either Word desktop or Word on the web) will look at your available labels and determine if any autolabeling needs to happen based on the content in the document.