Defender for Cloud Apps (MCAS): CASB Configuration for Zero Trust

The OAuth App Problem Your Conditional Access Policies Don't Solve

Walk into any M365 tenant that's been running for three or more years and pull the OAuth app consent list. The number is almost always higher than anyone on the security team knows. Apps authorized by users: calendar integrations, productivity tools, AI writing assistants, meeting schedulers: each holding delegated or application permissions on Exchange, SharePoint, or Microsoft Graph. Most were authorized before your current Conditional Access policies existed. None of them go through Conditional Access when they make API calls, because Conditional Access protects the authentication event, not the ongoing delegated token.

Defender for Cloud Apps, the product Microsoft rebranded from Cloud App Security (MCAS) in 2022, addresses three gaps that Conditional Access leaves open:

• What users do inside sanctioned cloud applications after authenticating
• Which unsanctioned cloud applications exist across the organization
• Which OAuth apps have been granted permissions to tenant data and how they're using those permissions

The CASB architecture sits between users and cloud applications. In session proxy mode (Conditional Access App Control), it proxies browser sessions, enabling real-time inspection and enforcement. In API-connected mode, it reads activity logs and file metadata from connected apps without requiring traffic redirection. Both modes provide visibility and control that authentication-time checks cannot.

This article covers the complete zero trust configuration: Cloud Discovery, Conditional Access App Control session policies, information protection, OAuth app governance, and KQL queries to monitor enforcement.

CASB Integration Architecture

Defender for Cloud Apps integrates with cloud apps in three modes. The mode determines which controls are available. Building a policy against an app that isn't in the right integration mode produces no enforcement effect without surfacing an error.

For zero trust posture, the priority order is:

1. App connectors for sanctioned SaaS apps: visibility into post-auth activity and OAuth governance
2. Session proxy (CAAC) for data-sensitive applications: real-time enforcement at the session layer
3. Defender for Endpoint integration: replaces manual log uploads with automatic continuous discovery

Cloud Discovery: Enable Continuous Visibility via Defender for Endpoint

Manual log uploads provide historical snapshots with a 24-hour lag and require log infrastructure to maintain. The integration between Defender for Endpoint and Defender for Cloud Apps enables real-time cloud discovery without any additional log infrastructure: devices enrolled in MDE stream cloud traffic metadata automatically.

Enable the integration in the Microsoft Defender portal at Settings > Endpoints > Advanced Features > Microsoft Defender for Cloud Apps, toggle to On.

Within 24 to 48 hours, the Cloud Discovery dashboard populates with discovered apps, user counts, transaction volumes, and risk scores. The risk score (1 to 10) factors in approximately 80 attributes: encryption in transit and at rest, GDPR compliance claims, data retention policies, legal jurisdiction, and security certification status. Any app scoring below 5 warrants review for blocking.

For devices not enrolled in MDE (servers, legacy systems, IoT devices), deploy a Docker-based log collector to receive syslog output from your firewall or proxy:

docker pull mcr.microsoft.com/mcas/logcollector:latest
docker run -d \
  --name casb-log-collector \
  --restart always \
  -p 514:514/udp \
  -p 601:601/tcp \
  -e COLLECTOR_TOKEN="<token-from-defender-portal>" \
  mcr.microsoft.com/mcas/logcollector:latest

Configure your Palo Alto, Fortinet, or Zscaler proxy to syslog-forward to the collector's IP on port 514 (UDP) or 601 (TCP). The collector parses vendor-specific log formats and streams enriched app metadata to the Defender for Cloud Apps backend.

Classifying and Blocking Unsanctioned Apps

Cloud Discovery surfaces what's running. The next step is classification. Set every discovered app to Sanctioned, Monitored, or Unsanctioned. Unsanctioned with block enabled pushes a block indicator to MDE-enrolled devices and compatible proxy integrations.

Block an app using the Defender for Cloud Apps REST API:

curl -X POST "https://<tenant>.portal.cloudappsecurity.com/api/v1/discovered_apps/unsanction" \
  -H "Authorization: Token <api-token>" \
  -H "Content-Type: application/json" \
  -d '{"appId": 12345, "block": true}'

For MDE-integrated devices, the block signal propagates to Windows Defender SmartScreen and Network Protection within approximately 2 hours. For proxy-based environments, download the generated block list from Settings > Cloud Discovery > Block scripts and import it into your Palo Alto or Zscaler URL category policy.

For detecting shadow AI tools specifically (unapproved ChatGPT wrappers, coding assistants that upload code to external services), search Cloud Discovery by category "AI" or tag "Generative AI". The full shadow AI detection and governance workflow is covered in the shadow AI governance guide.

Conditional Access App Control: Session-Level Enforcement

CAAC is the inline session proxy capability. When a user authenticates to a SAML or OIDC app via Entra ID, CAAC rewrites the reply URL to route the browser session through Microsoft's reverse proxy. From the user's perspective, the app behaves normally. From the security team's perspective, every HTTP request is inspectable and enforceable. Prerequisites:

