In recent years, I have written +20 Cloud App Security (MCAS) related blog posts but never touched deeply on Access Policies. Blocking access to the cloud environment can be efficiently done with other methods, such as Conditional Access policies, and use cases for using MCAS Access Policies are rare, but there are a few interesting ones.
Background
Typical organization I have worked with uses MCAS for cloud security monitoring & governance purposes. There are a lot cool features underneath the hood which are not widely known or used. To name a few ones:
- Cloud Discovery aka Shadow IT Management
- File Scanning
- Malware detection
- Microsoft Defender for Identity integration
- Identity security posture management
- Microsoft Defender for Endpoint integration
- App Control with Session Policies
- Custom policies in general. MCAS offers a way to detect use cases that are not possible to detect with other products
Session & Access Policies – Background
MCAS has wide range of policy categories available out of the box, a reference list of policy templates is found here. Even though, possibilities of leveraging policies is almost endless, it’s important to be aware of MCAS limitations when working with access & session policies. As most of you already know, MCAS is built mainly for protecting browser based applications in terms of Access & Session policies.
For example, session policies don’t support mobile & desktop apps.
The following statement is in Microsoft documentation (docs.microsoft.com) regarding session and access control policies:
Session and access controls can be applied to any interactive single sign-on, using the SAML 2.0 authentication protocol or, if you are using Azure AD, the Open ID Connect authentication protocol as well.
Furthermore, if your apps are configured with Azure AD, you can also apply these controls to apps hosted on-premises configured with the Azure AD App Proxy. In addition, access controls can be applied to native mobile and desktop client apps.
Native clients interactive sign-on can be seen in MCAS but when they are acquiring refresh-token it’s not visible in MCAS. There is an exception for this and you can request from MS Support non-interactive sign-in to be seen in your activity log (learned this one in one of my earlier MCAS case). The downside is that it might lead to huge number of false/positive alerts.
Access Policies – Use Cases
Let take a look how access policies could be used in combination of Azure AD Conditional Access & MCAS. Most of the access blocking scenarios can be achieved typically with Azure AD Conditional Access which have more granularity for configurations but in certain use cases MCAS can do a trick.
Also, keep in mind that especially traffic from risky networks based on Microsoft Threat Intelligent data is detected also with Azure AD Identity Protection (IPC). It means that even though you would have MCAS access policy in place, the access will be blocked by IPC before it reaches MCAS.
IPC deep dive – Azure AD Identity Protection Deep Diver – Part 2 – Sam’s Corner (samilamppu.com)
Pre-Requisites for Access Policies
- Azure AD Premium P1 license, or the license required by your identity provider (IdP) solution
- The relevant apps should be deployed with Conditional Access App Control – example policy below targeted for Office 365 App.
Example – Block Access by Category
Block Access from ‘Risky Network’ category is based on Microsoft Threat Intelligence data. In the specific category there are at the time of writing three (3) ranges available and one of them contains also Tor networks. If you want to block access to certain applications with MCAS it’s possible by creating Access policy and target it to wanted category.
Risky networks contains the following categories:
- Threat Intelligence
- Tags: Anonymous proxy, Botnet, Tor
- Malicious IP
- Blacklist
- Potential Malicious IP
- Blacklist
Be careful when using the category as a block mechanism. I have seen in many environments that legit connections are considered as anonymous proxy connections. In such environments, if category would be used as block mechanism, the connections would be blocked.
Block access by category alert
In this alert the category was used as a detection mechanism.
Example – Block Access by Tag
- Filters: IP-address
- Tag equals ‘Tor’
Before creating the policy you can select “edit and preview results” which shows traffic based on the filters selected.
Alert – Block Access by Tag
Alert generated when Tag ‘Tor’ was used.
Example – Block Access from native clients
You can block native client access with MCAS access policies. Even though, there are more comprehensive solutions for this available such as, Intune and Azure AD Conditional Access, MCAS might solve the problem in some use cases. If creating access policy for native clients remember to “device type = PC” that you don’t accidently block access from mobile devices.
Alert – Teams Native Client Access Blocked
Alert from native client, Teams in this case.
Summary
Access policies can offer more granularity for blocking access in some scenarios. In general, I recommend to use Azure AD Conditional Access for blocking purposes and use MCAS session controls for controlling the activities inside the session. Now, when Azure AD Authentication Context is in public preview you as an admin have even more options to control application sessions.
In general, blocking is more considered in BYOD scenarios. Also, mobile phones are something to consider when planning access policies but in those cases, Intune App Protection might be the chosen path.
References
Protect with Microsoft Cloud App Security Conditional Access App Control | Microsoft Docs
Cloud App Security: Block TOR Browser (Anonymous IP) – Microsoft Tech Community
This blog is part of Azure Week. Check it out for more great content!
About the Author:
Lead Consultant at NixuTigerTeam and an Azure MVP
Reference:
Lamppu, S. (2021). Cloud App Security Access Policies – Common Use Cases. Available at: https://samilamppu.com/2021/06/22/cloud-app-security-access-policies-common-use-cases/ [Accessed: 9th July 2021].
