Using Microsoft Defender for Cloud Apps to Secure Access for Remote Workers

If the last few years have proven anything, it’s that hybrid working is here to stay, and the traditional office-based model is no longer the standard. However, adopting new ways of working raise challenges for organizations who need to provide secure access suitable for an environment where people work on home networks or personal devices.

Many ways exist to address this challenge using technologies like VPNs or VDI environments, and each comes with its own level of complexity and usability. For Microsoft 365 customers, Microsoft Defender for Cloud Apps is a solution that is easily deployed.

What is Microsoft Defender for Cloud Apps?

Microsoft Defender for Cloud Apps (MDCA), previously known as Microsoft Cloud App Security, is a Cloud Access Security Broker (CASB). It sits between your users and your cloud apps to provide visibility, protection, and compliance in the cloud where traditional methods like firewalls may not be practical.

There are many ways you can utilize MDCA, from monitoring and preventing data leaks to providing valuable insights into what’s happening in your cloud service. In this article, I explore how MDCA can help secure common remote access scenarios using Conditional Access App Control Policies.

Licensing for MDCA

Full licensing details for MDCA are available online, but at a high level, three different SKUs for MDCA are available (excluding the US Government offerings):

• The entry level Azure AD Cloud App Discovery comes with an Azure AD Premium P1 subscription and only supports the Cloud App Discovery functionality; however, It doesn’t cover the App Control aspects described here.
• The next step up is Office 365 Cloud App Security, which includes Conditional Access App Control for Office 365 apps only – as this SKU is part of Office 365 E5. Additionally, an Azure AD Premium P1 subscription is required to configure Azure AD Conditional Access policies used for app control.
• The complete Microsoft Defender for Cloud Apps product comes with all the bells and whistles for MDCA, including expanding app controls to any cloud or on-premises app. MDCA can be purchased as a separate subscription or as part of Enterprise Mobility + Security E5 or Microsoft 365 E5.

How does App Control work?

Conditional Access App Control works by proxying user connections to cloud apps (provided Azure AD is used for authentication) through the MDCA service, and then monitoring connections and applying policies to user sessions in real time. Because connections are proxied, rather than direct to the app, the policies defined can control – at a granular level – the functionality delivered to the end user.

Keep in mind that app control only works for web sessions, so if you want to ensure your cloud apps are secured, you might want to block desktop and mobile apps or manage them by using Endpoint Manager or other means.

Configuring Conditional Access Policies

To leverage app control, an app must authenticate via Azure AD. For Office 365 this already happens, but any third-party apps (for example Dropbox or Salesforce) must be set up for Azure AD SSO. Once the app supports integrated authentication with Azure AD, it becomes available in Conditional Access to route to MDCA.

To configure Conditional Access, create a new CA policy to target users (everyone in the tenant or just a selected set) and the app you want to control (in this case, Office 365). The policy can be customized with further conditions such as locations or device states to meet specific requirements. There’s no need to configure any grant controls but under the session section, enable the option to Use Conditional Access App Control as shown in Figure 1:

For an app to become available within MDCA, at least one connection must be routed from Conditional Access. You’ll want to target this policy at a test user and sign into an Office 365 app such as OWA. After signing in, users see a message (Figure 2) to let them know their connection is being monitored. This message can be disabled in the MDCA settings under Conditional Access App Control -> User Monitoring.

After clicking continue, users will see the web app appear as normal, but checking the URL shows that the connection is going to the MDCA endpoint (Figure 3):

Creating a Session policy

Session policies in MDCA define the controls implemented on user sessions when they are proxied. Blocking file download based on content is a basic example where a session policy can help secure users working from home. To configure this policy, create a new session policy from the Control -> Policies page.

You can configure a policy from scratch, but I find it easier to use one of the predefined templates found under Policy template and to just modify the policy settings to make the necessary changes. Applying the Block download based on real-time content inspection template will prepopulate the policy with most of what’s needed.

The first thing to note is the activity filter, which excludes Intune Compliant and Hybrid Azure AD joined devices. To filter even further, the Office 365 app can be added as an app filter as shown in Figure 4. Session policies are supported for the following Office 365 apps:

• Exchange Online
• OneDrive for Business
• Power BI
• SharePoint Online
• Microsoft Teams (preview)
• Yammer (preview)

Next, the type of data you would like to be blocked must be defined in the Inspection method section of the policy. In Figure 5, I configured the policy to trigger based on data containing at least one credit card number (using the sensitive information type available in the tenant):

In the Actions section, the outcome of the policy is defined. The policy can be configured to test, block, or protect data. The protect option supports the assignment of a selected sensitivity label when a file is downloaded – this won’t assign the label to the file in SharePoint/OneDrive. Access to the downloaded file is then governed by the rights defined on the label.

This option allows users to continue downloading files while ensuring that the copy of the file on the end user’s device is protected appropriately. In Figure 6, I configured the policy to block the download attempt and chose to also block the download of files that cannot be scanned:

Before saving the policy, administrators can configure alerting and Power Automate playbooks to run when the policy is matched. About 15 minutes after the policy is configured, when users attempt to download files that match the criteria from unmanaged devices, they will be blocked and informed (Figure 7):

Other use cases

The example above is a very simple (although quite common) scenario. However, session policies are very flexible and can be configured to meet many different requirements. Some examples of other useful session policies are:

• Block all downloads on personal devices
• Block uploads on personal devices
• Limit certain users to “read only” web access to apps
• Prevent cut, copy, and paste of sensitive data
• Prevent users from sending messages or emails

Summary

Utilizing Microsoft Defender for App Control is no doubt an excellent way to secure remote workers, and by expanding it beyond Office 365 to encompass third-party cloud apps it can bring a level of control and governance over those that don’t have similar controls built in natively.