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.
Credit: Photo by Marl Clevenger on Unsplash
Nice piece. I’m just looking at exactly this issue (part of our planning phase).
Great article. We are at the stage of planning AIP / DLP in preparation for GDPR. Using AIP to label and protect Office documents does not work when the recepient is using Word Online. The assumption Microsoft is having here is that every recepient of an AIP labled and protected document will have the desktop version of Word. In my specific scenario, we might send such documents to our Governors who only have the Cloud licenses and not Office 365ProPlus.
AIP capabilities for the Office Online suite is on the roadmap and preview should start in 2018H1. That should address scenarios like the one you describe.
That is good to know. Will make it easier for me to convince management. Thank you for replying so quickly.
Nice overview, Joanne. I was reading into this matter and your article was a great help. A question: will it be possible to report back all denied actions if enforced so by policies (e.g. copying of content etc) and then analyse this info to see how the employee base behaves in general when it comes to information protection ?
Very helpful in making me understand how these two can work together. In your example of using both DLP and AIP you suggest to create several DLP rules and one to prevent sharing for content with the confidential AIP label. Is it fair to assume that would be a sensitivity label?
If so then how would this relate to Microsoft’s statement on DLP: “Note that you can currently use only a retention label as a condition, not a sensitivity label. We’re currently working on support for using a sensitivity label in this condition.” If that would be true then how to apply an AIP sensitivity label?
Hi Piet, it’s only available via PowerShell at this time (or last time I checked), however a retention label can be configured in a DLP rule thru the GUI. Here’s a link to another post of mine where I show how to configure an AIP (sensitivity) label as a rule in DLP using PowerShell.
Very good article. I have deployed RMS On-Prem and within Azure IP and this is a really good summary of what it is and how it works with each other, thanks for the summary. I like it.
Very good overview. Information shared in crisp and clear ways, especially explanation with the support of examples
Big thanks on that article. Helped me a lot.
Hello, I have benefited from your article so thank you. I would be very glad if you could answer a question that is not very relevant to this article.
Is it possible to integrate Titus with Azure RMS? The classification should Titus, the protection is Azure RMS.
Hi Baybars, I’ve never heard of Titus so I can’t help you out.
Thank you for your feedback and kindness.
Have a great day!
Hi – Yes Titus can be integrated with RMS. Alternatively the company who own Titus (HelpSystems) have their own best of breed Rights Management solution called Vera which has a very strong integration.