15.2 Defender for Cloud Apps Policies & Alerts

Policy Types in Defender for Cloud Apps

Policies are the engine that turns Defender for Cloud Apps telemetry into detections and automated responses. Each policy type is keyed to a different signal source, and MS-102 expects you to know which type applies to which scenario.

---

Anatomy of a Policy

Every policy in Defender for Cloud Apps follows the same three-part structure: filters → triggers → governance actions.

Filters

Filters narrow the scope of activities, files, or apps the policy evaluates. Common filters include:

• User / user group — specific users, groups, or all users except administrators
• IP address / IP tag — corporate IP range, anonymous proxy, risky IP
• App — Microsoft 365, Salesforce, or any connected app
• Location — country/region derived from IP geolocation
• Activity type — logon, file download, admin role change, OAuth app grant
• Device — managed vs. unmanaged, device tag

Triggers

A trigger defines when the policy fires:

• Activity matches — a single activity or a count of activities within a time window (e.g., more than 50 downloads in 60 minutes)
• Anomaly score — UEBA models assign a risk score; the policy fires when the score crosses a threshold
• File label / sensitive info type — a Microsoft Purview sensitivity label or sensitive info type is detected on a file, or the file is shared externally
• Discovered app risk score — a Cloud Discovery policy fires when a discovered app's risk score crosses a threshold or when a new app appears

Governance Actions

Governance actions define what Defender for Cloud Apps does when a policy fires. Available actions depend on the policy type and the connected app:

• Alert — create an alert with severity Low, Medium, or High
• Block — block the user, block the activity, or block the app (Cloud Discovery)
• Require MFA — require the user to re-authenticate with MFA (via Conditional Access App Control)
• Quarantine file — move a file to a quarantine location in SharePoint or OneDrive
• Revoke OAuth app — revoke a third-party OAuth app grant
• Revoke user sign-in sessions — force the user to sign in again across Microsoft 365
• Suspend user — suspend the user account in the connected app
• Sanction / unsanction app — mark a discovered app as sanctioned or unsanctioned
• Apply sensitivity label — apply a Microsoft Purview sensitivity label to a file
• Send to Power Automate — trigger a Power Automate playbook for custom response
• Notify user — send an email to the user or their manager

---

Configuring a Sample Activity Policy

To create a policy that detects mass downloads in Microsoft 365:

1. In the Defender portal, go to Policies > Policy management > Create policy > Activity policy.
2. Set a name and severity (e.g., High).
3. Under Activities matching all of the following, add filters:
   • App equals Microsoft 365
   • Activity type equals Download
4. Under Activity count, set More than 50 within 60 minutes for the same user.
5. Under Governance actions, choose Alert and Require user to sign in again (revoke sessions).
6. Save the policy. It begins evaluating the activity log immediately.

---

Anomaly Detection (UEBA)

Anomaly detection policies use User and Entity Behavior Analytics (UEBA) to baseline normal behavior for each user and peer group, then flag deviations. Built-in anomaly detections include:

• Impossible travel — sign-ins from two geographically distant locations within an impossible time window
• Activity from anonymous IP address — sign-in from a Tor exit node or anonymizer
• Frequent false positive alert dismissal — a user keeps dismissing MFA prompts
• Ransomware activity — patterns consistent with ransomware file encryption
• Suspicious inbox forwarding — a new inbox rule that forwards all mail externally
• Unusual add-in use — suspicious Exchange add-in activity

Anomaly detections are on by default for connected apps but can be tuned by adjusting the sensitivity slider and excluding user groups (e.g., service accounts).

---

OAuth App Policies

Users in Microsoft 365 and Google Workspace can consent to third-party OAuth apps that gain access to their mail, files, and calendar. OAuth app policies let you:

• Detect apps with high-risk scopes (e.g., Mail.Read, Files.ReadWrite)
• Detect apps granted by many users
• Ban an app, which revokes existing grants and blocks future consent
• Approve an app, which allows consent

This is one of the most important CASB controls for stopping consent phishing.

---

Alert Triage

When a policy fires, an alert is created and surfaced in the Alerts queue. Each alert shows the policy name, severity, related user, related app, and the activities or files that triggered it. From the alert you can:

• View similar alerts to correlate
• Open the activity in the activity log
• Apply a governance action — ban the app, revoke OAuth grant, quarantine the file, suspend the user, dismiss the alert as a false positive, or resolve it
• Send to Power Automate for orchestrated response

Alert severity (Low, Medium, High) helps prioritize. High-severity alerts typically warrant immediate investigation; low-severity alerts may be auto-resolved by tuning the policy.