Configuring Microsoft Cloud App Security to protect Exchange Online

More than ever before, end users expect flexibility and functionality at work to enable them to work when they want, where they want, and without a limited user experience. However, this challenges traditional IT security controls, such as blocking access from non-corporate machines, or outside the corporate network. Microsoft Enterprise Mobility + Security provides new ways for organisations to meet their users’ increasingly demanding requirements, whilst not compromising on data security.

Microsoft Cloud App Security (MCAS) is included in Enterprise Mobility + Security E5 and builds upon the mobility and security functionality that comes as part of E3, predominantly Intune and Conditional Access.

What is MCAS?

MCAS is Microsoft’s Cloud Access Security Broker solution, which allows you to monitor the cloud applications and services being accessed and adopted by your users, whilst also providing increased protection for data across cloud applications. More simply, using the MCAS Proxy, you can apply deeper more granular control over the data stored in your cloud applications with the least possible impact on your end users.

The monitoring capability, Cloud Discovery, allows you to monitor and identify your own corporate cloud environment as well as evaluate the adoption of non-sanctioned cloud apps your users are utilising, and allow or deny access to these apps. You can use APIs for supported third-party services to monitor and provide governance of those apps outside of the Azure AD/Office 365 stack. Using Conditional Access App Control (also known as MCAS Proxy) you can monitor and control use of cloud apps in real-time.

In this article, I will investigate what MCAS actually is, and what benefits it offers above the more simplistic controls within EMS E3, and then I will explain how you can implement Azure AD Conditional Access to protect users with MCAS, and how you then go on to protect your data – in this case within Microsoft Exchange Online – using MCAS Session Policies.

Conditional Access App Control

The functionality within MCAS which enables the restriction of behaviour in web applications is Conditional Access App Control. This can be implemented with any apps configured with SAML or Open ID Connect with single sign-on in Azure AD. This functionality has recently been extended to Office 365 apps (Exchange Online, Yammer, OneDrive for Business, SharePoint Online and Microsoft Teams) in Preview.

What is the difference between MCAS and OWA Mailbox Policies?

One of the key questions I had from an Exchange Online perspective when first investigating MCAS was why I would use this EMS E5 (the more expensive option) capability over the native protections within Exchange Online, perhaps alongside Conditional Access which comes as part of EMS E3.

The simple answer is the improved granularity of the control.

Using OWA Mailbox Policies, you either allow access to all attachments completely in OWA (open and download), view-only (just open in Office Web Apps) or block access to all attachments completely.

Using MCAS Session Policies, you can target more specific usage, such as device type (PC, mobile, tablet or other), specific geographic locations, or even specific ISPs. More importantly, you can also target specific file properties, so rather than restricting your users’ access to all files received as attachments, you can instead treat differing files alternatively, either targeting classification labels, file extensions, file names or file size. Then, you can reach another level of granularity again by using Content Inspection, applying controls on specific sensitive data types, for example, protect files that contain an email address to ensure you’re not sharing Personally Identifiable Information (PII), or write custom expressions to monitor what emails are being exchanged regarding a confidential project.

Those who are eagle-eyed reading this may have noticed I’ve hinted the final key benefit of MCAS. This being rather than just blocking access to the files sent in an email, you can apply protection to files accessed using OWA automatically based on the criteria specified above, using Azure Information protection Classification Labels (currently only labels that apply protection and are within the Global policy are supported) and block download of any files that can’t be protected – i.e. .txt files.

How do I enforce MCAS protection?

You can now configure conditional access policies in Azure AD to apply MCAS protection. When configuring your CA Policy, under the Session Access controls, select use Conditional Access App Control.

There is also a link here to the Cloud App Security portal.

How do I configure MCAS protection?

To demonstrate the capabilities, I am going to create three MCAS Session Policies to enforce different behaviours:

• First, I am going to apply a protection label to any documents which makes reference to Project X-Ray accessed from a non-domain joined machine, to ensure if they are downloaded, they will remain restricted to only members of the specified group via AIP Protection.
• Second, I am going to create a policy that blocks files download from a non-domain-joined or compliant machine.

For my first policy I will start by creating a new Session Policy from the Policies screen.

Then, I Create policy > Session Policy.

In the Create Policy window, I will configure my policy. First I will configure general details such as Policy name, Description and Session control type. For these policies, I will be selecting Control file download (with DLP) from the drop-down list.

Under the Activity source section, I configured the filter to match the requirement of applying the policy when the machine is not domain joined.

I then configure the Content inspection section, which is where I will identify the data to be protected. This is where you could use Sensitive Information types, but I am simply using a text string custom expression.

In some cases, you may want to protect anything that is encrypted and therefore can’t be scanned, but in this case, I am not applying this.

Next, you specify the action to be taken on the file. In this example, I want to block access to the file.

Once these settings are all configured you can click Create to create the policy. Note, that you see the warning message confirming that this is only applied to browser-based apps.

For my second policy, I will configure the same settings, with different values.

Under the Activity source section, I have configured the filter to match our requirement of applying the policy to machines that are not domain-joined or compliant.

In this case, I will not configure content inspection and will simply set the action to block download with a custom block message.

Click Create, and this is all the policies configured.

What is the user experience?

The first thing the user will notice is a warning that their access to OWA is being monitored by MCAS.

The next thing is that the URL for OWA will be changed from https://outlook.office365.com/owa to https://outlook.office365.com.eu.cas.ms/owa (in my case as my tenant is based in the EU).

Now, let’s look at what happens when we trigger our Session Policies, first looking at the Project X-Ray policy. When I open an attachment which contains Project X-Ray information from OWA, I can view this in the browser and I’m still able to download it. When launching the document after download, the first thing you will notice is this during Word’s start-up process:

The fact that your machine is configuring “Information Rights Management” is the first sign that the policy has been applied, and the document has been protected. When we open the document, you can see the policy has applied correctly:

The SECRET – PROJECT X-RAY protection template has been applied, and when we look at the permissions you can see the restrictions this puts in place.

So in this scenario, you could have a set group of people who you have set specific permissions. This means they can download their documents and work on them so long as they are signed in to their Office 365 account (by applying this restriction in the AIP label), giving these users more flexibility than before had they not been using their corporate machines.

Finally, the behaviour when the second policy is applied, this in turn blocks the downloading of files.

Again, you can open the attachment within OWA/Office Web Apps, and the option to download the file still displays within the email. This may be one of the reasons organisations prefer the user experience of OWA Mailbox Policies because if you block the download of attachments from OWA the option is removed from the interface. For users, this is less confusing, but obviously it has to be outweighed against the flexibility benefits.

When you attempt to download the file, you are shown a Download blocked notification including the custom wording we configured in our policy above.

You will also notice a txt file being downloaded which contains further information on the file. This is because where the MCAS Proxy sits in the navigation process, something must be downloaded at the time the proxy intervenes in the download. Consequently, this txt placeholder is downloaded and contains some original file information and the custom block message again.

This article is just a brief introduction to some of the capabilities of MCAS Proxy with Exchange Online and how they are implemented. Over the last 12-18 months, we have seen there has been a bigger uptake of Office 365 E5.

As a result of this, there have been greater monitoring and protection capabilities with Cloud App Security, so I won’t be surprised to see more organisations implementing these technologies in their environments.