Office 365 Security and Compliance: Guide to Creating Custom Sensitive Info Types and DLP Policies

Office 365 Security and Compliance: Guide to Creating Custom Sensitive Info Types and DLP Policies

In my last blog post, I covered configuring some of the out of the box data loss prevention policies that Microsoft’s security & compliance center offers. Yet in order to meet the specific needs of your organization, custom information types and DLP policies can be created. In this guide, I will show you how to use Microsoft Office 365’s Security and Compliance center to categorize sensitive content with custom sensitive information types and create custom data loss prevention (DLP) policies.

Part 1: Custom Sensitive Info Types for O365 Security and Compliance

First we’ll create a new sensitive info type. If the default options meet your needs continue to section 2 and we’ll get into creating a policy that can use these info types to classify your content.

Step 1:

Navigate to O365’s security & compliance center and open up sensitive information types under classifications, create a new one and give it a name & description.

Requirements for Matching the Sensitive Info Type for O365 Security and Compliance

Step 2:

Add a matching element, which is the sensitive info that this type will search for in content. The matching element will be the first thing an info type looks for in content followed by supporting elements if you choose to use them. Supporting elements are additional criteria that help with accuracy when identifying potentially sensitive content.

Options for matching and supporting elements:

  1. Regular expression
  2. Keyword list
  3. Dictionary

The number of keywords you can add to a keyword list is limited, but you can describe a greater number of keywords/patterns with a regular expression or a keyword dictionary. I’m going to walk through creating a sensitive info type that uses a regular expression as a matching element and a keyword list as a supporting element to detect Social Security numbers.

Regex:

  • \b(?!000)(?!666)[0-8]\d{2}[ \-](?!00)\d{2}[ -](?!0000)\d{4}\b

Keyword list:

  • SSN, “Social Security Number”, “social security number”, “Social Security #”, “Social Security No”, “Social Security Number”, SSN, “SS Number”, SS#, SS #, “SS Num”, “Social Security Num”

Below I’ve broken down some of the additional parameters you can configure for improving the accuracy of the sensitive info type as seen in figure 1.1.

Minimum Count – Keyword List

  • The minimum count describes the minimum number of the described keywords in your list required to satisfy a match. If you’re creating a policy for something more specific like a tax form which has a standard template that always has specific keywords then you may want to increase this count for accuracy.

Confidence Level

  • The confidence level defines the match confidence of the pattern, this becomes more important later when you use this sensitive information type in a DLP policy. For example, you can use more restrictive actions (such as block content) only on higher confidence matches and less restrictive actions (such as send notification) with lower confidence matches.
    • This option is really valuable as DLP policies without this flexibility can be frustrating and drive employees to find alternative routes to sharing content. For example, if your policy causes a lot of false positives and users don’t have the option to override it then they’ll likely just find a different way to share out the content like Dropbox or a personal email. Once your users start doing this, you have no control over where your content is being shared.

Character Proximity

  • When the matching element is detected, supporting elements only will trigger a match when found within this proximity to the first pattern element. By having the keywords supporting the regex, I have more confidence in an actual match since this info type will only look for those keywords after identifying an actual SSN type string of numbers as defined in the regular expression.

Step 3:

Test the sensitive information type:

Take some time to test out the info type, here you can use documents that you know should be flagged for sensitive content to test and tune your info type’s criteria for the best results.

The results give you a better idea of what the sensitive information type is able to detect based on your criteria.

Section 2: Create a Custom Data Loss Prevention Policy

We can create a data loss prevention policy to perform some actions when a sensitive content type has been identified. Navigate to the Security and Compliance center from the admin centers list, in the O365 admin center. Expand-out Data loss prevention from the options on the left and click Policy àCreate a policy.

Step 1:

Choose the information to protect.

By default, there are 3 categories which come with pre-built DLP templates, here we’ll choose the 4th option Custom to create our own.

Step 2:

Name your policy.

Since this is a custom policy, it will be helpful for end users to give this policy a relatable name and description. 

Step 3:

Choose locations.

