Using Sensitivity Labels in Office 365 DLP

Christopher Brumm
7 min readNov 22, 2020

--

In the last months we have seen

  • the integration of individual Information Protection and Data Loss Prevention features
  • the improvement of existing Information Protection features
  • the release of new Information Protection features

and it slowly forms a clearer and clearer overall picture with which it is possible to design and implement a holistic approach for Data Loss Prevention. In this blog post there is a good overview of the current situation and the numerous announcements:

In my opinion, one of the most useful innovations is the integration of Sensitivity Labels and Office 365 Data Loss Prevention, which is currently in Preview, since it is now possible to access not only automatic detection by the Sensitive Information Types but also labels already issued by users or automatisms.

In this blog I will try to explain why I consider this feature important, how I use / configure it and how it currently “feels” to the user.

First goals of an information protection strategy

In my projects I usually pursue these 3 goals first, in which different measures are then integrated:

  • Enable labeling of documents and mails
    This means we want to provide a good user experience while applying, changing or detecting sensitivity labels and aim for a high degree of automation.
  • Enable technical measures to prevent the sharing of sensitive data
    This means that we want to support policies that prohibit the sharing of sensitive data with technical measures. Again, things like good user interaction and predictable behavior are very important.
  • Establish secure ways to share data
    This means we don’t just want to impose bans, but to establish ways for users to securely share data with partners and customers.

The use of Sensitivity Labels in Office 365 DLP pays here strongly on the goal to Enable technical measures to prevent the sharing of sensitive data.

You might ask yourself:

“Why don’t we just block sharing?”

Because of email and the loose of a lot of feature.

“Why don’t we just encrypt with every label?”

The answer is the (still) existing restrictions including No AutoSave and Editing an encrypted file at the same time only in Office Online

Use Cases for Sensitivity Labels in Office 365 DLP

Here are some obvious Use Cases but due to the flexible configuration options the possibilities are immense. All use cases based on this feature have the following start and vary only in scoping and policy logic.

  • Create a new DLP policy, give it a name and choose your locations —depending on your Use Case. If you want to scope this feature for a PoC my advice is to do the scoping at the assignment of the Sensitivity Labels because this is especially at SharePoint and OneDrive a little inconvenient at this place.
  • Choose an advanced DLP rule, create a new rule and give it a name, and now comes the new feature: we can select the condition Content contains -> Sensitivity Labels

Block sharing (with override)

This obvious use case is probably the most powerful one. It is about effectively preventing the sharing of files from OneDrive and SharePoint for certain categories of documents.

Many companies are still hesitating to activate external sharing because they fear that this would lead to a loss of control. This (very good) blog shows very convincingly that this is not true:

Nevertheless, the question of technical measures to prevent intentional or unintentional misbehaviour by users still arises, and this is where the use of sensitivity labels in DLP brings enormous added value. The user is prevented from sharing the data when trying to do so with a meaningful reason.

Our rule now consists of the following components:

The Condition: The combination of label and external sharing.

The Action: Block the access of all people from outside the organization.

The User Notification: a customized policy tip

Since the policy tip unfortunately cannot use variables, either a generic text must be used or a separate rule must be created for each blocked label in the policy.

For the user the behavior when trying to share a file with the label is then the following:

A variant of this policy can also allow the user to override.

Whether this option is used depends on the document class defined in the corporate policy.

I like to use this option e.g. to map the increasing sensitivity by the different behavior. Example:

  • secret -> with overrides
  • top secret -> without overrides

Force labeling of documents to allow sharing

This Use Case is a restrictive variant of the Block Sharing Use Case which allows you to restrict sharing to documents marked with a (released) label and the necessary policy can be combined very well with labels with encryption.

Although the Use Case sounds very tempting, it can unfortunately only be configured in a roundabout way at the moment and causes slight irritations in the user experience.

The core problem with the configuration of this use case is that the External Shared condition must always be linked to another condition.

As a workaround it is now obvious to create a Sensitive Information Type that applies to all files.

A “match all” sensitive info type can be created quite easily with a regex (see https://regex101.com/) For my purpose here [\S\s] is good.

The side effect of this hack is, that e.g. OneDrive now shows for all files that there might be restrictions, but it works!

Keep internal mails internal

Here it is a matter of supporting the often already established classification of e-mails with a comprehensible technical measure. Of course, nobody would classify an e-mail that they want to send to an external recipient as internal, but there are very useful scenarios.

Imagine that colleague A wants to send an e-mail to colleague B and make sure that this e-mail does not leave the company. He would probably classify the mail with a label like “Internal”. If colleague B tries to forward the mail to an external recipient, DLP intervenes.

The needed policy is very similar to the Block Sharing policy but the user experience is different. It is scoped to Exchange and the rule consists of the following components:

The Condition: The combination of label and external sharing.

The Action: Block the access of all people from outside the organization.

This Use Case unfortunately still has the following limitations:

  • Bounce Mail instead of Policy Tips
  • Labels on attachments are not recognized

Design of a (technical) DLP strategy based on the different use cases

In practice, these different use cases can be combined into a strategy, which can then be used to implement graded measures. If we assume 4 basic labels (public, internal, sensitive, secret), it can look like this:

  • no technical restrictions for public
  • block (external) sharing with override for internal
  • block (external) sharing for sensitive and secret
  • block (external) emails for internal, sensitive and secret

If you add AIP Labels with Encryption for sharing in sensitive to allow sharing for this category as well, you get the following picture:

By the way, this can be configured very well with a single policy and multiple rules, because the deviations like the override action and the policy tips can be done completely in the individual rules:

Theoretically this policy could be extended for the Email Use Cases, but I think it makes sense to create another one here to increase the flexibility for further requirements.

--

--

Christopher Brumm
Christopher Brumm

Written by Christopher Brumm

ITSec Pro focussed on MS Cloud Stuff

Responses (1)