How to Structure DLP Strategy Governance?

In our last post about data loss prevention, we showed you how to change your data loss prevention (DLP) strategies based on your needs and the challenges involved in change management. Ultimately, this means based on how mature your organization is in controlling data flows, whether these arise through email or document sharing (among other methods). The goal was to ensure that these DLP strategies were implemented with the highest level of adoption by business teams and end users.

We are going one step further with DLP best practices in this new post. This time, we will be facilitating technical governance of these strategies and effectively simplifying the activities of the O365 admin and security teams.

In other words, the three main goals of good governance of DLP strategies and rules are:

• Identify an existing DLP strategy as soon as possible so it can be changed or, at the very least, audited
• Allow filtering or triage of DLP alerts across the security operations center (SOC) team and quickly determine the nature and severity of a DLP incident
• Ensure the expansion and “scalability” of your DLP policy repository

Microsoft Purview – What Are the Prerequisites?

The recommendations shared in this post can be used with an Office 365 E3 license and up.

DNA of a DLP Strategy

To fully understand how structuring DLP strategies and rules improves their governance, which in turn helps reach these three objectives, let’s go over how a DLP strategy is built within Microsoft Purview.

There are two “groups of characteristics” that make up a DLP strategy:

• General characteristics across the DLP strategy:
  • A name
  • A description (for the DLP administrators)
  • A range of applications, or “location” (EXO, SPO, OD, Teams, Devices, PowerBI, File Share, third-party SaaS applications, etc.)
  • An audience for each selected perimeter
  • A deployment method

• A set of one or more DLP rules that each describe:
  • A name
  • A description
  • A set of conditions that trigger the rule
  • A set of exceptions to the previous conditions
  • A set of control actions if the rule is triggered
  • Parameters for interacting with end users
  • Parameters for managing alerts triggered based on conditions and exceptions, including the severity level (Low, Medium, High)

To fully demonstrate how DLP strategies work technically within Microsoft Purview, it’s important to be aware of the following limitations:

• As previously stated, the general characteristics of a DLP strategy apply to all of the DLP rules that comprise it;
• Once generated, the name of a DLP strategy cannot be changed. This name must be unique for all DLP strategies on the tenant;
• In addition, once the strategy has been created, the name of a DLP alert cannot be changed either. This name must also be unique for each rule that makes up the tenant’s DLP strategies.

Lastly, if you want to maximize Microsoft Purview’s DLP rule configuration capabilities, we strongly recommend ensuring that each DLP strategy only applies to one “location” type. This is because some “locations” do not let you set the same conditions, have the same exclusions, or take different control actions when making a DLP rule. When you set up a DLP strategy for two different location types, like Exchange Online and Teams, you can only configure DLP rules that work with those locations. This means you can only use conditions, exclusions, and actions that work with the selection location types.

As a result, as the number of protection use cases grows, you’ll need to devise more and more DLP strategies.

But how do you keep track of all those different strategies when they are live?

The good news is that there are two ways to avoid getting caught up in a patchwork of DLP strategies. Better yet, they work well together!

• #1: Choose the logic you want to use to structure (distribute) your use cases across your DLP strategies
• #2: Devise a naming convention for your DLP strategies and rules based on this logic

Option #1: Structuring Your DLP Strategies and Rules

In general, I recommend structuring your DLP rules and strategies based on one or two of the following main criteria:

• Location type
• Data type the DLP strategy is aimed at
• Protection method (Monitoring, Block with override, Block, etc.)
• The target audience in mind (if specific)
• The business process affected (where applicable)

I prefer to focus on the first two at a minimum, as they are the least likely to change over time for a given use case.

Typically, rules at the DLP rule level of a strategy should be organized by severity (Low/Medium/High) at a minimum.

Each DLP rule within a single DLP strategy will logically have the same types of conditions and exclusions, with some differences in trigger thresholds. However, each rule will have different protection actions and user interactions and create different communication and alert strategies as a result.

You will then have your strategy and rule structuring convention. You will then have to follow this strictly for all your strategies and rules to make sure they are all consistent and managed in optimally.

Option #2: Naming Convention for Your DLP Strategies and Rules

With this structure in place, you will need to define a naming convention that reflects it for the strategies and associated rules.

As an example, here are two possible ways of structuring your DLP strategies and rules, along with the resulting naming convention and the pros and cons of each:

DLP Strategy Governance: Key Takeaways

“Divide and conquer” or “combine and simplify”?

Ultimately, both of these structuring approaches have pros and cons (or rather, challenges).

Generally, the more specific regulations or standards an organization has to follow, and the bigger it is, the better it is to structure its strategies and associated rules.

Switching from one structuring strategy to another is always possible on a technical level. However, the longer it takes to make the change, the more likely the technical operations involved will be time-consuming. Since policy names can’t be changed, you’ll need to create new DLP strategies and plan a go-live switchover so that there is as little “dead time” as possible between deactivating the initial strategies and deploying the new ones correctly to your users.

Find Out More about Building Your DLP Strategies

If Microsoft Purview’s Insider Risk Management features are eventually deployed within your tenant, you’ll be able to use Adaptive Protection for your DLP strategies, which gives you new, more flexible ways to protect your data.

With these new options, you’ll have more freedom to identify in “real time” which protection measures your DLP rule should use based on the user performing the sharing operation (or emailing, copying, etc.). However, depending on how your strategies are currently structured, especially your naming convention rule, you may need to create new DLP strategies and rules.

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

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

Would you like help improving your skills and preparing for your certifications? Discover the training courses offered by Cellenza Training:

• SC-400 training: Microsoft Information Protection Administrator
• SC-900 training: Microsoft Security & Compliance
• MS-102 training: Office 365 Administrator