Retention and Labels and Classifications, Oh My!!

So I’ve been working on a number of Proof-of-Concept (PoC) deployments for several of our customers, and I’ve run into a couple of interesting things I’d like to talk about.

The first things to talk about is some of the confusing Terminology that Microsoft is using in Office 365; and this was highlighted in conversation with my colleagues at a recent meeting. The main culprits are Retention Policies, and Labels & Classifications in the Security and Compliance Center.

For those of us who come from the Exchange world, Retention Policies are a collection of Retention Tags that can be applied to items within your Exchange Mailbox to control how and when these items are deleted/archived. In the  Security and Compliance Center, a Retention Policy dictates how long data is preserved (regardless of whether it’s SharePoint, Exchange, OneDrive or Skype for Business) and what happens to the data at the end of that period.

If you’ve been reading closely, you will have now realised that the new Retention Policy is actually what Microsoft were previously calling Preservation Policies so you can see why the confusion can occur.

The second thing is the Labels and Classifications functionality. Since some of the PoC deployments have involved Enterprise Mobility and Security (EM&S), I’ve been working with Azure Information Protection (AIP) which has, you guessed it, labels and classifications. Although they use the same terminology (which can cause confusion), they operate in different ways with different technologies.

Looking at the Labels and Classifications functionality in the  Security and Compliance Center, you can see that they are designed to preserve data in different locations, with different time-spans based on the label definition. In a sense, this is driven by the Preservation Policy functionality (sorry, Retention Policy!) but is more granular as different items and locations can have radically different labels. For what it’s worth, I think that these may be a better mechanism for data preservation and compliance, given that the Retention Policies are limited to 1000 mailboxes.

Labels and Classifications in AIP are building upon Microsoft’s Azure Rights Management Services (RMS). Data such as documents, spreadsheets and emails can be classified as they are generated and these classifications are embedded into the items. On top of this, the labels can provide RMS protection which encrypt the items with specific actions. Since these classifications are embedded into emails as headers, or office documents as metadata; they can be evaluated by any Data Loss Prevention (DLP)solution.

To illustrate how this works, I’m going to show you something that I used in a recent engagement.

The customer was having an EM&S PoC and wanted to use AIP to protect and classify documents, and prevent their distribution based on said classification. So I configured a standard set of labels for different levels of sensitivity, and sublabels that differentiate between Internal and External data within each level. Each label (and sublabel) has a label ID which looks something like this: 67d01370-cdc4-4324-ac98-74e0bba11db8

When we apply a label to emails, the AIP library add a header called “msipl_labels” and it will populate it with eight settings=value pairs. These include:

  • “MSIPL_Label_<LabelID>_Enabled=True”
  • “MSIPL_Label_<LabelID>_SetBy=<userid>”
  • “MSIPL_Label_<LabelID>_SetDate=<datetimestamp>”
  • “MSIPL_Label_<LabelID>_Application=Azure Information Protection”.

If there is a sublabel selected, the header will contain the setting=value pairs for that LabelID as well. To round it all off, there is a Sensitivity=<textstring> pair that is added.

Applying a label to Office documents works in a similar manner. The settings are added as custom properties and the values populated as per the information above.

I created a pair of Transport Rules on the customer’s Exchange Online tenant that were designed to monitor for any data classified “Internal” and to block it from leaving the Organisation.

  • If email header “msipl_labels” contains “MSIPL_Label_<LabelID>_Enabled=True”
    Then
    Block email with the following message “Attempting to send Internal emails externally”
  • If email attachments has the custom property “MSIPL_Label_<LabelID>_Enabled:True”
    Then
    Block email with the following message “Attempting to send Internal documents externally”

These rules were created as the highest priority and now this customer can protect all and any data from leaving their control.

Post to Twitter

Leave a Comment

Your email address will not be published. Required fields are marked *