Data Loss Prevention (DLP): From Theory to Practice

One of the most challenging aspects of rolling out DLP rules is the friction involved, as with many other data protection tools. The work around DLP should therefore be viewed as an iterative process in which feedback is gathered from stakeholders across the organization: Is the action reasonable for the information? Is it relevant? Is it feasible in relation to existing workflows? Yet driving an implementation based only on theory is not always a winning approach.

Start With a Hypothesis

Many organizations already have assumptions about potential risks. This is particularly true for supporting functions such as IT and Security. People in these areas often have specialist expertise and insight into the organization’s systems and how they are used within their respective domains. General potential risks include:

• Personal data must not be shared externally without appropriate controls.
• Customer data should not be uploaded to personal cloud services.
• Financial reports must not be sent outside a defined group of recipients.
• Production schematics should not be copied to USB devices or shared through unknown channels.

These are often well-founded hypotheses based on an already identified risk. But a hypothesis remains a hypothesis until it has been proven.

Before it can become an active DLP policy, we need to understand how the information actually moves, which user behaviors are legitimate, which false positives occur, and what impact the policy would have had if enabled across the entire organization.

A hypothesis must therefore be tested against real workflows before it is translated into a production-ready DLP policy.

The following five steps show how an organization can move from an assumption to an anchored, measurable, and practically feasible policy.

1. Formulate the hypothesis – define the information, the behavior or flow, and the potential risk.
2. Test in simulation mode – collect data without disrupting the business.
3. Analyze and adjust – identify false positives and assess how effective the controls are.
4. Anchor it in the business – complement the analysis with business context. Bring the results to the business for feedback.
5. Decide on implementation.

Below I’ll go through these steps in more detail.

Formulate the Hypothesis

A good DLP policy starts with a clear purpose. What do we want to protect, from what type of event, and why? But a truly strong DLP policy can also originate from a hypothesis developed by us as IT and/or security professionals. It may begin as an unstructured description, yet still point to something essential.

Example 1: “We believe that documents containing national identification numbers are sometimes shared externally by HR via emails with unauthorized recipients.”

Example 2: “We believe that financially sensitive information is shared with external recipients before approved publication.”

Example 3: “We believe that production results are downloaded, moved to USB devices, and then distributed further.”

A well-formulated hypothesis should describe:

• Which information is concerned
• Which information flow or activity is in focus
• Which risk has been identified
• Which parts of the organization are affected
• Which risks are associated with implementing a technical solution

The questions above make the discussion more concrete. Instead of speaking generally about “protecting sensitive data” or saying, “we want to solve data exfiltration with DLP,” we can discuss a specific risk in a specific scenario.

But as mentioned above, this is one path toward the goal. It does not have to be the only path!

Test in Simulation Mode

The next step is to configure the policy in monitoring mode. When using Microsoft Purview, the rules should preferably be published using the built-in simulation mode. The purpose is to evaluate the hypothesis and, ultimately, the DLP rules that have been created.

The objective is to gather facts and deepen our understanding of the specific flows and controls we have defined, without disrupting the business.

In simulation mode you can, for example, see:

• How often would the policy be triggered?
• Which types of files are affected?
• Which tools are most commonly involved, such as email, devices, etc.? This naturally depends on which rules have been implemented as part of the hypothesis.
• Which user groups or departments are affected?

This is an important part of the method. The DLP policies shouldn’t become theoretical controls designed without connection to reality. Instead, they become part of a data-driven process in which assumptions are validated against actual risk-related behavior in the organization.

Analyze and Adjust

Once the policy has been collecting information for a period, the real work begins: analyzing the results.

The first version of a policy may be too broad, too narrow, or focused on the wrong direction because the wrong signals have been used. A rule for national identification numbers may, for example, be very effective at detecting test data, while a rule based on sensitive words may match arbitrary content. The policy may also match legitimate workflows. The important point in the analysis phase is that not every result needs to be positive. A “negative” result is not a failure. It is an outcome from which we can learn, iterate, and potentially change direction.

