DLP – What is it and how does it work in the Microsoft Stack?

Hey Team, I hope everyone is going well – the lead up to Christmas has been pretty busy and doesn’t seem to be slowing down; it’s good to be alive!

This article will cover what DLP is more generally and how it works with M365 – this will be covered over an additional few articles and will walk through some of the other features and how these can be applied. As always, if you have anything else you want to be covered or have any questions about this article, please let me know.

So, what is Data Loss Prevention?

Data Loss Prevention (DLP) generally prevents the information from being shared with people who should not have access to it. This can be both due to accidental or malicious sharing of that data. For example, let’s take health records – many hospitals and healthcare providers store electronic health records on their patients. Still, we won’t want someone sharing that information with unauthorised users as its private information and not only betrays the trust of that patient, but that organisation could then be subject to fines depending on its regulatory compliance requirements. 

The majority of cyber security breaches lead to data exfiltration that malicious actors might be able to sell that information on; they could use it for a competitive advantage or, as has been happening recently, could exfiltrate that private information and then hold it to ransom, demanding that the organisation pay them not to make it public. A recent newsworthy event of this data exfiltration was as recent as a month ago, where the streaming platform Twitch was hit by a data breach in which the attacker claimed to have leaked 125GB of Twitch data.

So to implement this practice within our environment, we need to put protective controls around that data to ensure that it is safeguarded against those threats. Realistically there is no golden bullet for this, and the solution needs to follow a defence in depth principles – I recently covered Information Protection and Sensitivity labels, and those, combined with DLP, provide additional layers of security to stop this data from being exfiltrated and usable in an unauthorised users hands.

It should be a series of controls that can reach all of the different elements of your data estate, covering your applications, endpoints and both on-premise and cloud environments – it only takes a single area within an organisation that allows data to be shared without restrictions to cause a potential data breach.

How does DLP work in the Microsoft stack?

Data loss prevention is an integral control in the Microsoft stack; it allows you to identify, monitor, and automatically apply protection to sensitive items across the below:

• Microsoft 365 services like Teams, Exchange and SharePoint
• Office applications like Word and Excel
• Windows 10 endpoints
• Non-Microsoft cloud applications
• On-premise file shares and Sharepoint

In M365, you can implement DLP by defining and applying DLP policies – the system will look for the content that you define within your policy with more than a standard text scan, but the content will be analysed for things like primary data matches to keywords, evaluating regular expressions and using secondary data matches that are close to the preceding match – we will cover how that works in a future article.

What is a DLP policy?

DLP Policies can use both sensitive information types (think credit card data) and Sensitivity labels (if you need to know more about these, read my previous set of articles) to trigger a DLP action; these triggers are in addition to the ones listed above. Once the system identifies a match to a DLP policy, we can initiate a protective measure; for example, a user attempts to share a file with credit card data within it, the system identifies that data is located within the file and then refers to the DLP policy, where we can take a few different actions.

We can: 

• Show a pop-up tooltip that warns the user that they are trying to share sensitive information
• Block the sharing of that sensitive information, and if we allow it, show a tooltip to enable the user to override the policy as long as they justify it (and this is logged so that we can view this later)
• Block the sharing of the information outright, without allowing an override
• If the data is at rest, we can lock the file and move it to a secure quarantine location
• If it’s using DLP in Microsoft teams, we can prevent that data from being displayed. 

It should be noted that all of these activities are monitored and recorded in the M365 audit log, so we can go back and investigate any potential issues and track the action after the fact. 

The DLP lifecycle

Like all products, implementing DLP typically follows a pretty standard lifecycle – we plan, prepare, and then deploy. Each of these three sections can be broken down into a few subsections:

Plan for DLP 

We plan out what some of these DLP policies and the associate actions should do in this stage. Suppose the organisation and its users are new to the idea and practice of DLP. In that case, it will require some education to your users and the business as a whole and will likely require some changes to current business processes. Like with any implementation of a new capability, the company and its users need to come along for the journey so that the culture shift can be universally accepted and have a minimal negative impact – we all know that first impressions matter, and deploying a technology only to see it fail rarely gets a second chance!

We also need to keep in mind the technology impact of putting these protective controls in place – DLP monitors and protects data at rest and data in motion across your entire Microsoft estate, so we need to keep in mind the implication of putting these controls in place in production for those different locations, as well as the type of data we are looking to protect and the associated actions to be taken once a DLP policy match is actioned.

Prepare for DLP

Each location that DLP can protect does have its specific prerequisites; for example, configuring it to integrate into Exchange online is straightforward – we need to configure a policy to apply to that location. However, if we want our on-premise environments to be protected with DLP, we need to configure and deploy the Azure Information Protection (AIP) scanner to leverage those controls. We want to ensure that we create draft policies and test them before implementing hard blocking actions.

Deploy these policies into the Production environment

The last stage (and by no means the easiest!) is rolling these out into production; this will typically involve some change control process and some approvals from the business as a whole. We should know how these policies will work and affect the different areas from the last stage in the lifecycle, so we need to analyse and design the production policies based on that information. 

Even if you are confident that your policy won’t have any impact, you should first run it in test mode so that we can see the view impact of your policies whilst in production – it wouldn’t be the first time that people have discovered changes in the production environment that they weren’t aware of that have caused the business impact. While we are testing in this stage, we should be monitoring and tuning the policy accordingly – are we getting a lot of false positives, or are we hitting the correct data that we are concerned about? We need to ensure that the scope of our DLP policies covers the areas we are worried about and how these will tie into the security and compliance of your environment as a whole.

Finally, it’s time to enable these DLP policies in production; this is by no means the final time you will need to go through and tweak these policies. Over time, you will find that there may be additional areas that you want to increase the scope to. Are there other data types to add in that had not been considered previously or new actions that need to be applied to particular types of data. This will be an iterative process moving forward, so it’s best to keep monitoring these alerts and tuning as you go.

What’s next?

This article was to educate and advise people on what DLP was more generally. How it works within the Microsoft context, I spoke about the different areas in which Microsoft applies DLP and a typical deployment lifecycle. 

In the following article, I plan on covering how this can be typically deployed through the Microsoft Compliance centre – and will run through some typical use cases that I have seen and configured during my time in this area. 

Feedback is always welcome, so please feel free to reach out via a comment or to me directly. I also have recently created a YouTube channel covering Microsoft Compliance news and things that I am excited about coming up – it’s called Coast2Coast – MSFTAU, and it can be found here, so if you are interested, please give it a watch. 

As always, Peace.