Follow me on Twitter @AntonioMaio2

Tuesday, June 28, 2016

Data Loss Prevention in SharePoint 2016 & Office 365
How to Protect your Sensitive Information

Thanks to everyone that attended my session on SharePoint 2016 and Office 365 Data Loss Prevention yesterday.  It was great to meet everyone and share my thoughts and experience related to Microsoft's DLP technology within these two products.

The Microsoft Data Loss Prevention (DLP) capability that's now integrated into Office 365 and SharePoint 2016 is a great advancement in information security within these products.  It allows you to easily find sensitive data within your SharePoint or OneDrive for Business environment and automatically enforce policies on that content.  Those policies can identify sensitive information for end users, providing them with policy tips on how to handle it.  They can also block sensitive information from being accessed, and issue automated incident reports when policies are violated.

There are some prerequisites and dependencies that are important to understand when configuring DLP policies.  There are also some key differences between the DLP solutions within an on premise deployment of SharePoint 2016 and Office 365.

Prerequisites

In SharePoint 2016, the prerequisites for setting up DLP are the following:

  1. Create your search service application, define a crawl schedule and perform a full crawl.
  2. Configuring out going mail is highly recommended, so that policy notifications can be sent via email.
  3. Turning on Usage Reports is highly recommended, so that incident reports and overrides can be logged appropriately.
  4. Create an eDiscovery Center or Compliance Policy Center site collection, or both.  
    • You must create a different Compliance Policy Center per web application - you cannot have one that applies to all site collections across all web applications.  
    • However, you can create one eDiscovery Center site collection which can run DLP queries across all site collections in all web applications.
  5. Assign permissions to your compliance team, risk team and/or information security team so that they may access and manage DLP policies.  Its recommended that permissions are granted by making these users members of the Site Collection "members" group.

In Office 365, these prerequisites are taken care of for you.  You can simply access the Security and Compliance Admin Console within your tenant's Office 365 Admin Center, and start creating policies.

Dependence on Search

As we talked about in the presentation, the core data source behind both the SharePoint 2016 and Office 365 DLP is the SharePoint search index.  If content is not in the search index, the DLP engine won't find it.  This makes it all the more critical to have a healthy search and crawl configuration.

If you have explicitly excluded certain sites or content from SharePoint search, DLP policies cannot be applied to those areas.

When new content is added to SharePoint 2016, a crawl must occur and the search index updated with that content.  In addition, there are 4 timer jobs that must run to enforce DLP policies.  All this must occur before DLP polices can be enforced on sensitive information.

Options for Creating DLP Policies

In Office 365 a DLP policy is created by:

  • Specifying the locations where it may be applied: 
    • SharePoint Online (all sites or specific sites)
    • OneDrive for Business (all sites or specific sites)
  • Configuring one or more DLP Rules - rules are made up of:
    • Conditions
      • Select any number of 80 sensitive data types.  You may not create custom sensitive data types.
      • With each sensitive data type select the min and max # of instances
      • Who content is shared with (people inside or outside the organization)
      • Metadata properties
    • Actions
      • Send an email notification (default message or custom message)
      • Show a policy tip (default tip or custom tip)
      • Allow override (with or without business justification)
      • Block content (to all users except site owners, document owners or last modified)
    • Incident Reports
      • If a report is logged
      • Severity level
      • Send an email with the report
    • Configure some general settings for the rule like a name and description.
  • Configure some general settings like a name and description for the policy, as well as if it is configured.

In SharePoint 2016, a DLP policy is similarly created, but there are some differences:

  • Specify a name.
  • Select from one of 10 policy templates.  Each policy template relates to a combination of 10 sensitive data types.  
  • Select the number of instances of the sensitive data type which trigger the policy.
  • Specify an email address to which an incident report will be emailed
  • Select whether or not to display a policy tip (you cannot customize the text of the policy tip)
  • Select whether to block access to the content to all users except site owners, the document owner or the user that last modified the document.
  • Then you must assign the policy to a site collection where you wish it to be enforced.  You must specify each site collection one at a time.  You cannot easily apply it to all site collections.  As well, you cannot specify the application of a policy down to the subsite level.

In SharePoint 2016, it can take up to 24 hours for a DLP policy to be enforced on new documents.  Once again, you must wait for the search crawl to run, and then the 4 timer jobs related to this feature to run.  Even if you try to execute the timer jobs manually, I have found through testing that it can take up to 14 hours in a small SharePoint 2016 farm.

Areas for Improvement

As eluded to above, in Office 365 you can search for up to 80 sensitive data types.  In SharePoint 2016 on premise, you can only search for 10 - those 10 only relate to US and UK sensitive data types.

In SharePoint 2016, you cannot:
  • Specify more than one policy template per policy.  There is no concept of multiple rules making up a policy as there is in Office 365.
  • Customize which sensitive data types are searched for within the policy template, as you can in Office 365.
  • Customize either the email notification sent or the policy tip shown to the user, as you can in Office 365.
  • Specify any sort of HIPAA related sensitive data types, or sensitive data types from countries other than the US and UK.  Office 365 has access to a greater range of sensitive data types including those from many countries and those related to the HIPAA regulatory compliance standard.


Finally, either in Office 365 or SharePoint 2016, the following limitations currently exist:

  • DLP policies are not enforced on list items.  They are only enforced on documents.
  • DLP policies are not enforced when documents are uploaded to SharePoint.  They are only enforced on content already residing in SharePoint, which has been found by the Search crawler.

Presentation

My slides from yesterday's presentation can be found here:



Some Great Questions

There were some great questions raised that I would like to come back to readers with answers to in the coming weeks:

  • In SharePoint 2016, if you deploy additional language packs would you get additional sensitive data types related to countries or geographies with those languages?  My suspicion is no, but I think this is worth confirming.
  • If you have a hybrid configuration of SharePoint 2016 on premise with Office 365, your search index is combined and stored within Office 365.  In this case, how are DLP policies configured and managed?  What is the user experience like?
  • If you have metadata associated with documents and that metadata contains sensitive data, will the DLP policy be enforced on that document?  In this case, I suspect that if the metadata field is a managed property that is used by Search that it will find and enforce policies on this metadata, however once again this is worth testing to prove out.
Enjoy.
   -Antonio




No comments:

Post a Comment