First published on CloudBlogs on Nov 13, 2017 by Microsoft Cloud App Security Team
At Microsoft Ignite 2017, we announced the upcoming public preview of Conditional Access App Control . We are very excited that the time has arrived, and this feature is now in public preview! In this blog, we’ll dive deeper into the functional implementation of the feature and explain key productivity use-case scenarios. Our goal is to provide you detailed information to help you secure your cloud app data and perform real-time monitoring. Let’s get started!
Extend conditional access capabilities for real-time control of user sessions in cloud apps
Azure Active Directory (Azure AD) conditional access and Microsoft Cloud App Security Conditional Acess App Control work hand in hand to provide real-time monitoring and session control for cloud apps. In-session controls start with an Azure AD conditional access policy . In Azure AD, IT admins build a conditional access policy to define who (users or groups of users) and what applications should be routed toMicrosoft Cloud App Security, forming a set of conditions that can include user sign-in risk. In public preview, these policies apply to SAML-based app logins. After you select use of Cloud App Security Conditional Access App Control as a session control in the Azure AD console, the conditional access engine evaluates each user’s sign-in to determine if there is a policy in place for the spec set of conditions the user is coming from. If so, Azure AD sends that information to Microsoft Cloud App Security and, based on the filters set in the Conditional Access App Control session policy, the appropriate actions are taken on the user activities.
Set granular policies to restrict user activities and limit content access
Conditional Access App Control session policies help you to control and limit the user activities in the session itself. To do this, you define additional conditions for the session through filters, then you define the types of control (e.g. block download) you would like to implement based on these conditions. Filters . You can create activity or file filters. Here are some commonly used filters to create granular and effective session policies:
- Device identification: You can create a condition for unmanaged devices based on whether the device is Intune-compliant, Azure AD domain joined, or holds a valid client certificate. Since unmanaged devices add another level of risk to a session, this is a valuable filter to implement additional controls.
- Location information : Location or IP address can be utilized as an activity filter to establish controls for users accessing apps from locations outside of the corporate network. You can also configure restrictions for internal or risky IP addresses through the portal.
- Classification labels : This condition is integrated with Azure Information Protection and can be used to target files with sensitive content and place additional controls such as blocking access to the file.
- Content inspection : Content inspection of files is also an important filter and you can leverage the Microsoft Cloud App Security DLP engine to scan files for sensitive information matching a preset or custom expression, (e.g. credit card information).
Actions . Once you’ve defined the filters for the policy, which establish the parameters that will be evaluated, you can now determine the actions or controls. You can select to allow, block, or protect access to a document:
- Allow . You allow the user unrestricted access and actions in the app and log their actions.
- Block . If the user is coming from specific conditions you’ve set in the filters, this action will prevent the user from downloading a sensitive file.
- Protect . Alternatively, you can enforce protection on the file itself, and when the user downloads the file, it will be labeled with the selected Azure Information Protection classification label and corresponding protection (including encryption). Protection can be applied to files that support native encryption.
To keep the user within the session, all the relevant app URLs, Java scripts, and cookies within the session are replaced with unique URLs. For example, if the app returns a page with links whose domains end with myapp.com, with the link will appear as: myapp.com.us.cas.ms. As a result, events within the session can be monitored and when a download event is triggered, your desired control action will be implemented by either blocking the download or protecting the file.
Address key use case scenarios
Let’s put everything together and look at a conditional access policy and session policy working together for a typical use case scenario: Example Azure AD Conditional Access Policy:
Conditions : User is Bob, App is Box
Controls : Use proxy-enforced restrictions
Example Conditional Access App Control session policy:
Session Control Type : Monitor all activities and control file download
Filters : Classification label equals “confidential”; Device tag does not equal “compliant, domain joined or valid client certificate”
Action : Block
Using the examples above, what would happen?
The Azure AD conditional access policy and the Conditional Access App Control session policy will work together to perform real-time monitoring and control. User Bob, accessing Box from a non-compliant device such as his personal computer, would be routed through Azure AD to Microsoft Cloud App Security where his session would then be monitored. If Bob attempts to download a confidential labelled file, the download will be blocked and present Bob with the message that he is not allowed to download the file from the device he is using. Bob can still access Box and non-confidential files, but he will not be able to download the confidential files to this unknown and non-compliant machine. This capability provides you granular controls for controlling actions in user sessions. Blocking the sensitive data download to unmanaged devices helps you protect your organization’s data. At the same time, Bob can access the app and complete his required work from home. But this is only one of many use cases. IT admins can also perform the following key protection and productivity scenarios:
- Monitor high risk user sessions : Users with high sign-in risk levels accessing protected apps will be monitored and their actions within the session will be logged. IT admins can investigate and analyze user behavior to understand where, and under what conditions, session policies should be applied in the future.
- Restrict user sessions from locations outside of corporate network : Users accessing a cloud app from locations outside of corporate network will be allowed restricted access where the download of sensitive materials can be blocked.
- Protect on download : Instead of blocking the download of sensitive documents, IT admins can instead require documents to be protected via encryption on download. This ensures that the document is protected, and user access is authenticated, if the data is downloaded to an untrusted device or from an untrusted location.
Conditional Access App Control session policy – actions
Monitor activities with in-depth investigation capabilities
For those of you who are familiar with Microsoft Cloud App Security, you know the power of our activity log to investigate actions and events and pivot on critical inputs such as user and application. Regardless of the deployment method, API or reverse proxy (Conditional Access App Control), you can analyze activities in protected apps, gain a greater understanding of user behavior, and refine your session policies based on these insights. Additionally, you can also select Conditional Access App Control as a source for discovery analysis which will allow you to gain visibility to app traffic and usage patterns routed through the reverse proxy.
Feedback
Detailed information is now available at our technical documentation site . As always, we want to hear from you! If you have any suggestions, questions, or comments, please visit us at our Tech Community page .