Data Loss Prevention (DLP) has spread from Exchange to SharePoint so that the use of sensitive data in document libraries can be controlled by policy. Here's what Microsoft discussed about DLP at the Ignite conference.
Data Loss Prevention (DLP) is a feature that was first introduced in Exchange (2013 and Online) and is now in SharePoint Online (but not the on-premises version). I covered the initial news on this topic last year and took the chance at the Microsoft Ignite conference to find out had the functionality predicted then been realized in production.
DLP is actually a great example of how engineering teams are now working across multiple products rather than in the narrow silos of the past and it’s obvious that a lot of lessons learned from the DLP implementation in Exchange have influenced the implementation in SharePoint Online to provide protection against the misuse of sensitive data in documents. The documents can be stored in SharePoint or OneDrive for Business libraries.
Exchange uses the transport service as its single choke point to ensure that sensitive data will always be picked up in messages. DLP checking is also integrated in Outlook 2013 and Outlook Web App to provide instant feedback to users when they include sensitive data controlled by policy (like a social security number) in messages. SharePoint is obviously different, so it uses two approaches to monitor documents.
First, a background crawler checks documents as they are created or updated to ensure that the content doesn’t violate policy. For example, a policy might determine that the inclusion of a single SSN is OK but anything more than that should be reported. Policy tips can be signaled if a violation is detected, but the only applications that support these tips today are Word 2016, PowerPoint 2016, and Excel 2016, all of which are in preview.
Second, the indexer component that updates the search indexes used by SharePoint examines content as it is inserted into the indexes. Interestingly, Microsoft had to create a special handler to ensure that sensitive data buried in Excel spreadsheets could be picked up.
When policy violations are detected, DLP policy rules can call for incident reports to be generated and sent to a specific mailbox. On a busy system, especially when users aren’t particularly aware of the need to use sensitive data in an appropriate manner, a large number of incident reports can be generated. A lot of detail is contained in these reports but it also takes a lot of time for a human to review the reports and decide if violations have occurred and what action should be taken. And despite the DLP reports that are available in, it is often difficult to pick up trends that indicate where sensitive data is being mishandled.
To address this problem, Microsoft showed an integration between DLP and Dynamic CRM. Incident reports can be sent to CRM to become events or tickets. The data in the incident report and the attached message (a copy containing the sensitive data) is used to figure out what’s happening. CRM can collate information about incident reports to identify situations where specific individuals might be the root cause of multiple incidents or a specific type of data is being misused. The integration isn’t ready yet and is some months away, but Microsoft said that they are working with third parties to develop similar capabilities to manage DLP incidents in other products.
Another demo featured how to create a SharePoint eDiscovery case to look for documents that contain sensitive data using a new search term provided for this purpose. I was amused at how the Microsoft speaker input a complex Keyword Query Language (KQL) query as if it was the most natural thing in the world. I bet not many who attended the session will be able to repeat this feat without many checks against TechNet to confirm KQL syntax.
The session I attended also covered DLP document fingerprinting. This feature has been around for a while now and allows companies to create their own sensitive data types (for example, a company-specific HR form) and then use those data types within DLP policies. Although Microsoft is busy creating standard sensitive data types (like credit card numbers or passport identifiers – with another 30 new types covering country-specific types coming soon), there’s no way that they can define every possible form of sensitive data, which is why document fingerprinting is so useful.
After a number of years of development, DLP has come of age. It is a powerful way to create and manage policies to control the use (or abuse) of sensitive data within email and documents. If you’re an Office 365 customer, DLP is easy to deploy across both Exchange and SharePoint. On-premises customers can use it with, but the SharePoint side will have to wait a while more.
Follow Tony @12Knocksinna