Constant and Evolving Change to Improve Sensitivity Label Functionality
Microsoft released sensitivity labels for Office 365 in September 2018 to replace Azure Information Protection (AIP) labels. At the time, sensitivity labels offered limited functionality and required users to install a separate client before they could apply labels to Office documents. Since then, Microsoft has steadily pushed out new features and capabilities. Perhaps 2023 will be the year when your organization deploys sensitivity labels to protect and classify information stored in Exchange Online and SharePoint Online.
Licensing Sensitivity Labels
Sensitivity labels are part of the Microsoft Purview Information Protection product. Anyone with an Office 365 license can read documents or emails protected by labels. Users require Office 365 E3 or above to apply a label manually, while automatic policy-driven application of labels requires Office 365 E5 or the Microsoft 365 E5 compliance licenses. Automatic is a broad term and includes assigning a default sensitivity label for a SharePoint document library (the same requirement exists to apply a default retention label for a document library).
Users who don’t belong to a Microsoft 365 tenant can still receive and access protected content. In these scenarios, attempts to access the content will redirect to the Office 365 Message Encryption (OME) portal. Once authenticated, the user can read the content.
Managing Sensitivity Labels
Sensitivity label management is through the Information Protection section of the Microsoft Purview Compliance portal (Figure 1). Note that each label has a priority number from 0 (zero – the lowest priority). SharePoint Online uses the priority order to decide if users store confidential information on sites intended for more general access (a label mismatch).
The tasks involved in managing sensitivity labels are:
- Defining the usage of the labels.
- Defining settings for individual labels.
- Publishing labels through label policies to target audiences (user accounts). A label policy (Figure 2) consists of one or more specified labels and a target audience (user accounts). Publication must make labels available to users before they can apply the labels to documents and emails.
Two Broad Categories of Functionality
Sensitivity label functionality divides into two broad categories.
Protection: This was the original focus for sensitivity labels, where protection came from Azure Information Protection rights management. Essentially, users can only access protected content if the creator grants them the right to do so. The rights granted define the actions a user can take. For instance, they might be able to read a document but not print it. To help users understand that they’re dealing with confidential information, sensitivity labels can apply visual markers to documents and messages. For example, a label might insert text like “Confidential – Do Not Release Outside the Company” in a footer in Office documents.
Sensitivity labels also support the use of color as a visual indicator for the relative importance of labeled content. Labels applied to the most confidential material might be red, while those applied to less sensitive information might be yellow, green, or whatever other color hex code you think appropriate.
Either Microsoft (the default) or the tenant (BYOK or bring your own key) manages the encryption keys used for protection. Double-key encryption (DKE) is also available where both Microsoft and the tenant have separate keys, both of which must be available before a user can access the content. Finally, Outlook supports sensitivity labels that use S/MIME to encrypt and apply digital signatures to email. BYOK, DKE, and S/MIME show how Microsoft has expanded sensitivity labels to accommodate different forms of protection used by customers. However, the most common form of protection continues to be where Microsoft manages the encryption keys in its Rights Management service.
Container Management: Originally, a container is a team, group, or site. Recently, Microsoft has added OWA meetings and Teams meetings to the set (the latter requires Teams Premium licenses). Container management is a way for an organization to apply policy through labels. For instance, an organization probably doesn’t want guest users to be members of teams where people review highly sensitive information. By applying a label to the team that has the Guest Access setting disabled, no one except an administrator can add an external user to the team’s membership. Another example is the setting to control the sharing capability for a SharePoint site. In our example, it’s unlikely that the organization wants people to share documents from the site owned by the team with external users. The same sensitivity label that stops guest user access can also limit the external sharing capability for the site to be “Only people in your organization” (Figure 3).
Cybersecurity Risk Management for Active Directory
Discover how to prevent and recover from AD attacks through these Cybersecurity Risk Management Solutions.Learn More!
Separate Sets of Sensitivity Labels
It’s possible to use sensitivity labels for both protection and container management. However, I prefer to create separate sets of labels to handle the two functions. I think this approach makes label management easier to understand. The scope of the labels shown in Figure 1 tells you the use of each label. “Site, UnifiedGroup” means that a label is for container management, while “File, Email” means that the label is for protection. “Meetings” is the latest scope used to protect meetings.
It’s important to emphasize that any implementation of sensitivity labels involves a considerable effort to plan and deploy labels. Even items that appear simple, like label naming, require care. Users will do the right thing to protect sensitive information if they are guided by good names, descriptions, and limited choices. By that, I mean that it’s hard for users to decide between three or four labels that might be very similar. A label naming scheme that is clear, precise, and easy to follow is always better than giving too many choices. Take the example shown in Figure 4. Eighteen labels is too many, and the names of some do not clearly indicate the intended usage.
The screenshot comes from my tenant, and I know the reason why so many labels are present. But think of the average user who’s asked to choose from the array of available labels and then reflect on how many errors might happen.
Sensitivity Label Clients
The biggest change for sensitivity labels over the past few years is native mode support for labels within applications. Native mode means that an application includes code built using the Microsoft Information Protection SDK to apply, read, and respect sensitivity labels. As noted above, originally, labeling depended on a separate client (the AIP client and later the unified labeling client). Now, the Microsoft 365 enterprise desktop apps (Word, Excel, and PowerPoint), their online equivalents, and the paid-for version of Adobe Acrobat can interact with sensitivity labels directly. Support extends to protecting PDFs generated by Office applications.
The unified labeling client is now in maintenance mode. However, it’s still needed to apply sensitivity labels to files stored outside Microsoft 365 or files belonging to applications that don’t support information protection. This article discusses how to use the client to apply sensitivity labels to the MP4 files generated for Teams meeting recordings.
SharePoint Online and Sensitivity Labels
Another area of major improvement over the last few years has been the support of sensitivity labels within SharePoint Online. Initially, although it was possible to store protected content in a document library, SharePoint Online couldn’t do anything with the encrypted file. SharePoint Online stores item metadata separately to the blobs used to hold documents in Azure SQL, so the metadata (like document names and authors) was always available. However, services like Microsoft Search couldn’t index the encrypted content, which meant that other Microsoft 365 services like Data Loss Prevention (DLP) policies couldn’t work.
The solution is for SharePoint Online to decrypt content before storing files and to encrypt files when users access the content. This makes it possible for other services to access and use protected content stored in both SharePoint Online and OneDrive for Business. The mechanism sounds simple, but a lot of engineering effort happened to make it possible.
Before an organization can use sensitivity labels with SharePoint Online in an integrated manner, it must opt-in to support sensitivity labels. This simple step tells SharePoint Online that it should decrypt protected content before storage.
Sensitivity Label Challenges
Microsoft has made great progress to improve and refine how sensitivity labels work across Microsoft 365. Some challenges still exist, including the lack of APIs to allow organizations to apply sensitivity labels to content (this is coming), but overall, the picture is very positive.
That is until you venture outside the boundaries of day-to-day work with Office/PDF files. Management of protected files can be difficult, especially for third-party applications. Take backup products for example. They request data from SharePoint and download protected files, which the backup product then copies to its repository. But recovery and access to the backup files by end users is less certain. Conceptually, the challenge is easier for the forthcoming Microsoft Syntex backup service because all data remains within Microsoft, but it’s still something to test.
The same question of how to deal with protected content exists for tenant-to-tenant migrations when millions of emails and documents might move from one tenant to another. User accounts created in the target tenant can open unprotected files, but it’s likely that rights assigned to protected files won’t include their email address and block access. Removing encryption from documents before the transfer can be done (the same process is used to recover protected documents left behind by ex-employees), but it’s painful and slow.
No doubt improvements will happen in these areas in the future. I can’t say when, so my anticipation is more in hope than with certitude.
That was a great read! Although I have a question, if you may;
I’ve managed to create labels and a policy to apply them, and they work like a charm on the office online apps,
but they don’t show up at all on the desktop version. This may be silly, but I can’t quite figure this one out.
Do you use a perpetual version of Office or the Microsoft 365 apps for enterprise? You need the click to run version: https://learn.microsoft.com/en-us/microsoft-365/compliance/sensitivity-labels-versions?view=o365-worldwide#sensitivity-label-capabilities-in-word-excel-and-powerpoint
Is it now possible to force external users to use true MFA when using Sensitivty labels on an email? When i’ve been experimenting with this before i could not find a scenario where i could encrypt/label an email to force the user to authenticate with true MFA (Authenticator, SMS etc) before opening the email. Only email OTP was possible, and that was only when the external user was using something other than Microsoft, for example gmail.
It’s sad that you cannot apply labels to one note content. Makes me wonder how much development is left for this app. You can apply flip but not sensitivity or one note and I haven’t found a third party app yet either.
It’s certainly curious that Microsoft has not yet plunged into labeling OneNote files, but the structure of a OneNote file might mitigate against the kind of protection they have. I don’t know. This is just idle speculation.
Great information, as always from you @tony 🙂