Information Protection – Applying Sensitivity Labels in M365

In my last article, we defined what Sensitivity labels and Sensitive Information Types were, how they relate to each other, how they are created, and the elements that each sensitive information type consists of. We also ran through Trainable classifiers, where we can use machine learning to train a model to recognise a particular data type, and we can then use that trained model to automatically label data using Sensitivity Labels.

This time, I wanted to start looking into applying what we have covered in an environment – specifically how to both create and apply these sensitivity labels, covering both manual and automatic methods.

A recap – Sensitivity Labels in M365

To briefly recap – sensitivity labels are the tool that we utilise to apply our Data Classification to our data. This would have been built out as part of our data classification framework that I have written about in previous articles and should cover all of the data that we found in our previous phase, ‘Know your Data’. With the implementation of Sensitivity labels, we will start to apply protective controls to our data and move into the ‘Protect your Data’ phase. 

For this example, let’s use the same Data Classification Framework that I have used in previous articles. We will focus on creating and applying a Sensitivity Label of ‘Sensitive,’ concentrating on Credit Card data. These files will need to be encrypted to a few different users, and they will need a watermark applied in the header of the file.

Business Acceptance and End User education

A critical element that needs to be completed before creating these sensitivity labels is the acceptance of the Data Classification Framework and associated controls by the organisation itself. Typically this would require Board or Executive approval as implementing these controls can affect business processes if not worked out beforehand.

Another critical element to consider is the education of end-users. Sensitivity Labels are relatively easy to use and understand. Still, there needs to be a process put in place so that users are aware of what Sensitivity labels are, how they can be applied, what data is considered sensitive, and the business rules that govern that data. For example, if the end-user needs to downgrade a label because a file has been mislabelled – what is the process around that? 

These activities need to be mapped out and users educated to make the correct decisions when they run into such events.

Creating a Sensitivity Label in M365

Alright – it’s time to create and implement some sensitivity labels! 

The portal that all of the configurations take place in is the Microsoft 365 Compliance Centre. To create Sensitivity labels, you will require some Information Protection privileged access in the Compliance Centre; you can typically grant permissions against the Information Protection grouping of roles.

Some additional information on these roles and how they work in the Compliance Centre can be found below:

Within the Compliance Portal, we want to browse down to the Information Protection section; this will bring up all the sensitivity labels within the environment. It will show the label order in terms of sensitivity, the scope that these labels are applied, and when the labels have been last modified.

Once we select “Create a Label,” it will bring us across to a “Name and create a tooltip for your label” screen. Within each of these different sections, you will want to be as descriptive as possible. This will help both your end-users and administrators to understand what the label is to be used for and will save a lot of time educating staff going forward.

We then need to set the scope of this sensitivity label – this determines where the label can be applied and covers three areas, we also enforce controls based on where the label is applied:

• Files and Emails – This covers the various file types and emails that we can apply labels to – think the content in Office, OneDrive files, and Azure, to name a few.
• Groups and Sites – These controls apply to labelled Teams, Microsoft 365 groups, and SharePoint sites.
• Azure Purview Assets – These will apply to assets within Azure Purview – think things like SQL columns, files in blob storage, etc. (This will also be covered more in a future article).

Protective Controls

Once the scope has been determined, we need to start to configure controls. In our example use case, we need to have files and emails encrypted and the word ‘Sensitive’ displayed across the top – let’s walk through how to apply these two controls.

Encryption

First, let’s configure the encryption of these files. We have a few options – do we want to specify who has access to these files once they are labelled now, or do we want to determine who should have access each time the label is applied? Of course, this will depend on your specific use case, but in this case, we will identify those users for this policy. For example, suppose this would be a label for something such as a tender that requires different people to access the file depending on what they were going to tender for. In that case, we could use the other option.

In this example, let’s give all authenticated users and groups in our organisation read-only access. So we will assign them with “Viewer Rights” as below:

As you can see, we can be pretty granular with permissions – we can restrict users from editing, saving, or even printing a document based on what permissions we grant them. We can also add multiple groups and provide them with different permissions – in the below example, we have given the SOC Team Co-Author rights to this same sensitivity label while still allowing the rest of the business to view the file.

In this encryption section we also can restrict access to content after a particular period of time, and to either allow or deny offline access.

Content Marking

The second control we will configure for this label will be to include a Content Marking – this will be where we configure the file to have the word “Sensitive” added into the header of the email or document.

This is fairly straight forward – simply select the type of content marking you would like to apply – watermark, header, footer or a combination of all three – then type in the text you want displayed, the font size, colour and the alignment of the text as below;

Publishing a Label

Now that we have our label created, we need to publish the label so that the users that need access to that label have it in their client (both the native client build into office and the unified labelling client require this).

The first step that we need to do is select the labels that we want to publish – this can be multiple labels, or one at a time depending on how you will be splitting up your user groups. in this example we want the following labels published to all users in the organisation:

Once this has been configured, we have four options that we can configure for the labels included in the policy – typically, organisations will enforce that users will be required to provide a justification to lower a files classification, but the four options and the descriptions can be found below:

Now that we have configured and published our labels, they will be made available for end-users to manually apply these labels in their respective client. This typically will be included in the ribbon of the application that they will have the option to select one of the labels that had been published.

Automatic Labelling

Now that we have covered the manual method of applying a label via the respective client – let’s finish off my covering automatic labelling. Automatic labelling of sensitive information in M365 can use a few different methods of locating and labelling data and will be depending on the locations that you want to apply the label to; for example, we can use Sensitive Information Types or Trainable Classifiers that the system will look for – and if found then the corresponding label will automatically be applied to the file. 

In the above example, we have configured the label to search for both Credit Card numbers and any resumes within the system – if that data is found within a file then we have an additional couple of options. We can automatically apply the label to the file right away, or we can recommend that the users apply the label – putting the responsibility on the users to enforce these protections.

We then have the ability to display a message once a label is automatically applied; this is another field where we should be as descriptive as possible – it helps users understand why a label has been applied and potentially what kind of data was found.

What’s next?

So in this article, we have covered how to apply and enforce sensitivity labels and their respective controls within M365. These can be extended out to Microsoft Teams, as well as SharePoint sites – we can also use Azure Purview to extend these out across multiple cloud platforms, including Azure.

In the next few articles, I will start to work through the next pillar in our Information Governance Lifecycle “Prevent Data Loss” with Data Loss Prevention (DLP) and how it can be applied in an M365 environment – this capability is also empowered with the integration with Information Protection and Sensitivity labels, so it should be a natural progression through the lifecycle.

As always, feedback is welcome – and if there are any additional topics you want to see covered, please feel free to leave a comment or to message me directly.

As always – Peace.