For many organizations, the move to the cloud means many more ways for employees to access sensitive data. The days of the corporate-issued laptop on the network (or VPN) being the only way to access corporate data are well behind us. While this increased flexibility can be a boon for end user productivity and mobility, it can also mean greatly increased risk of security events if not enabled in a secure fashion.
Enter contextual access control.
Long a staple of cloud access security broker (CASB) deployments, contextual access control allows you to identify the context by which a user is accessing an application, and then limit the user’s level of access to that application based on the risk of that context. For example, if a user is accessing Office 365 from an unmanaged device, you might want to block the OneDrive sync client. Constantly synchronizing large amounts of potentially sensitive data to an unmanaged device is not only risky, but it’s also not necessary for users to have such large quantities of data pre-downloaded to an unmanaged device.
Microsoft’s answer to this use case is what they call Azure AD Conditional Access. According to Microsoft, “the objective of a conditional access policy is to enforce additional access controls on an access attempt to a cloud app that is driven by how an access attempt is performed.” Available only in Azure AD Premium P1 at $6/user/month (or for $8.74/user/month as part of EMS E3), this functionality is not cheap. Unfortunately, it’s also quite limited.
Let’s take a closer look.
Conditional Access policies include two components – Conditions and Access Controls, with Conditions establishing the context by which the user is accessing the app, and Access Controls being the action taken as a result of that context.
- Users and Groups
Azure AD supports users and groups as conditions, much like leading CASBs do. Unfortunately, you’re limited only to using Azure AD as your directory, which is quite a big change if you’re not already using Azure AD.
Advantage: CASB, or draw if you’re using Azure AD
- Cloud Apps
Azure AD supports Cloud Apps as conditions, much like a CASB would typically do.
- Client Apps
Client apps promise to allow you to “apply a policy to different types of applications. Examples are websites, services, mobile apps, and desktop applications.” From here, Microsoft links to their “technical reference” for details on the supported client apps:
Quite the limitation to only support one application!
- Device State & Platform
Distinguishing by Device Platform (OS) is available, though of limited usefulness in most scenarios. Device state, however, promises to distinguish between managed and unmanaged devices. Unfortunately, it does so only via Azure AD Domain Membership, which limits platform support and requires Azure AD, or via devices manually marked as compliant, which doesn’t scale beyond the smallest organizations. A CASB gives you the flexibility to identify devices based on a wide range of cross-platform variables in a scalable, automated fashion.
Advantage: CASB, unless you are that very rare organization that has only Windows machines and all are Azure AD domain joined, in which case this is a draw.
- Block vs Allow Access
Table stakes… Everyone can allow or block access altogether.
- Access Only from Approved Client Apps
This feature allows the organization to limit access only from approved client apps. Unfortunately, this functionality works ONLY with Microsoft apps. No native mail clients, no third party apps, etc. For most organizations, the cloud footprint very quickly extends beyond Microsoft Office 365, making this limitation a non-starter.
- Session Controls
As with the Client App condition, this is another lofty sounding Microsoft feature – “Session controls enable limited experience within a cloud app. The session controls are enforced by cloud apps and rely on additional information provided by Azure AD to the app about the session.” Sounds great, let’s take a look at the supported application list:
Surprise, surprise, Sharepoint Online only!
CASB can offer limited data access for ANY application, Microsoft or otherwise
- Limited Access within an App/Access Method
Many organizations want to use context/conditions to allow access within an app/access method, but in a limited fashion. Unfortunately, whether you have Conditional Access only, or if you’ve also purchased the Microsoft CAS product, there is no real-time, inline protection. This means no ability to control, or even see, what a user is doing after they’ve logged in. This also means no insider threat protection, no account hijack/takeover protection, and no controls of any sort over suspicious activity once the door is opened.
The Bottom Line
Overall, this feature is high on promise and low on delivery, operating on the design principle of transferring large portions of customers’ money into MSFT’s bank account.
To learn more about CASBs, download the Definitive Guide.
*** This is a Security Bloggers Network syndicated blog from Bitglass Blog authored by Tim Davis. Read the original post at: https://www.bitglass.com/blog/msft-azure-ad-conditional-access-vs-casb