Overview: Session policies with Conditional Access App Control and Defender for Cloud Apps
Through Software as a Service (SaaS), many corporate applications and data now reside in the cloud and, in most cases, can be accessed from any browser. This interactions can be monitored and governed through Defender for Cloud Apps. A browser is independent of device management (MDM) or application management (MAM), and the only security perimeter is again identity. But the browser session can also be monitored and controlled - which is what this blog post is about. Common requirements could be:
- Prevent data exfiltration: block up-/download, cut/copy and print
- Information protection and data loss prevention: only allow up-/download of documents with a specific label (Purview Information Protection)
- Block potential malware: protect your environment by blocking the up-/download of malicious files identified by Microsoft threat intelligence
- Require step-up authentication: require MFA for privileged tasks
- Alert and investigate on events: trigger alerts and find visibility through processes and actions in cloud apps
- Protect corporate resources accessed from the browser on non-corporate devices
- Apply real-time session monitoring & controls
- Granular governance over session activities with policies and alerts
- Conditional Access (CA) - access evaluation based on signals to grant / with access or block and apply session controls
- Defender for Cloud Apps (DFCA) - the cloud access security broker (CASB), as visibility- and governance tool for Cloud Apps
Layer of interference
To enforce session controls, DFCA uses a reverse proxy architecture that redirects the app URL to a custom MCAS URL. Users will also get a notification before entering a site. This happens on OSI layer 5 session layer. Read the Microsoft docs
|Original URL||MCAS redirected URL with Session control|
The notification before opening the site:
Let's get started with some hands on and experience from the field.
Conditional Access app control & Defender for Cloud Apps connected apps
Conditional Access and Defender for Cloud Apps can both enforce session policies, but CA is much less powerful, as shown in the list - which are the available options in a CA policy under "Session":
- "Monitor only (Preview)" only connect Defender for Cloud Apps connected apps, so they get listed
- "Block downloads (Preview)" a session control to block Microsoft proprietary download function (it will not work for any app integrated download or save)
- "Use custom policy..." will enforce the dedicated session policy of Defender for Cloud Apps
In DFCA you can see the connected apps under Investigate. These will populated once a Conditional Access policy enforces app control and a user accesses the app.
A session policy can be created in the DFCA portal under Control>Policies and has the following settings:
First of all you can add some general information to the policy such as the name, severity, category, description and the session control type of the policy that will allow for different policy settings, which could be: Monitor only, Block activities, Control file download (with inspection) or Control file upload (with inspection). I would definitely also take a look at the templates.
The activity source is are condition/rule set to which entities this policy will get subject of.
There are some filters for the files, especially the sensitivity label is a powerful option (integration to Compliance).
The inspection method then defines how the content is treated. Built-in DLP for data loss prevention of data in sessions (basic controls), Data Classification Service is to inspect the content for classified data types and sensitive data. Malware detection utilizes the Microsoft Threat Intelligence service to scan files on potential malware.
The action is what then happens on a policy match.
- Test - monitor only
- Block - block the action (notify the user by mail or customize the block message displayed to the user)
- Protect - apply a sensitivity label to the downloaded files
- Require step-up authentication - require MFA in the session to fulfill the action
"Always apply the selected action even if data cannot be scanned" is another option to enforce the policy even if the data could not be inspected/scanned.
The alerts consist of the familiar DFCA alerts which are displayed in the portal, sent by email, text message or to Power Automate. You can also set a daily alert limit to avoid an alert and overview overkill.
Here are some policy samples for Conditional Access (CA) only, or combined with Defender for Cloud Apps (DFCA).
- Monitor the session for all cloud apps
- Browsers on devices can‘t download files and attachments
- Sign-in frequency for special applications
- No persistent browser sessions
- Continuous access evaluation (CAE) for real-time token revoke
- Disable resilience defaults (behaviour during an Azure AD outtage)
Some of the DFCA session policies use real-time content inspection. The policies could always be configured to trigger an alert.
- Block up-/download of potential malware (based on Microsoft Threat Intelligence)
- Block up-/download with limitation (file extension, name, size, sensitivity label)
- Block sending of messages
- Block cut/copy and paste
- Protect files on download with a sensitivity label
- Require step-up authentication for certain actions
This is a little guidance how I would introduce this service:
- Technology introduction / POC for session controls
- Pilot stage > gather connected apps and start monitoring
- Define a strategy/concept and enlighten the management
- Base protection (soft policies), start with alerts and observe the service impact and adapt on feedback
- Implement more rigorous policies
- Integration to Compliance / Purview
On my blog I cover more interesting security topics, such as: