Microsoft Ignite 2020 has started! It’s going to be a week full of exciting and new announcements on Azure, Microsoft Teams, Power Platform, Microsoft 365 and of-course security and compliance. During the next couple of week I will be delving into (preview) functions for information protection. Some of these functions have been in (private) preview for some time and can now reach a greater audience.

When looking back at the (relatively) short history of Azure Information Protection and Microsoft Information Protection, we can discern some trends. First of all, information protection has always centered on detecting, classifying and protecting sensitive information as stored in documents. Regardless of the location where the document was stored, it could be classified and protected.

Office 365 Message Encryption added an additional layer of communication protection and secure messaging. And when used in conjunction with Microsoft Cloud App Security, even some non-Microsoft cloud-services could be connected as-well.

As Office 365 and Microsoft 365 came more and more into play, the use of information protection become more important. Most enterprises use SharePoint Online, OneDrive for Business an Office Online to manage and work with documents. But Azure Information Protection and Office 365 didn’t like each other much. So Unified Labeling (sensitivity labels), the Office Online integration and auto-classification for data was released.

But technology evolves and it needs to. Although it’s great that Microsoft enhances functionality and releases more and more features, sometimes this leaves some caveats. For example: sensitivity labels settings for Groups and Sites. These are great and really allow us to move from document-level to container level. One snag though….. A label setup which includes these settings, also shows up as a document-label, when published. This might be the use-case, but sometimes you might want to be able to differentiate.

So, having said this – all I’m saying that some improvements need some time. And now during Ignite we will be able to look at these. In this blog I will focus on:

  • Endpoint data loss prevention
  • Using sensitivity labels for data loss prevention in Microsoft 365
  • Container/document separation of sensitivity labels
  • Classification depth
  • Double Key Encryption
  • Multicharacter support

Now I will look at these in more detail and show them with some video’s. But for now, just some updates.

Endpoint data loss prevention

In one of my earlier blogs I wrote about how Windows Information Protection (Intune MAM for Windows 10) was able to work with sensitivity labels from Microsoft 365. It allowed for control over sensitive information when this was used on a Windows 10 device.

Microsoft is now working on bringing this type of data loss prevention into Microsoft 365. Called “endpoint DLP” an administrator now can enforce policies on the Windows 10 device. These policies are part of the data loss prevention part of the compliance dashboard. Activities include:

  • Copying a sensitive file to an external USB media device
  • Copying a sensitive file to a network share
  • Uploading a sensitive file to a cloud service
  • Printing a sensitive file
  • Copying sensitive content to the clipboard
  • Accessing a sensitive file by an unallowed app

Another nice addition is the native integration with Microsoft Edge. Unauthorised actions using this browser (for example trying to upload a document to DropBox) are blocked. And you might also note the Cloud App Security option. From a technology perspective, this is not new. But it’s great to have one dashboard for admin to set DLP policies, even to other cloud apps!

More on this function:

Using sensitivity labels for data loss prevention in Microsoft 365

When working with the DLP engine in Microsoft 365, you might have noticed that the policy settings DLP rules only allows for sensitive information types or retention labels to be used. This off-course depends on the function. Exchange allows more conditions based on the message, for example.

If you wanted to use the sensitivity labels for this, you needed Microsoft Cloud App Security – but this is only included in the more extensive licensing models. Now Microsoft is allowing the use of the sensitivity labels with your DLP policies. Which makes perfect sense to me.

Container/document separation of sensitivity labels

This one I mentioned earlier in the blog. The current sensitivity labels allow you to scope these to sites and groups. When you create a SharePoint Online site-collection or Microsoft Team (or edit the details later) you can select the label.

At this moment, you can control the privacy of the site/team, external access and the use of unmanaged devices for this site/team. Which is great functionality.

However, such a label also shows up when working with documents and e-mails. So Microsoft is going to enhance this capability. In the short-term you can select if you want a label to be used for documents and e-mails or containers (sitesteams) or both. The later is the default configuration.

In addition, the protection settings are differentiated between groups (teams) and SharePoint sites. The sharing settings of the latter are now included (you know: everyone -> only people in the organisation). This makes for a very cool and new addition.

If you want to be part of the preview, you can nominate your tenant here.

Classification depth

If you’re used to work with data loss prevention or automatic classification of content, you are aware of the confidence system. This is one of the components used by Microsoft 365 to determine if content confirms to the sensitive information type. At this moment, this is based on numbers.

This is going to change. As this is a tricky and complex subjectmatter, so I’m going to quote Microsoft on this.

“We are upgrading confidence levels by replacing number-based confidence system with three discrete confidence levels – high confidence, medium confidence & low confidence. Confidence levels (high, medium, low) reflect how much supporting evidence was detected along with the primary element. The more supporting evidence an item contains, the higher the confidence that a matched item contains the sensitive info you’re looking for. For example, matches with a high confidence level will contain more supporting evidence in proximity of the primary element and would lead to lower false positives but higher false negatives. Whereas matches with a low confidence level would contain little to no supporting evidence in proximity and thus would lead to zero to low false negatives but higher false positives.”

More information here:

And this article also describes some of the other enhancements. Which are great: 98 new sensitive information types for example. Or the ability to copy/paste and edit the out of the box sensitive information types. Very, very impressive stuff.

Double Key Encryption

At this moment, the encryption used by Microsoft Information Protection allows you two choices. Either you use the Microsoft generated key or you provide your own key. There was no middle-ground. But this is coming and is now in preview. It’s called Double Key Encryption or DKE and this allows you to encrypt information using a Microsoft key and your own key.

This allows you to have more control on the encryption of your information. For example, when you have very specific requirements to be in control of your information and data at all times.

This feature is now in preview. If you need more information, please see these posts:

Multicharacter support

This is a big announcement for enterprises which use the Chinese (simplified or traditional), Korean and Japanese language. This preview allows for the supports of the so-called double byte character set. It enables the use of this set in sensitive information types and keyword dictionaries.

Leave a Reply

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