Tech Guide: Microsoft Defender for Cloud Apps - DLP Policies
A Quickstart guide to implementing DLP policies to protect content in M365 apps
Microsoft Defender for Cloud Apps
The Microsoft Defender for Cloud Apps or MDCA offers powerful DLP capabilities as part of it’s CASB offering, especially if your organization owns E5 licenses and uses AzureAD Conditional Access Policies . Previously known as Microsoft for Cloud App Security ior MCAS, this CASB capability works closely with the DLP capability of Microsoft Information Protection to protect data in cloud apps. By bringing the solution under the Defender umbrella of products, all of the settings and policies can now be managed in the Microsoft Security Portal . The guide will walk you through getting started with some basic DLP policies.
Concepts
MDCA works by leveraging a reverse proxy between the cloud app that is being secured and the user. TThis enables MDCA to provide real-time DLP and Session controls on the cloud app. Since all data travels over the proxied connection, MDCA gets visibility into all information passing between the user device and the cloud app. This is evidenced by the change in the domain. As shown below, any protected cloud app will be routed through “mcas.ms” and will be shown as a subdomain of this domain. Eg: For Outlook, the original URL which is “outlook.office.com” will appear as “outlook.office.com.mcas.ms”
This means to work with MDCA, you must enable “session control” using Conditional Access application control with AzureAD Conditional Access Policy (CAP). Thus using conditional access, you can direct users under specific scenarios through the MDCA reverse proxy, rather than routing everyone through it. Some common scenarios to consider are
- User or Device shows a high risk -> Use MDCA to monitor all traffic to and from the cloud app
- User is access cloud app from an unmanaged device (Eg: not Azure joined) -> Use MDCA to block any file download, while allowing user to work on the online version of the file, or encrypt the file upon download.
- Third-party user is accessing a high value cloud app -> Use MDCA to detect and prevent copy/paste/print of sensitive info types such as Credit Card numbers
Thus the CAP determines the conditions under which data should be protected, while the MDCA Policies determine the action based on certain conditions about the data, user and device.
Prerequisites
As mentioned earlier, the first prerequisite is to use AAD CAP to route user via the MDCA reverse proxy. By selecting the “Office 365” app under “Cloud apps or action” and selecting “Use Conditional Access App Control” with the “Use custom policy…” setting, all the Office 365 apps will be brought under MDCA protection. You may apply additional conditions to define the conditions under which this policy should come into effect.
The other requirement before a policy can even be defined is to have MDCA detect the cloud app. This occurs when at least one user logs in to the protected cloud app and the user is routed via the reverse proxy due to the Conditional Access application Control setting. When this first login occurs, the applications will appear in the Conditional Access App Control apps
section of the Security portal (found under Settings -> Connected apps menu). Without any apps added to this section, you may see the error below when trying to define a DLP policy.
There are additional requirements that are detailed here . Once these prerequisites have been met, we can proceed with creating our first few DLP policies.
Understanding DLP Policies using Session Control
To create a new policy, navigate to the Policy Management section of Cloud Apps , click on “Create policy” and choose “Session Policy” from the dropdown. Note that you must have the appropriate role to create and manage Cloud App Policies.
You may opt to create a policy from scratch, or use prebuilt templates to create the policy. The prebuilt templates are a good starting point and have some good options to get started with controls for cloud app protection.
Otherwise, building a policy from scratch is also a good way to get granular controls. A Session policy has the following main components (ignoring the basics like name and description)
Session control type
The session control type determines what type of control will be applied to that session. The options available are shown below. Depending on the option selected, there will be additional options that appear.
- Monitor only is the most basic option, offering logging of all activity on the cloud app. There are no additional options to configure.
- Block activities, as the name suggests, offer blocking controls. This should be applied with an “Activity Type” under the “Activity Source” setting. By filtering on these activities the block control will apply on them. Available activity types are
- Cut/Copy item
- Paste item
- Send item
- Control file download (with inspection) enables controls on download of files. This control has a filter option for matching files. The filter options available are
- Extension
- File name (works with regex)
- File size (MB) with lt,gt and “in between” options
- Sensitivity Label -> This is a powerful capability to scope down controls on documents of a specific sensitive type. Eg: You may choose to only apply controls on Confidential documents. Note that you must have sensitivity labels created and published via label policy in the Compliance portal under Information Protection for the labels to appear in MDCA.
In addition to the filters above, there are content inspection options available under “Inspection method”. The options available are
- None -> No content inspection will take PolicyTemplates
- Built-in DLP -> Enables content inspection and has the following sub options
- Include files that match a present expression -> Uses prebuilt matching based on some common data types such as Email address, Credit Card Numbers, SWIFT code, Passport numbers along with some country specific data PII types for US, CA and UK. There is an option available to ignore context which will lead to higher false positives but lower false negatives.
- Include files that match a custom expression -> Allows you to specify custom expressions to search for in the contents. Also offers the option to exclude certain files based on content.
- Advanced Settings -> Allow setting the option to perform content search in the Content, Metadata and File name. It also offers the option to unmask 4 characters of a match, which is completely masked by default.
After the filters are defined, the next section is the Actions section. This section has options to
- Test -> only monitors activity and does not apply an action
- Block -> Blocks the download of files as defined in filters above. Also has options for notification by email and a custom block message (examples shown later in this article).
- Protect -> Offers the option to protect the files before download. TThis can be either to
- Apply label -> Apply sensitivity label to the downloaded file (useful for third-party endpoint DLP products)
- Apply custom permissions… -> Enables setting of custom permission by encrypting the file. Useful for enabling download of sensitive documents to unmanaged devices. You can effectively tie the file to the user’s identity before download.
- Always apply the selected action… -> TThere are several scenarios where content inspection may not work. This option applies the action in such cases.
Finally after the Actions section is the Alerts section. As the name suggests, this section deals with creating alerts when a policy match occurs. The alerts will be generated in the Security portal, but can also be sent via email or trigger a Power Automate playbook for SOAR type of actions.
Example DLP Policies
Now begins the fun part. Creating policies that actually do something. Here are some starter policies that can help understand and test the DLP capabilities in MDCA
Block Sending of Chat containing sensitive info
This policy as shown below uses content inspection to check for Credit Card numbers and prevents the content from being sent via Teams chat.
When this policy is enforced in Teams chat, the user will see the “Failed to send” message in the chat
In addition, a popup will appear which shows the customized message from the policy.
Block download of file based on sensitivity label
This policy filters the file based on the Sensitivity Label and blocks downloads of Confidential labelled files. Ideally, this policy would be used in conjunction with a device check such that downloads are blocked on untrusted/unmanaged devices.
The popup will appear similar to the case above but with the message as customized for this policy.
These policy matches or violations are also recorded in the app activity logs and if configured, will also be records as alerts.
Known Limitations
TThe MDCA reverse proxy is not foolproof and there are conditions under which it can be bypassed. These are documented here along with other limitations. Thus it is important to add compensating controls depending on the level of protection required.
Suggested Reading
https://learn.microsoft.com/en-gb/defender-cloud-apps/proxy-intro-aad
https://learn.microsoft.com/en-us/defender-cloud-apps/editions-cloud-app-security-o365
https://learn.microsoft.com/en-us/defender-cloud-apps/session-policy-aad
https://learn.microsoft.com/en-us/defender-cloud-apps/troubleshooting-proxy