You can specify where this policy applies to, and whom it applies to in their respective zones. Notice that you can include or exclude different principles depending on the zone. For example, you can exclude the security team from a policy that would be counter-productive to their daily operations.

Step 4.1:

Customize the type of content you want to protect.

This is where we can either leverage the custom sensitive information type we created earlier or use advanced settings to set up rules that offer more conditions and exceptions.


To simply leverage a custom info type, choose the first option in figure 2.4 and click edit to add the classification type (sensitive information type) like in figure 2.5.

Step 4.2

Advanced options for specifying sensitive content criteria.

Choosing the second option (Use advance settings in figure 2.4) will expose addition rules and settings after clicking next. The following sections describe each of the advanced options.

Conditions & Exceptions

You can protect (or exclude) content that matches any of the following conditions:

  1. Contains sensitive information
  2. Has specific labels applied
  3. Sent in email by someone whose IP address matches a specific address or range
  4. Sent in email to a specific recipient domain
  5. Included in attachments with specific file extensions
  6. Included in documents with specific properties

Note: These same options available for conditions are also available as exceptions – Ex. Don’t apply this rule when content is sent via email to a specific domain.

Actions

Choose what you want to happen when this policy is triggered. You can block sharing, restrict access and/or encrypt content that’s been found to have sensitive content. Also, you can specify whether this policy affects everyone or just external users.

User Notifications

Use notifications to inform your users as to why the policy was triggered and recommend next steps. Here I’m recommending that they add a label to this document, you can also automatically notify specific people when this policy is triggered. Alternatively, you can create a label policy that will automatically label documents based on the sensitive information type detected.

Note: Notifications for teams will be displayed in the chat client itself.

User Overrides

You can allow users to override the policy and optionally require a business justification. Consider the end user impact when making this decision because false positives are a frustrating reality. 

Incident Reports

You can enable incident reports to automatically notify you via email whenever a policy match occurs. Configure a severity level for the policy which will be highlighted in the compliance dashboard as well as the emailed incident report.

Options

As you create more policies, these additional options will become useful to streamline the flow of policies in your organization and avoid conflicts. Consider this situation:

  • You have a finance department that deals with documents containing financial data on a daily basis.
  • You’ve also made a DLP policy that scans documents for financial data and prevents it from being shared.
  • Now every time a person from that department needs to send out a tax document to an employee they need to request approval from a manager. This wastes time and causes more work for the manager and the finance team.

Instead, we can create a rule that excludes members of the finance team. By enabling the rule below with the rule being that if they are a member of the finance team do not process additional rules for the Financial DLP policy.

Conclusion


Every organization is different and must adhere to different types of compliance and regulations, creating a policy to address your use-cases is important. Leveraging these custom policy options can help prevent data leaks and help protect your sensitive data.

It’s important to note that setting up these policies can help with DLP compliance but your organization still needs to be able to prove that it is compliant when audited. This means you’re your organization needs to be able to audit, report and document how data is stored, accessed, and managed. which is best handled with a data access governance solution like StealthAUDIT for SharePoint.

Here’s an overview of what StealthAUDIT for SharePoint can do:

Auditing and Reporting

  • Understand effective access to SharePoint 2010, 2013, and 2016 Sites, Lists, and Libraries, as well as determine where any user or group has access
  • Identify where direct SharePoint permissions are applied which may be indicative of high-risk or otherwise toxic conditions
  • Identify instances where resources are being shared explicitly or anonymously

SharePoint Governance

  • Identify site ownership through analysis of SharePoint security permissions, content ownership, activity, and SharePoint change tracking
  • Assign owners to sites and enable them to perform periodic reviews of access
  • Enable owners to make ad-hoc access modifications to their data
  • Enable users to request access to SharePoint resources and have the request reviewed, approved or denied by the data owner

Threat & Vulnerability Detection

  • Identify files (including images using OCR) containing sensitive content such as Credit Card and Social Security numbers, personal health information, and dozens of other types of Personally Identifiable Information (PII) in multiple languages
  • Create and search for custom criteria specific to an organization such as Employee ID numbers, trade secrets, and product formulas

..and more

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.

Privacy Preference Center

      Necessary

      Advertising

      Analytics

      Other