Posted by Reading time: 10 minutes
Sensitivity labels are able to disable the option to print and/or export a document, thus protecting the sensitive content. But what if an user simply uses <CTRL><P> in the browser and we cannot use Endpoint DLP?
What’s the scenario?
Some time ago I came across a very interesting scenario at one of our clients. In the meantime, I’ve had some time to think this over more closely. So time to share my thoughts.
The scenario is relatively simple. A document portal based on SharePoint Online is used to present documents to guest users. Because of the sensitive nature of the information in these documents, the documents are not to be downloaded, nor printed. Also, copy/paste actions are not allowed. And as an additional bonus-requirement: even the print-actions from the browser <CTRL><P> are not allowed.
This bonus-requirement is interesting. People might still be able to exfiltrate information by simply printing the webpage, either to paper or PDF. It’s a standard component for any web-browser, right?
For example: a sensitive Word document (labeled) in Google Chrome.
What are the options?
So, what do we have as options for these requirements?
As the client uses Microsoft E5 licenses, so there is not much in the way of limitations. But some options are disqualified right away. For example: Endpoint DLP. Endpoint DLP allows us to monitor and even restrict specific actions that will meet the requirement. Yeah!
But this will not solve our problems. The reason is simple: endpoint DLP requires the devices to be onboarded to either Microsoft Purview or Microsoft Defender for Endpoint. And this might be helpful for our internal employees, this will not work for our guests. To be fair: we don’t have any insights or control over the devices our guest use to access the documents.
Sensitivity labels on the container level
Setting a sensitivity label on the SharePoint Online site might solve the problem. The label has the option to control access from an unmanaged device. As we can assume that our guest-users are using devices that we do not manage, this will be an great option.
Also, this option is not limited to sensitivity labels. The conditional access rules used by the label can also be applied to specific SharePoint Online sites using PowerShell. The settings in the label offer the required features: disable download, print or sync files. So this is the one? Not entirely – remember the bonus-requirement? This setting will not block those pesky guests from using <CTRL<P> to save or print the sensitive content.
Sensitivity labels on the documents
Now we are working with sensitivity labels, why not look at labels on the item (document) level? When combined with the labels on the container level, this might we a working solution. A sensitivity label applied to a document will block copy/paste and print actions . When a document is opened in the Microsoft 365 app, the label will even block any screenshots.
But there is one very important requirement for these permissions to work: a Microsoft account. In order for the permissions to be applied and the encryption on the documents to work, Microsoft accounts are used. These can be Entra ID accounts, Microsoft Live accounts or dedicated Microsoft RMS accounts. So, in our scenario, we would need to make sure that our guests have such an account. One way to achieve this, is to invite these guest to the tenant and to create dedicated guest-account in Entra ID. But this was deemed to be cumbersome. So, time to look at the next alternative.
Microsoft Defender for Cloud Apps (MDfCA)
When an enterprise has the option to use Microsoft 365 E5 or equivalent licenses, do not hesitate to look into and use this platform. One great advantage of MDfCA is the ability to act on activities based on content and session inspection. And it is this ability which will solve our bonus-requirement.
Using Entra ID Conditional Access rules, we can have sessions to/from SharePoint Online be monitored by MDfCA. And as these CA rules can be applied to specific user(groups), we can apply them to our guest users.
When these users access the SharePoint Online site, they will be greeted with an information screen. Btw: you can configure MDfCA to either display this or not. And you can modify the message, as seen below.
In our scenario, we are going to need to Session based policies. One policy will look at the copy/paste and printing actions, while the other will look at any downloads. The printing actions will be disabled and when the user still tries to print (using <CTRL><P>), this will be blocked.
Using<CTRL><P> will not get you anywhere…
The download option is based on a build-in session policy. The user will see a message and a .txt-file will be downloaded.
So, how does this work?
Setting up the policy
Let’s focus on the policy to block printing first. This is a session policy in MDfCA. The most simple example is to block these activities when they occur in SharePoint Online and when the user comes from an unmanaged device.
In order for this to work, we also need an Entra ID Conditional Access policy (see screenshot above). By the way, I just noticed that Entra ID CA now has Insider risk as a condition as-well. Cool!!
Are we done?
You can use the sensitivity label on the SharePoint Online site to block most of the unwanted action and use the MDfCA policy for the bonus-requirement. But this policy does have one snag; Although you can scope the Entra ID CA rule to specific users, you cannot scope this to specific sites. Which means, that for all our guest users in the CA rule, this policy will act on all SharePoint Online sites.
But there is a way to get around this.
Authentication Context
Let’s say we want to use only MDfCA and only for specific SharePoint Online sites. So we want to block downloads and prevent any copy/paste or printing. We will need to set-up two session based policies for this in MDfCA. And when we setup the Entra ID CA policy, both these policies will be applied.
But, again, these will be applied for all SharePoint Online sites.
Authentication Context may solve this. We can set the conditional access rules for a SharePoint Online site (either by using a sensitivity label or by using PowerShell) to use a Authentication Context. This way, we only add the specific SharePoint Online sites we need.
In Entra ID Conditional Access, we configure the rule to act on this specific Authentication Context.
And that’s how this works.
Solves any problem?
People sometimes ask me if there is a way to stop users from taking photos of sensitive data or to restrict taking screenshots. For the latter, you will need to use sensitivity labels on the document level and force these documents to be opened in the relevant Microsoft 365 app.
Taking photos? Aside from using watermarks and the relevant Microsoft 365 app, there is no way to stop people from taking a photo of a document if they are allowed to open this. Watermarks and other visuals markings (https://learn.microsoft.com/en-us/purview/sensitivity-labels-office-apps#dynamic-markings-with-variables) might deter this type of behavior. But – alas – this only works in the Microsoft 365 Apps, so you will need to force opening these documents there.
But there it is. MDfCA was able to address the requirements.
Information security and compliance 
Great article, as always!
You mentioned a scenario where Sensitivity Labels (encryption) weren’t used because there’s a need for dedicated Entra ID Guest Accounts for those without a Microsoft Account. I’m curious, how did you manage to assign the CA Policy to route the session over to MDCA?
The authentication context with sensitivity labelling can be helpful in some cases, but cannot support some more complex use cases, e.g. when forwarding multiple CA policies to MDCA. In my opinion, we need the feature to filter based on the authentication context within the session policy in MDCA itself or to assign the session policy directly in in CA.
Thank you Bilel!
Great question 🙂 The guest-users in this scenario received a specific and generic portal-account for access. Setting them up with individual guest-accounts would have been possible. But when opening a document using the M365 App, using the MIP encryption, would require them to login to the app using that account. And this we cannot control or ask of the users.
I agree that we need that feature. Although in the MDfCA you can set a condition in the policy to only work for specific users. But that requires more administration of the policies. On the auth.context: we didn’t use this (yet) in the scenario, but I’m very interested in this concept. That’s why I included this 🙂