The two protection controls I’m discussing in this post are Data Loss Prevention (DLP) and Azure Information Protection (AIP). Although DLP has been around for several years, AIP is (relatively) new on the scene. They both protect data in different ways and are part of Microsoft’s Information Protection solution to help improve your organization’s security posture. I was confused about the overlap between these two products and can only assume I’m not alone. I set out to understand the differences and to determine if both were required for an organization to protect their documents. It turns out… yes!
DLP relies on the search index and a central DLP policy store (where protection rules are evaluated) to protect data. DLP queries the search index and compares its content against the DLP policies for potential data breaches. The DLP policy store is synced to SharePoint Online, OneDrive for Business sites, Exchange Online and Office 2016 clients (Word, Excel, PowerPoint) to ensure data is being protected at all endpoints. A combination of being reliant on the freshness of the search index (crawl schedule) as well as a synced policy store means there is potential for new/changed content to be unprotected by the latest DLP policies for periods of time. With DLP, you can block a document from being shared or an email from being sent both within and outside of your organization if it meets the rules you have defined.
AIP is a protection mechanism that lives within the document itself. A label is associated to a document and then stored in clear text as a sensitivity property on it. This property stays with the document regardless of where it is stored/shared. You can use AIP to encrypt a document, to apply visual markings and to assign specific actions allowed such as copy, edit, forward, etc. In addition, DLP (and other applications) can read the sensitivity property on a document to take further action. I’ve blogged about this in a recent post, Use AIP Labels in DLP Policy Rules.
Do we need both DLP and AIP to protect our corporate documents? YES! Their capabilities and coverage are not the same. I’ll walk thru a Contoso example to demonstrate why.
TLDR? Skip ahead to the My Takeaways section at the end. 🙂
Let’s start by defining the protection control we want to implement at Contoso to prevent sensitive information from leaving their environment.
Control: In Contoso, any document containing sensitive information (Credit card numbers, customer numbers, personally identifiable information, etc.) should be considered ‘Confidential’ and not be copied nor shared outside of Contoso.
Protecting a confidential document using DLP only
At Contoso, a DLP policy was configured with a rule to automatically identify sensitive information in a document. If found, it will restrict the document from being shared to anyone external to Contoso.
Recall that DLP uses the search index to identify documents it must enforce its actions on. For those familiar with how the search crawl process works in SharePoint, you know there is a window of time between when content may have been added/changed and when it is crawled. In addition to this, there are settings within SharePoint that can exclude SharePoint document libraries (and even entire SharePoint sites) from being crawled and therefore are not included in the search index. This has a direct impact on the effectiveness of DLP.
Additionally, for domain-joined machines, the Office 2016 programs have a local synced copy of the DLP policy store that is updated every 24 hours. As information workers are in the client programs, content is constantly being checked against the local DLP policy and violations will be detected real-time. This of course assumes they have the most up-to-date policy synced to their machine. As additions/changes are made to the central DLP policy store, there may be a time period when the local Office client is unaware of it.
Local synced policy is stored here:
Imagine a Contoso employee created a document with content identified as being confidential in nature by the Contoso protection control described above OR they modified a document that didn’t originally contain that information, but now did. If they are working in Word/Excel/PowerPoint either Online or 2016 client versions, the DLP policy is constantly being checked and, assuming they have the most up-to-date policy deployed locally, the sensitive content will be detected. All is good.
If, however, either of these conditions exist and they decide to share this confidential document to an external email address, it will not be protected by DLP and they would be allowed to share it externally:
- the document library they are working in or the site they are working on has been configured so it is not included in search (i.e. not being crawled)
- the employee is working in the Office client but the local synced DLP policy is not up-to-date (default 1/day) and does not include the policy to protect this content.
Protecting a confidential document using AIP only
At Contoso, an AIP label is configured called Confidential. This label is not automated, but should be selected for any document containing a credit card number, customer number or personally identifiable information. This label is configured to prevent copying and forwarding (reference: Configuring usage rights for Azure Rights Management). Available custom permission levels are in the image.
We also have AIP configured so an email message will automatically get the label that matches the highest classification of all attachments. We do this so if a Confidential document is attached to an email, the entire email is considered Confidential.
Imagine a Contoso employee created a document with content identified as being confidential in nature by the protection control described above. For the SharePoint site the end-user is working in, you may be relying on the end-user to know the document contains sensitive content so they choose the correct AIP label. Although you can have a default label for all documents, it may be less restrictive that what it should be for this document.
Note: You can have automatic AIP labeling configured to automatically set the Confidential label if credit card number, Customer Number or Personally Identifiable Numbers were found, however it requires an AIP P2 plan. You can also require an end-user to provide justification before downgrading a sensitivity label.
Whether an AIP label is automatically applied or not, if an information worker is allowed to override the label and chooses intentionally or otherwise to (incorrectly) label the document with a less restrictive label – one that allows the document to be externally shared, a data breach can happen.
This is the fine line we all walk balancing usability with security. We need to protect sensitive data but we don’t want to impede information workers from doing their work. This is one of the most challenging aspects of implementing data protection controls across an organization.
Protecting a confidential document using both DLP and AIP
Imagine the same scenario described above but with both DLP and AIP configured – the risk is greatly reduced. Here’s the setup:
- Add a Confidential AIP label that when applied would prevent forwarding and copying.
- Publish the AIP label as part of your Global policy to all locations in your tenant.
- Define a DLP policy for all Exchange, SharePoint and OneDrive locations.
- Configure several DLP rules within the policy in this priority order:
- Priority 1: prevent external sharing for content with the Confidential AIP label
- Priority 2: prevent external sharing for content detected with sensitive information identified in the protection control
- Ensure all locations are being crawled across your tenant.
You are still relying on the correct AIP label to be applied to protect the document. If, however, the correct label hasn’t been applied, the second DLP rule will fire to detect the sensitive content and prevent the data breach from happening.
Takeaway 1: If you can, configure both DLP and AIP to implement the protection controls in your organization to reduce the risk of an inadvertent data breach.
Takeaway 2: You need to balance usability and security. Sometimes there is a legitimate need for an information worker to downgrade a classification setting. To accommodate this, configure the AIP policy to require the end-user to provide justification to set a lower classification, remove a label or remove protection and then allow it to happen. Also, recommend labels where you can.
Takeaway 3: If you are excluding SharePoint content from being crawled, know the data protection risk of doing so.
Takeaway 4: Educate information workers on the importance of correctly classifying documents and why it’s important. They need to understand the meaning of their organization’s classification labels and when to use one over the other. Refer to my blog post, O365 Data Protection: Information Worker Adoption, where I talk about a “Data Protection Center” to provide training and guidance for the Information Worker – in my opinion, a must-have for the digital workplace.
Remember, protection is only as good as the weakest link.
Thanks for reading.