In the last year, I wrote three blog posts related to Microsoft Cloud App Security (MCAS) monitoring part. In those posts I haven’t touched the activity part (blocking) yet, that’s still to come.

The posts were:

I was fortunate to have the possibility to evaluate Cloud App Security in customer cases during the last year. I really love the MCAS features and capabilities for detecting and monitoring suspicious activities. One of the best sides is native integrations with other Microsoft security products. It has downsides as every security product has but that’s not the topic in this post (one more to come).

What I haven’t touch earlier is integration with Microsoft Defender ATP. This blog post concentrates on it.

Integration

Benefits

Cloud Discovery is part of MCAS and used primarily for seeing shadow IT used by an organization. Description from docs.microsoft.com:

The integration simplifies the rollout of Cloud Discovery, extends Cloud Discovery capabilities beyond corporate network, and enables machine-based investigation. 

Microsoft Cloud App Security uses the traffic information collected by Microsoft Defender ATP about the cloud apps and services being accessed from IT-managed Windows 10 machines. The integration enables you to run Cloud Discovery on any machine in the corporate network, using public wifi, while roaming and over remote access. It also enables a machine-based investigation.

Microsoft Cloud App Security uses the native integration with Microsoft Defender ATP to tap into data about cloud app and service traffic from managed Windows devices. The integration doesn’t require any additional deployment and works out of the box. You don’t need to route or mirror traffic from your endpoints or do complex integration steps.

What’s Needed For The Integration?

In a nutshell, you need:

Configuration

The configuration is made in securitycenter.windows.com (MDATP portal) settings blade. When Microsoft Cloud App Security integration is enabled it pushes the MDATP signals to MCAS and admins can leverage Cloud Discovery solution and visibility to Shadow IT on the MCAS side. Worth to mention is that forwarded data is stored in the same locations as Cloud App Security data.

Note: If you are using Azure ATP, consider making integration with MDATP to get better visibility and additional detections.

If your company policy allows using preview features in production I encourage you to configure preview features to ON state.

Cloud Discovery In Cloud App Security

Let’s have a look at how it looks on the MCAS side and what you can do with the discovered data.

Cloud Discovery Blade

The Cloud Discovery blade shows an overview of how applications are used in the organization. When MDATP is integrated with MCAS, reporting is continuous as you can see from the picture below (Top right corner – Win10 Endpoint Users report). If you have imported firewall logs or are using session controls with MCAS, those ones exist behind the same navigation bar.

Terminology

  • Sanctioned – Approved safe app
  • Unsanctioned – Blocked unwanted app

Note: It might take 2 hours to data be visible in the MCAS portal after integration is made. In my environment, it took 1 hour, so it was pretty fast.

What’s interesting in the picture is the “News and Entertainment” section and Apps headquarters map. I’m not aware that anyone in my organization should use apps that are based in China, what’s the app and who’s using it?

The Investigation

When I jump to the App categories and to the “News and entertainment”

I see which apps are behind the category and what’s the purpose of red color. I can see that there are three (3) apps behind this category:

  • Microsoft MSN
  • Yahoo Webmail
  • Sohu News

Sohu is already blocked in my environment and users should not use it based on security policy. Yahoo, I even didn’t know that someone is using it in my org:) Seeing immediately benefit from Cloud Discovery to find out shadow IT apps.

Microsoft Cloud App Security documentation says: “When the app is unsanctioned in Cloud App Security, it doesn’t block use, but enables monitor its use. You can then notify users of the unsanctioned app and suggest an alternative safe app for their use. The app usage and creates additional policies related to it”.

On the other hand, the same document has the following sentence: “If your tenant uses Microsoft Defender Advanced Threat Protection (ATP), Zscaler NSS, or iboss, any app you mark as unsanctioned is automatically blocked by Cloud App Security”.

I was banging my head to the wall without getting blocked until I found this one, kudos to my colleague @PitkarantaM. MCAS has a new setting available which allows blocking endpoints with the help of the Microsoft Defender ATP.

30 minutes after integration was made I had blocked domains in the “Indicators” blade.

What’s also needed on the Defender ATP side is to enable “Custom network indicators” which allows configuring machines to allow or block connections to IP addresses, domains, or URLs in custom indicators list.

How Blocking Actually Works?

From docs.microsoft.com

Cloud App Security takes advantage of Microsoft Defender ATP Network Protection capabilities to block endpoint device access to cloud apps. You can block apps by tagging them as Unsanctioned in the portal.

Based on the comprehensive usage and risk assessment of each unsanctioned app, the app’s domains are used to create domain indicators in the Microsoft Defender ATP portal. Windows Defender Antivirus, running on endpoint devices, uses the domain indicators to block access to these apps.

Pre-requirements

To have this configured properly you need:

In Defender ATP

  • Cloud App Security integration
  • Custom Network Indicators enabled

Cloud App Security

  • Cloud app control with Microsoft Defender Advanced Threat Protection enabled
  • Cloud Discovery enabled
  • Unsanctioned configuration for unwanted apps in the MCAS

Custom Network Indicators and Other Browsers

I also tried to block sites straight from the MDATP portal and it took approximately an hour after the initial configuration after access to the URL defined was blocked. In both cases, Edge was used.

This block doesn’t work with 3rd party browsers (like Chrome & Mozilla) with Defender Smart Screen and additional configuration is needed. Practically, the network protection from Defender ATP needs to be enabled. More information from here.

In my environment, I did configuration through Powershell to individual devices.

Set-MpPreference -EnableNetworkProtection enable
The outcome when Defender Smart Screen and Network Protection are enabled

Cloud Discovery Policies

MCAS has an extremely good set of built-in policies for Cloud Discovery already available in use. If those don’t exactly match your scenario own ones can be created. Most often I start with the built-in templates and make some customizations before publishing the policy.

New Popular App

In my environment policy named “New Popular App” is configured with the following settings. Policy evaluates Cloud Discovery data and creates an alert if enough users have been taking new app in to use.

  • New “Popular App Policy” template used
  • Policy severity – high
  • No filters applied
  • In template user limit is 500 – I changed this to 3 to get alert sooner
  • Governance – I add a custom tag for such an app if one is detected

Templates available at time of writing (27.12.2019) are:

  • New popular app
  • New high volume app
  • New high upload volume app
  • New risky app
  • Cloud storage app compliance check
  • Collaboration app compliance check
  • CRM app compliance check
  • New cloud storage app
  • New collaboration app
  • New online meeting app
  • New CRM app
  • New HR management app
  • New sales app
  • New code hosting app
  • New vendor management system apps

The Cloud Discovery Alert

After MCAS receives data from Firewall, proxies or Defender ATP it analyzes it and raises alerts if a match is found based on MCAS policies. Below is an alert from a popular app in the Fetads environment.

Summary

I’m quite enthusiastic about MCAS and MDATP integration. Possibility to use Cloud Discovery data adds an additional layer to the solution and makes the security solution more comprehensive than ever. Waiting eagerly my next Cloud App Security project in 2020.

Even blocking apps is possible with Cloud App Security it’s important to evaluate possible use cases and requirements before start blocking applications. One possible use case could be preventing end-users to access malicious URLs.

The cases I have had Cloud App Security have been used mainly for monitoring the internal user’s browser-based traffic. It has capabilities for identifying native clients (and blocking activities) but regarding my experiences, I encourage customers to use other ways to handle native clients, such as Intune & Conditional Access.

Until next time!