In-Depth

Breaking Down the New SharePoint DLP Controls

Administrators can now set policies and controls that can be tracked for compliance with new data loss prevention tools in SharePoint Server 2016.

• By Jasson Walker
• 04/11/2017

One of the unsung features Microsoft added to SharePoint Server 2016 last year was the support to reduce data leakage. SharePoint 2016 Data Loss Prevention (DLP) lets administrators create policies that can restrict users’ access to documents with sensitive or personal information.

Microsoft has offered DLP capabilities to help organizations reduce data leakage for some time now -- it was first introduced as a feature in Exchange Server 2013. DLP in Exchange Server 2013 implements DLP in motion (that is, it secures sensitive/personal information while it’s in motion over a network), while DLP in SharePoint Server 2016 implements DLP at rest (that is, it secures sensitive/personal information while it sits in a repository).

SharePoint DLP has evolved since it was first included in Exchange Server 2013 and Office 365, and the latest iteration of DLP in SharePoint Server 2016 provides some significant benefits, but also has some drawbacks that still need work. The new SharePoint Server 2016 allows administrators to automatically protect sensitive information spanning site collection. In addition to letting admins create DLP queries to discover data that might be sensitive, such as information subject to regulation, it allows them to set up policies, as well as monitor activities by users attempting to violate policies.

Microsoft outlines how to implement the DLP features in SharePoint Server 2016. But before deciding on whether to build your DLP policies with SharePoint, it’s important to weigh the benefits and shortcomings of the DLP features added to SharePoint Server 2016. In addition to outlining both, I’ll share some useful tips accumulated through my hands-on work with SharePoint DLP.

SharePoint DLP Benefits
Role-Based Communication Features
For a DLP system to work, all parties involved, such as content users and compliance managers, need specific information when a DLP policy affects the availability of content. Accordingly, SharePoint DLP has terrific communication features that are customized according to their roles. For instance, content users attempting to access a file that they’re not permitted to open based on the DLP policy will receive a red "block image" (see Figure 1). As a result, the content user can clearly see that access to the file is blocked before they even click on the file.

If a content user wants to explore her options for working with the blocked content, she can view the Policy tip associated with it, which is shown in Figure 2.

When a user uploads or updates a document that violates a DLP policy, SharePoint DLP e-mails the content user to alert them about the policy violation (see Figure 3).

Communication with Compliance Managers
Naturally, the needs and requirements of content owners and compliance managers are quite different, but the features in SharePoint DLP are similar. For example, when a user uploads or updates a document that violates a DLP Policy, SharePoint DLP e-mails an incident report to the compliance manager (see Figure 4).

Wide Array of Sensitive Information Types
SharePoint DLM offers a list of 51 sensitive information types available. Each of these define the specific format for a sensitive information type that you can use to create DLP policies. These sensitive information types make it much easier for you to create DLP policies that restrict access to content with domestic and international passport info, credit card, info and bank account info, among others. Microsoft published a complete list of these sensitive information types, which you can view here.

Manual DLP Policy Override
If a SharePoint DLP policy blocks access to a file that a user really needs, he can manually override the policy block. All he has to do is click on the Open menu and then select the View policy tip. Once the Policy tip opens up he should click the Resolve button, which can be seen back in Figure 2.

After you enter a reason for the override, the file is unblocked and available for access.

SharePoint DLP Shortcomings
While SharePoint 2016 introduces some key DLP capabilities, as noted earlier there are some concerns worth considering.

DLP Policy Implementation Delay
SharePoint DLP is dependent on the SharePoint Search Index, which is a component of SharePoint Search. In order to under­stand how SharePoint DLP works, you have to understand how SharePoint Search works. The search architecture (see Figure 6) shows how various datatypes interact:

• Crawl component: Crawls content sources to collect crawled properties and metadata from crawled items and sends this information to the content processing component.
• Crawl database: Contains information about crawled items, such as last crawl time, the last crawl ID and the type of update during the last crawl.
• Content processing component: Crawls content sources to collect crawled properties and metadata from crawled items and sends this information to the index component.
• Index component: Receives the processed items from the content processing component and writes them to the search index. This component also handles incoming queries, retrieves information from the search index and sends back the result set to the query processing component.
• Query processing component: Analyzes and processes search queries and results. The processed query is then submitted to the index component, which returns a set of search results for the query.

Because SharePoint DLP depends on this SharePoint Search Index, content with sensitive/personal data must be indexed before any DLP policies can be applied. This raises an issue when your SharePoint content is crawled infrequently. For example, if you crawl your SharePoint content once per day, and someone uploads a file with sensitive information, after the crawl is completed for the day, it will take a full day for this new content to be crawled, and in turn discovered to contain sensitive data by SharePoint DLP. More frequent crawls are recommended, depending on the volume of sensitive data and the overall performance of the SharePoint farm.

DLP Policy Assignment Delay
After you create a DLP policy, you must assign the policy to a site collection for it to work. But when you assign a DLP policy to a site collection, there will likely be a delay before the assignment takes effect. In fact, the Web page where you make this assignment gives you a warning about this delay.

Site collection assignments are performed by the Compliance Dar Task House Keeping and Compliance Policy Processing Timer Job, which runs once every 24 hours by default. Therefore, it can take up to 24 hours for these jobs to run and for the assignments to be performed.

Unfortunately, you must perform a manual assignment of each DLP policy with each site collection to which you want to apply the policy. Hence, if you have a Web application with 20, 50, 100, 500 or more site collections, and you want all of these site collections to be assigned to a DLP policy, you must perform a manual assignment of each DLP policy with each site collection.

Customization Limitations
Two areas I wish could be customized, but was unable to do so, are Sensitivity Information Type Templates and notification e-mail messages.

Overall Assessment
As a SharePoint administrator, you’re ultimately responsible for protecting all of the data in your SharePoint environment. And because DLP automates the ability for SharePoint to discover and restrict access to sensitive information, it’s a welcome feature in SharePoint Server 2016. Despite some of the drawbacks to the new DLP features in SharePoint Server 2016, and the fact that implementation can be time-consuming and cumbersome for large-scale SharePoint farms with 50-plus site collections, the wide array of built-in DLP policies, excellent communication features, and overall data protection effectiveness make DLP a feature that you should seriously consider implementing.