• The target app must use Entra ID as the identity provider via SAML or OIDC
• A Conditional Access policy must route the app through CAAC
• The app must render without strict frame-busting headers that block proxy injection

Conditional Access policy configuration for CAAC:

In the Entra ID Conditional Access portal, modify the policy governing the target app. Under Sessions > Use Conditional Access App Control:

• Select "Monitor only" during the rollout phase: traffic is proxied and logged but no blocking occurs
• Switch to "Use custom policy" when session policies are tested and ready to enforce

Session policy: block download from unmanaged devices

In Defender for Cloud Apps under Policies > Session policies, create:

Policy name: Block-SharePoint-Download-UnmanagedDevice
Session control type: Control file download (with inspection)
Applications: Microsoft SharePoint Online
User filter: All users
Device tag: NOT "Intune compliant", NOT "Hybrid Azure AD joined"
Action: Block
Alert severity: Medium
Send alert to: security-team@contoso.com

This policy stops the scenario where a user on a personal device accesses SharePoint via a mobile browser and mass-downloads files outside the device compliance check. Conditional Access verified the device (or didn't) at authentication time; the session proxy enforces the download restriction at the HTTP layer regardless of how the session was established. Session policy: watermark downloads from managed devices

For managed devices where download is permitted but a forensic trail is needed:

Policy name: Watermark-SharePoint-Download-ManagedDevice-Confidential
Session control type: Control file download (with inspection)
Applications: Microsoft SharePoint Online
File filter: Sensitivity label is "Confidential" OR "Highly Confidential"
Device tag: "Intune compliant" OR "Hybrid Azure AD joined"
Action: Protect (apply label and watermark)
Watermark text: "[User.Mail] [Date]"

The proxy applies the watermark to the downloaded copy only. The original file in SharePoint is unchanged. This creates a forensic trail linking the document to the specific user and session without requiring an endpoint agent or custom DRM infrastructure.

Information Protection: File Policies for Stored Data

File policies scan files stored in connected apps continuously, not just at the time of download or upload. They catch data that arrived before the policies were created, which is critical for any tenant with years of unscanned SharePoint content. File policy: detect unprotected PII in SharePoint

Policy name: Detect-UnprotectedPII-SharePoint
Applications: Microsoft SharePoint Online
Inspection method: Built-in DLP
Content match: "Credit Card Number" OR "U.S. Social Security Number" OR "IBAN"
File filter: Sensitivity label is NOT "Confidential" AND NOT "Highly Confidential"
Action: Apply sensitivity label "Confidential"
Governance: Notify file owner
Alert severity: High

File policy: detect sensitive files shared externally

Policy name: Detect-ExternalShare-Confidential
Applications: Microsoft SharePoint Online, Microsoft OneDrive
File filter: Sensitivity label is "Confidential" OR "Highly Confidential"
Collaborators: External users have access (domain NOT in approved partner list)
Action: Remove external collaborator access
Governance: Quarantine file, notify file owner, email compliance team
Alert severity: High

These policies complement Purview endpoint DLP. Purview endpoint DLP covers files accessed from managed Windows endpoints. Defender for Cloud Apps file policies cover the same files when accessed via browser on any device, or via third-party apps connected through OAuth grants. Both layers are required for full coverage of regulated data.

OAuth App Governance

App Governance is included with Microsoft 365 E5 and Defender for Cloud Apps plans. Access it at Microsoft Defender portal > Cloud Apps > App Governance.

The highest-priority view is Apps > High privilege. Filter for apps that have:

• Files.ReadWrite.All: full read/write access on all SharePoint and OneDrive content in the tenant
• Mail.ReadWrite: full read/write access on all Exchange mailboxes in the tenant
• Directory.ReadWrite.All: permission to modify any Entra ID object

These three permission scopes in an unrecognized or community-rare app are the clearest signals of a compromised OAuth token or a malicious consent grant attack (also called illicit consent grant). Create an App Governance policy for high-privilege apps with anomalous activity:

Policy name: Alert-HighPrivilege-LowUsage-Apps
Trigger: App has Files.ReadWrite.All OR Mail.ReadWrite
AND: Publisher is not Microsoft-verified
AND: Community use is less than 5%
AND: API call rate exceeds 300 calls/day with fewer than 5 active users
Action: Alert (high severity), Generate incident in Defender portal

Revoke consent for confirmed suspicious apps:

Connect-MgGraph -Scopes "Application.Read.All", "AppRoleAssignment.ReadWrite.All", "DelegatedPermissionGrant.ReadWrite.All"
# Revoke all app role assignments for a service principal
$spId = "<service-principal-object-id>"
$assignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $spId
foreach ($assignment in $assignments) {
    Remove-MgServicePrincipalAppRoleAssignment \
        -ServicePrincipalId $spId \
        -AppRoleAssignmentId $assignment.Id
}
# Revoke delegated permission grants
$grants = Get-MgOauth2PermissionGrant -Filter "clientId eq '$spId'"
foreach ($grant in $grants) {
    Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $grant.Id
}
# Disable the service principal to prevent new token issuance
Update-MgServicePrincipal -ServicePrincipalId $spId -AccountEnabled $false

Zero Trust Policy Coverage Map

The following matrix maps each policy type to the zero trust principle it enforces and the specific threat it addresses:

Enable all built-in anomaly detection policies under Settings > Cloud Apps > Anomaly Detection. The policies to verify as active: Impossible travel, Activity from anonymous IP addresses (Tor, VPN, anonymizer services), Ransomware activity detection, and Mass download.

Monitoring with KQL

When Defender for Cloud Apps alerts are forwarded to Microsoft Sentinel via the Microsoft Defender XDR data connector, these queries provide hunting and alert coverage: Download block events by user and policy:

CloudAppEvents
| where ActionType == "BlockedAccessAttempt"
| where Application in ("Microsoft SharePoint Online", "Microsoft OneDrive")
| extend PolicyName = tostring(RawEventData.BlockingPolicyName)
| extend DeviceType = tostring(RawEventData.DeviceType)
| summarize BlockCount = count() by AccountDisplayName, PolicyName, DeviceType, bin(Timestamp, 1h)
| where BlockCount > 3
| order by BlockCount desc

Anomalous OAuth app API call volume:

CloudAppEvents
| where ActionType == "OAuthAppActivityByServicePrincipal"
| extend AppName = tostring(RawEventData.AppName)
| extend ScopesUsed = tostring(RawEventData.Scopes)
| where ScopesUsed has_any ("Mail.ReadWrite", "Files.ReadWrite.All", "Directory.ReadWrite.All")
| summarize DailyCallCount = count() by AppName, AccountId, bin(Timestamp, 1d)
| where DailyCallCount > 500
| order by DailyCallCount desc

Impossible travel alert triage:

SecurityAlert
| where ProductName == "Microsoft Cloud App Security"
| where AlertName has "Impossible travel"
| project TimeGenerated, CompromisedEntity, Description, Severity, ExtendedProperties
| order by TimeGenerated desc

For integration with the broader zero trust posture, see the zero trust security guide and the non-human identity governance guide for the service account and managed identity layer that CASB controls complement.

CAAC Rollout Strategy

Rolling CAAC into production without a test phase causes user-visible disruption. Common failure modes:

• Apps with strict Content-Security-Policy headers that block the proxy's JavaScript injection: visible as a blank page or console errors about refused frame embedding
• Single-page applications using custom authentication libraries outside standard OIDC redirects: the reply URL rewrite may fail silently and redirect users to an error page
• Apps behind split-tunnel VPN where some traffic bypasses the proxy: session policies appear to apply but download restrictions don't trigger for tunneled traffic

Recommended rollout sequence:

1. Deploy CAAC in Monitor Only mode for two weeks, observing session activity without blocking
2. Review the CloudAppEvents table in Sentinel for access patterns that would have triggered blocking under enforcement policies
3. Test session policies against a pilot group of 10 to 20 users before tenant-wide rollout
4. Switch to enforcement mode for the pilot group and monitor support ticket volume for proxy-related rendering issues
5. Expand to full tenant in batches by department over two weeks

For the full zero trust architecture these controls fit into, including the Defender for Cloud vs. Wiz CSPM comparison for cloud workload posture coverage.

Hardening Checklist

• [ ] Defender for Endpoint integration enabled for real-time cloud discovery without log upload infrastructure
• [ ] All discovered apps classified as sanctioned, monitored, or unsanctioned within 30 days of initial discovery
• [ ] Unsanctioned apps with risk score below 5 blocked via MDE or proxy integration
• [ ] CAAC session policies deployed for SharePoint, OneDrive, and Exchange OWA: downloads blocked from unmanaged devices
• [ ] Watermarking policy active for managed-device downloads of Confidential-labeled documents
• [ ] App connectors configured for all sanctioned SaaS: M365, Salesforce, Box, GitHub Enterprise, AWS
• [ ] File DLP policies active: scanning SharePoint and OneDrive continuously for unprotected PII
• [ ] External sharing detection active: removing access when Confidential files are shared outside the approved domain list
• [ ] App Governance enabled with high-privilege app policies configured and alerting
• [ ] All anomaly detection policies enabled: impossible travel, anonymous IP, mass download, ransomware detection
• [ ] CASB alerts forwarded to Sentinel via Microsoft Defender XDR data connector
• [ ] KQL alert rules deployed for download blocks, OAuth call volume anomalies, and impossible travel events
• [ ] CAAC tested in monitor-only mode for each target app before switching to enforcement
• [ ] Quarterly OAuth app review scheduled: audit apps with write permissions every 90 days and revoke stale consent