How to Deploy DLP Policies?

Deploying measures to safeguard your company’s data at rest often involves at least two areas that work together: information protection to protect data at rest and data loss prevention (DLP) to protect data in motion.

This post is all about DLP and presents the array of options available for deploying your protection strategies in an iterative and layered manner.

What Is DLP?

Quite simply, and most importantly, data loss prevention is taking adequate precautions to automatically control the flow of data from a user to other people, based, typically, on the type of information being sent and the nature of the respective data recipients.

For example, wouldn’t your organization be at risk of disclosing regulatory data without authorization if an email containing personal data (as defined by the General Data Protection Regulation (GDPR)) was sent to recipients identified as using non-business messaging services?

The same is true for sharing files or protecting information within instant messaging conversations through Teams or Viva Engage.

Can We Block Emails?

This question arises quickly when you start general design or detailed design workshops.

This is a good question, especially if it comes from a security officer or information systems security officer (ISSO). However, there are a whole host of things behind this that should not be overlooked at the risk of alienating all of the business (or even cross-functional) departments in the organization, and the configuration efforts would then be for nothing because of (real or imagined) reasons that would interrupt work or the business.

So What Then? You Shouldn’t Block?

Blocking an email is not the most important part of DLP, although (spoiler alert) this will still be one of the strategies to consider ultimately.

Is it common for an email, shared file, or conversation to be blocked these days? No, it doesn’t happen very often, if ever.

So, will users understand and accept if we unilaterally, or even empirically, block these same shares and content tomorrow?

Power Up to Ensure the Run’s Success

A successful DLP policy in a production environment is:

• Effective
• Legitimate and appropriate
• Understood and accepted

What makes the DLP policy effective is ensuring that the intercepted content is the targeted content with the highest level of accuracy and probability. In other words, there should be as few false positives as possible that trigger an incorrect DLP alert.

The DLP policy will be seen as more legitimate if the protection measures fit the type of business and the targeted user’s level of responsibility. For instance, a user who works in human resources (HR) will, at least theoretically, have more reason to handle personal data than someone who works in more “technical” areas.

Not only will the first two points help get people on board with the strategy, but so will communicating with employees before and after deployment and “in real time.”

To optimize the achievement of these three objectives, it is best to plan for at least four stages of deployment, each incorporating an additional protection strategy compared to the one before.

As you might expect, these four stages use Microsoft Purview DLP features and options. These can be summed up as follows:

• Monitor to validate
• Monitor and inform
• Block and allow override
• Block with no override

The first two stages will have no impact on users’ day-to-day actions. The subsequent two stages, however, will fully interact with users’ actions.

Stage 1: Monitor to Validate

This step occurs silently for the users. It involves enabling DLP policies that log information-sharing events that (in theory) should not happen for administrators and security officers.

Everything happens transparently for the end users, and nothing changes in terms of the user experience.

Is this stage really completely silent? No.

Talking to the regulatory bodies (employee representation committee, trade union, data privacy officer (DPO)) early on about the plans is highly recommended to inform and warn them about the intended strategies.

This communication should cover what data types will be monitored, how, for whom, and for how long, etc.

You will need to make the following changes to settings for the DLP rule(s) that make up your DLP policy on the Purview side:

• Do not configure any protection actions
• Disable user email notifications and policy tips
• Disable the creation of a DLP alert if the DLP rule is triggered

After enabling the DLP policy and deploying it to the targeted users, you will be able to:

• Keep track of how many times your DLP policy is triggered in the Activity Explorer dashboard.
• Evaluate how well the chosen data model works as the DLP rule trigger condition. There is no magic formula for this. Rather, verification steps must be taken (by sampling, at least) on the events that triggered the DLP rule. Moreover, depending on the business type of the data in question, this should not be performed by just anyone.

Stage 2: Monitor and Inform

Stage 1 should have enabled you to adjust the data model used and better understand (or not) the main business situations in which your DLP policy is triggered.

By making these configuration improvements in stage 2, you can make the screen display a message when the user triggers the event targeted by the DLP rule. For example, the data model has been recognized in the email (subject, body, attachment) and possibly another condition.

The purpose of this message is to inform the user that their action is not authorized (because of your company policy, rules, etc.) but is still tolerated at this stage.

The benefits of this stage are to:

• Get people used to the fact that their information-sharing activities are being monitored and may be blocked in the future because they are prohibited;
• Start monitoring the reasons why users decide to send an email with sensitive content. Identify the senders and the recipient types (internal, known, or less known external domains).

You will need to make the following change to the settings for the DLP rule(s) that make up your DLP policy on the Purview side:

• Enable policy tips and/or user email notifications

Stage 3: Block But Allow Override With a Justification

Stage 3 is only implemented after a sufficient amount of time has passed since implementing stage 2. This time will vary depending on the target audience’s size (from two weeks to several months).

The DLP policy will block the targeted action, inform the user, and, most importantly, give them a choice that makes them accountable.

• Do they think that the DLP rule and the subsequent blocking are valid? If so, will they follow the advice in the message that accompanied the blocking?

Or,

• Do they believe they are authorized to share the information with entitled parties? In this case, they will ask the system to override the DLP rule by entering a “business justification.”

By declaring the event a false positive, they can also indicate that the content in question is not what the DLP rule thinks it is. This declaration will also be recorded.

The stage 3 evaluation will enable:

• In theory, a reduction in the number of DLP alerts triggered if the number of users stays the same and the stage lasts a similar length to the previous one;
• By reviewing the business justifications provided by the users requesting an override of the DLP rule, you should be able to identify the scenarios better when blocking sharing is not justified, or at least to what extent.

You will need to make the following changes to the settings for the DLP rules that make up your DLP policy on the Purview side:

• Add an action to block the sharing action;
• Enable the mechanism allowing users to request a DLP rule override for a business reason;
• Enable the mechanism allowing users to request a DLP rule override due to a false positive.

Stage 4:  Block With No Override

Now, we come to the (inviolable) stage of blocking the user.

When the organization initiates this stage, it means:

• the change management strategy has been fully implemented,
• the results of this change management have been measured and taken into account,
• the DLP policy’s effectiveness has been given a score that is deemed satisfactory,
• the legitimate groups that need to be blocked have been identified.

There is one exception, though: in theory, a certain regulatory framework could justify enabling this blocking measure without activating one or two of the intermediate stages (stage 2 or 3).

You will need to make the following changes to the settings for the DLP rule(s) that make up your DLP policy on the Purview side:

• Disable the mechanism allowing users to request a DLP rule override for a business reason;
• Disable the mechanism allowing users to request a DLP rule override due to a false positive (unless the organization wishes to keep this override, at the risk of it being misused by users).

Is the Goal of a DLP policy Really to Block Data Sharing?

Enabling blocking in stages 3 or 4 is just one example of protecting content that is meant to be shared.

Other actions can be taken instead of blocking content that are just as legitimate (depending on what is required under current regulations).

For example, for an email-specific DLP policy, other ways to prevent leaks are possible, such as:

• Encrypting the email to restrict further distribution
• Requesting approval from the sender’s manager
• Notifying a legitimate authority to intervene in such situations, etc.

The BUILD is Done. Now what?

Now, time for the Run! No matter what level of protection is deployed, once the DLP policies go live, a system (a team, process, and roles) must be in place to monitor the DLP events.

This is another topic, but here’s a quick summary:

• Objectives: Reporting, passive monitoring, advanced investigation
• Resources: Audit log, Activity Explorer, Purview alerts, Defender alerts and incidents, Sentinel alerts and incidents, etc.
• Continuous improvement of data models: identify false positives, define changes to make to the model, and approve and incorporate any adjustments

Learning and Mastering How Microsoft Purview Works: the Associated Training and Certifications

As stated at the beginning of this post, data loss prevention is just one way that Microsoft Purview can protect your data and ensure the compliance of its use.

It is strongly recommended that you take one or more exams to consolidate your Microsoft Purview knowledge before starting a configuration project on a live tenant.

Here are the exams and associated certifications that cover Purview configuration:

• Specialized certifications in the area of Security:
  • SC-900: Microsoft Certified: Security, Compliance, and Identity Fundamentals
  • SC-400: Microsoft Certified: Information Protection and Compliance Administrator Associate
• Cross-functional certifications:
  • MS-102: Microsoft 365 Certified: Administrator Expert

Key Takeaways

A successful deployment plan for your DLP policies must consider both the readiness of your organization to incorporate these changes into the way it operates and the risk of having your business activities wrongly interrupted.

A phased deployment will drastically reduce the number of false DLP alerts that a Run team (security operations center (SOC) or similar) will need to monitor in addition to all the other alerts from the various deployed security solutions.

Finally, Microsoft Purview and the data loss prevention solution have a lot of features. However, you should limit yourself to the ones that fit your needs, regulatory obligations, and/or your information systems security policy (ISSP).

You can always refine your DLP rules later to account for new security rules and deal with exceptions better.

Would you like to learn more or get some expert help? Contact us!