App governance and sensitive information

Reading time: 5 minutes

How does Microsoft Defender for Cloud Apps relate to sensitive information and oAuth applications attempting to access these?

What’s this all about?

Microsoft Defender for Cloud Apps [MDCA] is a powerful component in the Microsoft Defender suite of platforms. As a Cloud Security Access Broker or CASB, it allows you to discover and control the use of Shadow IT, protect sensitive information (including preventing data leaks), and protect against cyber threats.

In this blog I want to focus on one aspect of MDCA: App Governance and how this relates to information protection. There is more than meets the eye in this.

Microsoft Defender for Cloud Apps

As a platform, MDCA goes beyond the capabilities of Microsoft Purview. For one, the platform is able to extend the information protection features to non-Microsoft SaaS environments. As the platform looks at the sessions going to/from the cloud platform, it lets you detect sensitive information flow in real time. MDCA also enhances the detection of sensitive information by adding specific searchable properties of the content. For example Mime-type.

By detecting unusual behavior across cloud apps, risks to the organization are minimized. Ransomware detection is one of the unique aspects of the platform. Cloud apps can also be accessed based on regulatory compliance and industry standards.

Getting there

Before I delve into aspects like licensing and the app governance parts, let’s talk about getting to MDCA. The classic option is to go to the Defender for Cloud Apps dashboard, which can be found at https://<tenant-name>.portal.cloudappsecurity.com/#/dashboard.

Some time ago, Microsoft enabled the Security portal for accessing the MDCA functions. So now you can also go to https://security.microsoft.com/cloudapps. And this is also the only way to reach the app governance (https://security.microsoft.com/cloudapps/app-governance) functions. I would recommend using this portal.

Licensing

But first…..

It’s good to note that MDCA is a separate component within the Microsoft Defender suite and as such has different licensing requirements. Let’s approach this from the Microsoft 365 perspective; Detecting cloud apps is part of both the Microsoft 365 E3 and E5 license and Enterprise Mobility & Security [EMS] E3/E5. In other words, this basic function is available for you right away when you are using Microsoft 365.

If you want to use the detection and protection components of the platform, you have two choices. The Office 365 workloads are part of the Office 365 Cloud App Security license, which is part of either Office 365 E5, EMS E5, Microsoft 365 E5 Security, or Microsoft 365 E5 Compliance.

If you need all the functions of the platform, including extending this to non-Microsoft SaaS environments, then you will need either Microsoft 365 E5, EMS E5, Microsoft 365 E5 Security, or Microsoft 365 E5 Compliance.

Please note that App Governance is an add-on to MDCA and requires a separate license to use.

Detecting and protecting cloud apps

From the Cloud Discovery page of MDCA, an administrator has an overview of all cloud apps that are in use within the organization. These apps are discovered by analyzing firewalls and/or Microsoft Defender for Endpoint logging. It allows the administrator to detect “rogue” applications – sometimes referred to as Shadow IT.

In addition to this, MDCA offers a cloud app catalog of more than 31.000 SaaS apps (the figure above is somewhat older) which you can use to check the security posture and risk level of a SaaS application. You can also tag the app as sanctioned (allow) or unsanctioned. A tag that can be used in detection and protection policies. For example:

A specific component of MDCA is the overview of oAuth applications. These types of applications have been known for use in ransomware or other attack scenarios. So having an overview as this is valuable. It also directly relates to the component of App Governance.

App Governance

This add-on feature to MCDA called App Governance was introduced in a public preview on Juli 14th, 2021. The feature is designed for managing and securing oAuth-enabled applications that are registered in the tenant’s Azure Active Directory. So, to be clear, the features will not be applicable to any other sanctioned SaaS applications.

App governance allows an administrator to monitor and set additional policies for the oAuth applications. The dashboard contains the option to display the relevant oAuth applications, see any created alerts and create policies to monitor the applications.

The Apps overview shows you all the registered oAuth applications, with the following metadata:

App status: Enabled | Disabled
API access: Graph | Non-Graph
Privilege level: High | Medium | Low | Na
Permission usage: Is use | Some unused | na
Permission type: Application | Delegated | Mixed
Publisher verified: Yes | No
Services access: The cloud services, for example, SharePoint or Teams
Sensitivity labels accessed: Microsoft Purview Information Protection labels.

The last one really caught my eye. So let’s take a closer look. When selecting an application, this information is shown in more detail.

In the October 2022 release, Microsoft added specific insights and policies for apps that access content with Microsoft Purview Information Protection labels attached. And this is great news. It now allows you to prevent certain apps from accessing your most sensitive information when this has been labeled. You can even automatically deactivate applications when needed.

So let’s take a look at the policies for this.

Policies

App governance comes with a set of pre-defined policies. You can choose to use these, edit them, or create your own. When creating your own policy, are assisted by pre-formed templates. These templates come with built-in settings.

Usage: Unused app, Increase in use, New app with high data usage;
Permissions: Unused credentials, Overprivileged app, New app with non-Graph API permissions, New highly privileged app, Expiring credentials;
Certification: New uncertified app;
Activity: Access to sensitive data.

When selecting the Activity template, this predefined policy will act on any cloud services and any sensitivity label.

Other components of the policy include the severity (High, Medium, and Low), the ability to disable the app when the policy is triggered, and the status (Audit mode, Active and Inactive).

During the policy creation process, you can modify the default settings. This is also the case when creating a custom policy. And this is the option to specify the specific sensitivity of the data accessed. So let’s go through the options.

Custom policy

The policy can be set to act on specific applications. By default, these are all oAuth (registered) applications, but you can either select specific ones or exempt specific ones. Next, you’ll be able to set the policy conditions. And here you have a wide range of options.

For example: is the app overprivileged? Or is the publisher verified? Has the app been given consent by priority users? The latter one is relatively new and allows administrators to designate specific (VIP) users within the tenant as “priority account” or “priority users”. More information on this: https://learn.microsoft.com/en-us/microsoft-365/admin/setup/priority-accounts?view=o365-worldwide

For detecting oAuth applications that are accessing sensitivity labels, you can select this relevant option. Which in turn will display the list of Microsoft Purview Information Protection labels. This is great stuff!

Play around with these options, there are many possibilities. For example:

Based on your risk assessment and risk appetite, you can either use warnings/alerts when an oAuth app is accessing sensitive content or you can just block the app directly. The alerts can be found in the Security portal, under Incidents & alerts.

That’s it.

I hope this article was helpful. Here’s more information on App Governance: https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-manage-app-governance