Use Conditional Access and MDA Session Policies to Block Downloading of Sensitive Data with Authentication Context

I have been amazed by the features in Microsoft Purview that help protect and govern data and how Purview integrates seamlessly with other Microsoft security services.

I would like to demonstrate a solution to a scenario I have fabricated as a means to illustrate how awesome these features in Purview and Entra ID are and how they can integrate together and create comprehensive data protection solutions and hopefully spark ideas of your own for improvements in your own organization. Again, this is by no means a solution ready for production but more a fun way to demonstrate how powerful these features are.

Scenario:

So, you've got your critical data migrated from your file server on-prem to SharePoint and your data is no longer sitting on a file server behind a firewall.

You followed best practice and all of your data is spread out among many SharePoint sites (Flat Architecture: See SharePoint Maven's article on this topic here).

There was an ongoing project when the file server migration happened called Project Falcon and with the new flat file structure, you have data related to this project in several sites.

You only want this data to be downloaded on Intune managed devices.

• How can I know where this data is?
• How can we control the interaction with this data on a particular SharePoint site?
• How can we block downloading of data with specific Sensitive Information Types on devices that are not managed?

Solution:

We can use MDA (Microsoft Defender for Apps) as a CASB (Cloud Access Security Broker) to control the interaction of data. We can then leverage Authentication Contexts and Conditional Access Policies to apply these controls to a single SharePoint site and in effect, implement Conditional Access App Control. I will demonstrate the following:

• Create a Sensitivity label and label policy (will write about these in the future)
• Create Authentication Context and link to SharePoint site
• Create Conditional Access Policy (Session policy)
• Ensure Azure is connected to MDA
• Create Session Policy in MDA

Create an Authentication Context

We're going to use an AC (Authentication Context) linked to our particular SharePoint site to a specific Conditional Access Policy that will be a building block for our CASB component of this solution.

• Log into Entra ID and on the left side menu, select the Protection --> Conditional Access blade.

• Give your AC a name, description, select an ID and ensure you select the checkbox to "Publish to apps..." and click save.

• Click on the "Authentication contexts" tab to see your newly create AC:

Create a Conditional Access App Control Policy using Conditional Access Policies (CASB)

Now let's create a CA Policy that targets our AC we created.

• Go to Conditional Access under the Protection blade and select

• Give your policy a name and then under Users, select a a group or All users. Under "Target resources", select "Authentication contexts" from the drop down and then select the checkbox next to our newly created AC.

• You can select any conditions you'd like that suit your needs. For my example here, I would like ALL traffic to the site with highly confidential Project Falcon data to be brokered via MDA.
• Under Access Controls, select Session and then select the check box for "Use Conditional Access App Control" and in the drop down, select "Use custom policy.."

• Click create

Link Authentication Context to a SharePoint Site

When I check the ConditionalAccessPolicy property of my SharePoint site, the value is "AllFullAccess". This simply means I do not have a Conditional Access Policy applied to this site. Let's do that now by linking our AC we created earlier to our site that has the Project Falcon highly confidential data.

Get-SPOSite https://mycompany.sharepoint.com/sites/RetailOperations | Fl *Conditional*


ConditionalAccessPolicy : AllowFullAccess        

• Connect to SharePoint via PowerShell (See how to install and connect to the SharePoint PowerShell module here)
• Run the following command to link your AC to your SharePoint site while obviously change the name of the AC to that which you created in your environment:

Set-SPOSite -Identity "https://mycompany.sharepoint.com/sites/RetailOperations" -ConditionalAccessPolicy AuthenticationContext -AuthenticationContextName "ProjectFalcon"        

• Run the same "Get-SPOSite" command to check the new value for the ConditionalAccessPolicy property is "AuthenticationContext":

We have now linked our AC to our SharePoint site

Creating a Session Policy in MDA

Now, if this is the first time creating a CA policy with Conditional Access App Control configurations, when you go to create your session policy in MDA, you will see a note stating "You don't have any apps deployed with Conditional Access App Control. Go to Conditional Access App Control page to deploy an app". Everything will also be greyed out and you will not be able to create the policy.

This is mainly for other 3rd party SaaS apps that you would like to connect with MDA for Conditional Access App Control but for Office apps (including SharePoint), we simply need to create a CA policy with the Session control settings configured. Because our SharePoint site with Project Falcon data has an AC linked to it and that AC is configured in the CA policy, SharePoint will eventually appear in MDA as a Conditional Access App. We could have also targeted "Cloud Apps" in the Conditional Access Policy but instead, we used our AC (ProjectFalcon).

Let's create our session policy:

• Log into Microsoft Defender XDR (formerly M365 Defender) and navigate to Cloud apps --> Policies --> Policy management

• Click on "+Create policy" and then select Session policy

• Click the dropdown under Policy template, and select "Block download based on real-time content inspection" and select "Apply template"

• Make sure to modify the Policy name as the field will automatically populate with the name of the policy template
• For the "Session control type" drop down, select "Control file download (with inspection).
• Under Activity Source, select the filters that will trigger this policy. For our fabricated scenario here, we don't want users to be able to download sensitive project falcon data from non-Intune managed devices. My filter is setup so "Device Tag does not equal Intune Compliant"

• Under the "Files matching all of the following" filters section, I configure mine to scope to data with my custom Sensitive Information Type label. Set the action to Block and add a custom message for your end user's so they know why their action is being blocked:

• Click Create

Testing/Validating

You will know your session is being proxied via Defender for Apps because the Top Level Domain will be appended with "mcas.ms" :

Downloading From non-Intune Device

When the user attempts to download the file that has the highly confidential, project falcon Sensitivity label applied to it, the action is blocked and the user is displayed the block message:

A .txt file is downloaded instead which contains information about the file attempting to be downloaded along with the same block message.

Downloading From Intune Managed Device

When the user logs into their Intune managed corporate device using their Edge browser, they're authorized to download the file with highly sensitive data