Questions to ask during the analysis phase include:

• Are the matches relevant to the hypothesis?
• Which matches seem to be a genuine risk?
• Can we identify patterns in user behavior?
• Does the policy need to be adjusted?
• Should certain workflows be excluded?

The analysis can produce many different outcomes. It may, for example, show that we need to refine the controls implemented in the policy. It may also make it clear that our hypothesis was incorrect and irrelevant. Whatever the outcome, we have gained evidence that can either be acted upon or set aside.

Anchor It in the Business

Now we are approaching the real strength of simulation mode! When we, as the supporting functions, develop a policy and publish it directly in enforcement mode, it rarely ends well, especially if we do not have sufficient insight into the business. Frustration builds quickly, and the discussion can easily become centered on the restrictions introduced and the friction perceived by the business. A better starting point is to present validated observations and use them as the basis for a joint decision, or as a way to get the business on board, ideally, with feedback.

Consider the following example:

If we simply say, “We want to introduce a DLP policy that blocks all external sharing,” or even announce, “We have introduced a DLP policy that blocks all external sharing,” the outcome is unlikely to be positive, particularly if the business depends on that specific workflow.

A better approach would be to say, “We have tested a policy in simulation mode for four weeks. It matched external sharing 240 times. Of these, around 60 appear to involve external sharing with public domains and should be blocked. Based on our current understanding, 120 appear to be legitimate workflows with our partners, which we have addressed, and we need your help to assess the remainder.”

The conversation becomes more constructive and, above all, turns into a dialogue around a shared goal rather than one filled with frustration over restrictions on essential workflows. The business is not simply handed a policy. It takes part in validating the hypothesis and shaping the controls.

Decide on the Implementation

Following the analysis and dialogue with the business, we should have enough information to decide on the future of the hypothesis and, by extension, the DLP policy. Possible decisions could include:

• Proceeding with the policy
• Adjusting the policy and running a new simulation
• Implementing the policy only for selected groups
• Starting with warnings, or monitoring only, instead of blocking
• Stopping the policy because the hypothesis could not be validated or is not relevant

An established rollout method is as follows:

1. Simulation mode – understand the behavior; this has generally already been completed if nothing has changed.
2. Warning – when we move into warning mode, the wider user population is brought into the process, but no action is taken at this stage. This provides an opportunity for education and guidance.
3. Enforcement mode – the policy is rolled out broadly with the implemented actions.
4. Follow-up – measure the effect and adjust as needed.

DLP Is Not Just Technology

Tools such as Microsoft Purview can provide valuable insight for identifying, classifying, monitoring, and protecting information. But technology alone cannot determine the right level of protection for a particular business process. That requires collaboration between technology teams and the business. Those of us in central supporting roles responsible for managing the systems contribute specialist knowledge of the tools and of potential threats to the organization. Compliance-oriented roles contribute to regulatory requirements, data owners help assess the value and use of the information, and the business, similar to the data owner, validates the information and how well the controls work in day-to-day operations. When we organize ourselves in a way like the above, DLP becomes easier to manage and more precise.

From Hypothesis to Evidence-Based Implementation

To summarize, the best DLP policy is rarely the one that is written perfectly from the start. It is the one shaped through a hypothesis, simulation, analysis, dialogue with the business, and continued development based on feedback and results.

The method can be summarized in five parts. Each step should provide enough evidence to determine whether the policy can move forward, needs to be adjusted, or should be stopped.

1. Formulate a hypothesis about which information and behavior may introduce risk.
2. Set up a policy in simulation mode to collect data without disrupting the business.
3. Analyze and develop it further until the policy produces relevant and useful matches.
4. Bring the results to the business for feedback, discussion, and anchoring.
5. Decide on implementation, with follow-up.

In this way, DLP becomes more than a technical control. It becomes a shared way of working to protect the organization’s information through controls that are anchored in the business.