Data Loss Prevention in SharePoint Server 2016

Thank you to everyone that attended my webinar on April 28th on Data Loss Prevention in SharePoint 2016.  We had a great turn out.  As I said in the web cast, Microsoft is bringing great features from SharePoint Online like the Compliance Center to the on premise world with SharePoint Server 2016.  This is an excellent advancement for our on premise SharePoint deployments.  My webinar was a review or tour of the Data Loss Prevention features we now have for our on premise deployments with SharePoint 2016.

Introduction

Today we're constantly hearing about or experiencing threats to our business, and in particular to our business data.  To protect the business and its reputation, or to comply with business standards or industry regulations, organizations need to protect their sensitive corporate data and put in place measures to prevent its disclosure.  Sometimes that disclosure is inadvertent, or accidental. Sometimes its intentional or malicious.  In either case, a data loss prevention solution (or DLP) is one one of the necessary solutions to this problem.  SharePoint 2016 now includes a robust Data Loss Prevention capability that can help us protect that data.

More specifically, when we talk about data loss prevention we're talking about automated systems which scan our data for keywords, regular expressions and patterns looking for specific types of data, and then either reporting or enforcing policies on that data.  This includes many different types of data, including:

• Personally Identifiable Information (PII): passport numbers, social security numbers, tax identification numbers or even drivers licenses
• Payment Credit Information (PCI or PCI DSS): credit card numbers
• Financial Data: debit card numbers, bank account numbers, SWIFT codes or routing numbers
• Health Insurance Data: medical record numbers, policy numbers, patient information

If we look back, data loss prevention has been a long time feature of Office 365.  However, until recently it was only available in Exchange Online with policy tips and policy enforcement.  In mid-2015, Microsoft announced that the Office 365 Compliance Center would include DLP for SharePoint Online and OneDrive for business, and that solution was released to the various Office 365 tenants through the last part of 2015 and into early 2016.  Now, with the imminent release of SharePoint 2016 Server we also have this capability for our SharePoint on premise deployments.

Prerequisites

You need the following prerequisites in place before configuring the SharePoint 2016 DLP within the new Compliance Center:

• Create a Search Service Application (mandatory)
• Start the search service, Define a crawl schedule, Perform a full crawl
• Must have a healthy search index and crawl for DLP policies to be effectively applied
• Configure out-going email (recommended)
• Turn on Usage Reports (recommended)
• Create the eDiscovery or Compliance Center site collections (mandatory)
• eDiscovery - for DLP queries to identify where sensitive data exists
• Compliance Policy Center - for DLP policies to monitor and enforce policies
• One or the other is mandatory - you can create both, but both are not mandatory
• Assign the organization's Compliance Team with permissions to access the eDiscovery and/or Compliance Center site collection(s) through the Site Collection Members group

Issue Follow-up: DLP Policy Enforcement Time & List Items

Some of you will remember that there was an issue with the enforcement of the DLP policies in the library that I was demoing during the presentation.  I was showing a library with a document that contained 5 credit card numbers and the blocking policy was enforced on that document.  However, there were 5 other documents that had 1 credit card number each in which the 'policy tip' policy (or monitoring and warning policy) was not getting enforced on those - even after waiting 12 hours.

Well, after waiting 14 hours the 'policy tip' policy final got applied to those 5 additional documents.  Considering those documents contained a credit card number, and my understanding is that the policy templates which check for credit cards are considered high priority internally, I would have expected those to be enforced sooner.  

Please note: I was launching full crawls and the timer jobs which are supposed to enforce DLP policies manually over and over, to no avail.  

What I have read, that it can take up to 24 hours for DLP policies to be enforced, is obviously true.  If I had a 1000s of users, with millions of documents, and users updating documents adding/removing sensitive information all the time, I could understand the 24 hour wait time.  But I added 5 documents into 1 library, in a farm of 20 documents total, with only 1 user using the farm - in this case I would have expected faster performance.  Enforcing DLP policies is often time sensitive and waiting 24 hours can mean in some situations that sensitive information is already exposed.

As well, one of the tests I was running in my farm was if the DLP policies get enforced on list items.  Even after waiting over 24 hours, we can see that the DLP policies are not applied to the list items in this list containing sensitive information (credit card numbers) even after waiting 5+ days and ensuring that full crawls are successfully run and all associated timer jobs are also successfully run:

Presentation and Recording

The presentation slide deck can be found here:

30 on Thursday - data loss prevention in SharePoint 2016 - protect your sensitive information - published from AntonioMaio2

The recording to last Thursday's webinar can be found here:

Final Thoughts

Data loss prevention is just 1 critical part of securing our sensitive data.  This includes identifying sensitive data, monitoring its usage and enforcing polices which control its usual and disclosure.

• The fact that SharePoint 2016's DLP uses the search index is both a blessing and can cause issues - traditional SharePoint DLP systems have had challenges accessing and scanning content from outside of SharePoint and using the search index allows the DLP capability to operate as quickly and efficiently as possible.
• If something is not in the search index, it will not be found by your DLP policies.  So, the freshness of your search index and the health of your search crawls will affect how effectively your DLP policies are applied.

The DLP capability within SharePoint 2016 is a great start!  However, I would like to see it evolve particularly in the following areas:

• Apply DLP policies to list items, in addition to documents.  I have seen several incidents in the field where clients store sensitive information in list item metadata columns.
• More policy templates
• Exchange Online has 80 templates and SharePoint online has 51; SharePoint 2016 on premise has only 10.
• Especially include health related policy templates, looking for HIPAA and medical related sensitive information.
• Customizable sensitive data types - you can do this in many other DLP systems now.
• Today policies are location based (which site collection it resides in) and condition based (what sensitive data types are included and the number of instances.  I would like to see event based policies included as well - like enforcing policies upon upload, upon adding an item, upon deleting an item, upon editing an item, etc.
• More actions available for policies, like encrypt content with IRM upon download.
• One compliance center for all site collections, including OneDrive for Business (MySites), across all web applications.  We can do this today with the eDiscovery Center in SharePoint 2016 and in SharePoint Online with OneDrive for Business in Office 365 - why can we not do this in the SharePoint 2016 Compliance Center.
• More control over when policies are run - the ability to say "Evaluate all policies now" as opposed to running timer jobs and guessing which is the right timer job to run and getting no results when you run them all.
• Document matching capability - allow us to specify a library of documents which are compared to documents in the system as part of a DLP policy, along with a required percentage of match for each document for a policy to fire.  This would help us prevent disclosure off executive communications, intellectual property, documents that follow a common format, etc.

Finally, I encourage everyone to starting learning about and testing the SharePoint 2016 eDiscovery DLP queries and the Compliance Center's DLP policies.  You do need to test DLP policies in a TEST or STAGING farm (or TEST site collection if you don't have a separate farm) before deploying them to a PRODUCTION environment because they often need tweaking and you don't want to do that while Production users are trying to access data they need.  And one more time... ensure you have a healthy search index and crawl: if something isn't in the search index it will not be found by the DLP policies you put in place.

Enjoy.
   -Antonio