# Microsoft Defender for Cloud Apps Administration

> Chapter 73 of the Courseiva MS-102 curriculum — https://courseiva.com/learn/ms-102/microsoft-cloud-app-ms102

**Official objective:** 3.2 — Security Threats

## Introduction

How does Microsoft Defender for Cloud Apps (MCAS), a Cloud Access Security Broker (CASB), protect your SaaS applications from security threats? For the MS-102 exam, this topic appears in approximately 10-15% of questions under objective 3.2 (Security Threats). Mastering MCAS is critical because it integrates with Microsoft 365, Azure AD, and Defender for Endpoint to enforce conditional access and protect against cloud app threats. You will learn how MCAS discovers shadow IT, protects data with session policies, and detects anomalies using machine learning.

## Defender for Cloud Apps as a Security Camera System

How can a single system provide both surveillance and access control for every building on a corporate campus? The campus has multiple buildings (SaaS apps like Office 365, Salesforce, Box) with their own entry points (sign-in pages). Traditional perimeter security only watches the main gate (network firewall). MCAS deploys hidden cameras (API connectors) inside each building that record every action—who enters, what they touch, and when they leave. It also has motion sensors (conditional access app control) that can trigger automatic lockdowns if someone tries to enter a restricted area (sensitive data). The system's central monitoring station (Cloud App Security portal) correlates feeds from all buildings to detect patterns like an employee swiping into two buildings 1000 miles apart in 10 minutes (impossible travel). When a threat is detected, the system can automatically lock the person out (revoke session) or freeze the door (block download). Unlike a simple alarm, MCAS can also replay the footage (investigation) and identify which specific badge (user account) was used. This analogy directly mirrors how MCAS uses API-based monitoring for deep visibility, reverse proxy for real-time control, and anomaly detection for threat identification.

## Core explanation

### What is Microsoft Defender for Cloud Apps?

Microsoft Defender for Cloud Apps (MCAS) is a Cloud Access Security Broker (CASB) that acts as a gateway between users and cloud applications. It provides four core capabilities: discovery, protection, detection, and remediation. Unlike a simple firewall, MCAS operates at the application layer and can inspect and control traffic to sanctioned and unsanctioned cloud apps.

### Why MCAS Exists

Traditional network security perimeters are ineffective for SaaS applications because traffic often bypasses corporate networks (e.g., users accessing from home or mobile). MCAS addresses this by monitoring cloud app usage via API connectors and reverse proxy. It solves shadow IT, data exfiltration, and compromised account threats.

### How MCAS Works Internally

MCAS operates in two primary modes: **read-only** and **real-time control**. Read-only mode uses API connectors to pull activity logs and data from connected apps (e.g., Office 365, Salesforce). Real-time control uses a reverse proxy (Conditional Access App Control) to intercept and modify user sessions.

#### API Connectors

API connectors are the backbone of MCAS. They authenticate to supported apps using OAuth or app-specific tokens. Once connected, MCAS continuously fetches:
- Activities (e.g., file downloads, permission changes)
- Files and metadata
- User and device information

The default polling interval is **15 minutes** for most apps, but critical alerts can be triggered in near real-time via webhooks. For example, when a user downloads 100 files in 5 minutes, MCAS can raise an alert within seconds.

#### Conditional Access App Control (CAAC)

CAAC uses a reverse proxy architecture. When a user accesses a managed app (e.g., Salesforce), Azure AD Conditional Access routes the session through MCAS. The user's browser is redirected to MCAS's proxy, which decrypts and inspects HTTPS traffic. MCAS can then:
- Block downloads
- Mask sensitive data (e.g., credit card numbers)
- Require step-up authentication

The session is proxied using TLS interception. MCAS re-encrypts traffic with its own certificate, which must be trusted by client devices. This introduces a latency overhead of approximately **50-200 ms** per request.

### Key Components, Values, and Defaults

- **Cloud Discovery**: Uses Microsoft Defender for Endpoint or firewall logs to identify unsanctioned apps. Default data retention is **90 days**.
- **App Catalog**: Contains over **16,000** cloud apps with risk scores from 1-10.
- **Policies**: Types include activity, anomaly, file, OAuth, and session policies. Anomaly detection uses machine learning with a baseline of **14 days**.
- **Governance Actions**: Automatic actions like suspend user, revoke OAuth token, or quarantine file.
- **Integration**: Connects to Azure AD (user risk), Defender for Endpoint (device risk), and Microsoft Purview (DLP).

### Configuration and Verification Commands

To connect an API connector via PowerShell:
```powershell
Connect-MsolService
New-MsolServicePrincipal -DisplayName "MCAS-Connector" -Usage "Connector"
```

To verify MCAS integration with Azure AD:
```powershell
Get-AzureADPolicy | Where-Object {$_.Definition -like "*MCAS*"}
```

For session control, you must create a Conditional Access policy in Azure AD:
```json
{
  "conditions": {
    "applications": {
      "includedApplications": ["Salesforce"]
    }
  },
  "grantControls": {
    "builtInControls": ["mcas"],
    "authenticationStrength": "mfa"
  }
}
```

### How MCAS Interacts with Related Technologies

- **Azure AD Identity Protection**: MCAS consumes user risk scores from Azure AD. If a user is high risk, MCAS can trigger a session policy to block access.
- **Microsoft 365 Defender**: Alerts from MCAS appear in the unified security center. MCAS also shares signals like anomalous activity.
- **Microsoft Purview**: DLP policies can be applied via MCAS to prevent data exfiltration from cloud apps.
- **Defender for Endpoint**: Cloud Discovery uses MDE logs to detect shadow IT without any agent.

### Traffic Flow for Session Control

1. User attempts to access Salesforce via browser.
2. Azure AD evaluates Conditional Access policy; if MCAS is selected, user is redirected to MCAS proxy.
3. MCAS proxy establishes two TLS connections: one with user (client), one with Salesforce (server).
4. MCAS decrypts traffic, applies policies (e.g., block download), and re-encrypts.
5. User sees modified content (e.g., download button disabled).

### Key Timers and Thresholds

- **Anomaly detection baseline**: Minimum 14 days of activity required.
- **Activity policy evaluation**: Real-time for API connectors (within minutes).
- **Session timeout**: Default 60 minutes of inactivity.
- **File quarantine**: Files are moved to a quarantine folder; retention 30 days.

### Exam-Relevant Details

- MCAS supports **app-to-app** visibility for over 50 connectors.
- The **Cloud Discovery** feature can use **Microsoft Defender for Endpoint** as a data source without additional agents.
- **OAuth app policies** monitor third-party apps that have been granted permissions to Microsoft 365.
- **File policies** can detect files containing **credit card numbers** via built-in DLP.
- **IP address ranges** can be tagged as corporate or VPN to filter activities.

## Real-world context

### Scenario 1: Shadow IT Discovery at a Mid-Sized Enterprise

A company with 5,000 employees suspects employees are using unsanctioned file-sharing apps like Dropbox and WeTransfer. The network team enables Cloud Discovery by configuring the log collector to receive firewall logs from the corporate firewall (Fortinet). Within 24 hours, MCAS identifies 47 cloud apps in use, with Dropbox being the top unsanctioned app by traffic volume. The security team creates a policy to alert when any unsanctioned app with a risk score below 5 is used. They also block high-risk apps like a known malware-hosting service. The challenge is log volume: the firewall generates 10 million logs per day. The log collector must be sized with adequate CPU and memory (4 vCPU, 8 GB RAM recommended). Misconfiguration can cause log parsing failures, leading to incomplete data.

### Scenario 2: Protecting Sensitive Data in Salesforce

A financial services firm uses Salesforce to store customer PII. They enable MCAS API connector for Salesforce and create a file policy that detects files containing social security numbers (SSN). When a user downloads a file with SSN, MCAS automatically quarantines the file and alerts the security team. They also deploy session control via Conditional Access App Control to block downloads of any file tagged as 'Confidential' from unmanaged devices. Performance is a consideration: the reverse proxy adds latency, so they exempt low-risk apps from session control. A common mistake is forgetting to trust the MCAS certificate on client devices, causing TLS errors for users.

### Scenario 3: Compromised Account Detection

A user's credentials are compromised via phishing. The attacker logs in from an IP in Russia, while the user is in the US. MCAS's impossible travel policy fires because the two sign-ins occurred 30 minutes apart (distance > 500 miles). The alert is raised within minutes. The security team investigates and sees the attacker downloaded 200 files from SharePoint. They immediately use the 'Suspend user' governance action, which disables the account in Azure AD within 5 minutes. The team also revokes all OAuth tokens for that user. The key metric is alert latency: API-based detection takes up to 15 minutes, but session-based detection is real-time. In this case, the initial sign-in was via the proxy, so detection was immediate.

## Exam focus

### What MS-102 Tests on MCAS

Objective 3.2 focuses on threat protection, including MCAS. Expect questions on:
- **API connectors** vs **session control** – which provides real-time vs historical visibility.
- **Cloud Discovery data sources** – specifically that MDE can be used without additional agents.
- **Anomaly detection policies** – default baseline period of 14 days.
- **Governance actions** – what actions are available (suspend user, revoke token, quarantine file).
- **Integration** – how MCAS consumes Azure AD risk scores.

### Common Wrong Answers and Why Candidates Choose Them

1. **'MCAS can block downloads from any app without configuration.'** – Wrong. Session control requires Conditional Access policy in Azure AD and a session policy in MCAS. Candidates assume it's automatic.
2. **'Cloud Discovery requires a log collector.'** – Wrong. MDE is a built-in data source that requires no log collector. Candidates overlook this.
3. **'Anomaly detection works immediately after enabling MCAS.'** – Wrong. It needs a 14-day baseline. Candidates think it's instantaneous.
4. **'Session control works with any cloud app.'** – Wrong. Only apps that support SAML or OIDC and are registered in Azure AD can be proxied. Candidates think it's universal.

### Specific Numbers and Terms to Memorize

- **14 days**: Minimum data for anomaly baseline.
- **90 days**: Default data retention for Cloud Discovery.
- **16,000+**: Apps in the cloud app catalog.
- **50+**: Supported API connectors.
- **OAuth app policies**: Monitor third-party app permissions.
- **Impossible travel**: Requires two sign-ins within a configurable time and distance.

### Edge Cases and Exam Traps

- If a user accesses a sanctioned app from an unmanaged device, session control can block downloads, but API-based policies cannot block in real-time.
- Anomaly detection may generate false positives for users who travel frequently; you can create exceptions by IP ranges.
- MCAS does NOT support on-premises apps; it is cloud-only.
- Governance actions are asynchronous; they may take up to 30 minutes to propagate.

### How to Eliminate Wrong Answers

- If a question mentions 'real-time blocking', look for session control or Conditional Access App Control.
- If it mentions 'historical analysis', look for API connectors.
- If it asks about 'shadow IT' without agents, look for MDE integration.
- If it asks about 'third-party app permissions', look for OAuth app policies.

## Step by step

1. **Connect API Connector to App** — Navigate to the MCAS portal, select 'Connect apps', then choose the app (e.g., Office 365). Follow the wizard to authenticate using Global Admin credentials. MCAS will request OAuth permissions to read activities, files, and user accounts. This step is one-time per app. After connection, MCAS immediately begins pulling data. The initial sync may take 1-2 hours for large tenants. Verify by checking the 'Connected apps' list for a green status indicator.
2. **Enable Cloud Discovery** — In MCAS, go to 'Cloud Discovery' and select data sources. You can upload firewall logs, use Microsoft Defender for Endpoint, or install the Cloud Discovery log collector. The log collector is a Docker container that parses logs and sends them to MCAS. It supports Cisco, Fortinet, and other major firewalls. After data flows, MCAS builds a shadow IT report showing top apps, users, and traffic volume. The report updates every 2 hours by default.
3. **Create Anomaly Detection Policy** — Go to 'Policies' > 'Policy management' > 'Create policy' > 'Anomaly detection policy'. Choose a template like 'Impossible travel' or 'Activity from anonymous IP'. Configure parameters: for impossible travel, set minimum distance (e.g., 500 miles) and time window (e.g., 2 hours). The policy triggers if two sign-ins from different locations occur within the window. MCAS uses machine learning to baseline normal user behavior over 14 days. Test by simulating a login from a different region.
4. **Configure Session Policy** — In Azure AD, create a Conditional Access policy that includes the target app (e.g., Salesforce) and grant control 'Use Conditional Access App Control'. Then in MCAS, go to 'Policies' > 'Session policies' and create a new policy. Choose 'Control file download' and set action to 'Block'. Also configure session monitoring to log all activities. When user accesses Salesforce, they are redirected through MCAS proxy. Verify by attempting to download a file; it should be blocked.
5. **Investigate and Remediate Alert** — When an alert fires (e.g., mass download), go to 'Alerts' in MCAS. Click on the alert to view details: user, app, IP, and activity timeline. Use the 'Activity log' to see all actions from that user. Remediate by selecting 'Govern' > 'Suspend user' or 'Revoke OAuth token'. MCAS sends the action to the connected app via API. For example, suspending a user in Salesforce disables their account. Document the incident in the 'Investigation' tab.

## Comparisons

### API Connectors vs Session Control (Reverse Proxy)

**API Connectors:**
- Provides historical visibility into activities and files.
- Polls data every 15 minutes (non-real-time).
- Can apply governance actions (suspend user, quarantine file).
- Works even when user is offline; uses app APIs.
- Supports over 50 apps (e.g., Salesforce, Box).

**Session Control (Reverse Proxy):**
- Provides real-time control of user sessions.
- Intercepts HTTPS traffic via reverse proxy (50-200 ms latency).
- Can block downloads, mask data, require MFA.
- Only works when user is actively connected via the proxy.
- Works with any SAML/OIDC app registered in Azure AD.

## Common misconceptions

- **Misconception:** MCAS can block all cloud app traffic at the network level. **Reality:** MCAS operates at the application layer and controls traffic via reverse proxy or API. It cannot block traffic at the network layer like a firewall. To block unsanctioned apps at the network level, you need a web proxy or firewall.
- **Misconception:** Cloud Discovery only works with firewall logs. **Reality:** Cloud Discovery can also use Microsoft Defender for Endpoint logs, which require no additional infrastructure. This is a common exam distinction.
- **Misconception:** Session control policies apply to all apps automatically once enabled. **Reality:** Session control must be explicitly configured per app via a Conditional Access policy in Azure AD and a session policy in MCAS. Only apps added to the policy are proxied.
- **Misconception:** Anomaly detection policies are based on a 7-day baseline. **Reality:** The default baseline is 14 days. This is a specific number that appears on the exam.
- **Misconception:** MCAS can prevent data exfiltration from on-premises file servers. **Reality:** MCAS is designed for cloud apps only. For on-premises, you need Microsoft Purview or Defender for Identity.

## Key takeaways

- MCAS is a CASB that provides visibility and control over SaaS apps via API connectors and session control.
- Cloud Discovery can use Microsoft Defender for Endpoint logs without additional agents.
- Anomaly detection policies require a minimum of 14 days of data to establish a baseline.
- Session control requires both a Conditional Access policy in Azure AD and a session policy in MCAS.
- Governance actions include suspend user, revoke OAuth token, and quarantine file.
- MCAS integrates with Azure AD Identity Protection to consume user risk scores.
- The cloud app catalog contains over 16,000 apps with risk scores.
- File policies can detect sensitive data using built-in DLP classifiers like credit card numbers.

## FAQ

**What is the difference between MCAS and Azure AD Conditional Access?**

Azure AD Conditional Access is the policy engine that enforces access controls (like MFA) at sign-in. MCAS extends this by providing deep session controls (like blocking downloads) and continuous monitoring after sign-in. MCAS also offers shadow IT discovery and anomaly detection that Conditional Access alone cannot provide.

**How do I enable session control for an app?**

First, in Azure AD, create a Conditional Access policy that includes the app and select the grant control 'Use Conditional Access App Control'. Then, in MCAS, go to 'Policies' > 'Session policies' and create a policy with the desired controls (e.g., block download). The app must support SAML or OIDC and be registered in Azure AD.

**Can MCAS monitor unsanctioned apps?**

Yes, via Cloud Discovery. MCAS can identify unsanctioned apps from firewall logs or MDE logs. You can then sanction or block them. However, MCAS cannot apply session control to unsanctioned apps unless they are added to Azure AD as enterprise apps.

**What is the default data retention for Cloud Discovery?**

The default is 90 days. You can configure it up to 180 days. After the retention period, data is purged.

**How does MCAS detect compromised accounts?**

MCAS uses anomaly detection policies like impossible travel (two sign-ins from distant locations within a short time) and activity from anonymous IPs. It also consumes user risk scores from Azure AD Identity Protection. When an anomaly is detected, it generates an alert.

**What governance actions can MCAS take?**

Actions include suspend user, revoke OAuth token, quarantine file, and require user to reset password. These actions are sent via API to the connected app. Not all apps support all actions; check the app's documentation.

**Does MCAS support on-premises apps?**

No. MCAS is designed for cloud apps. For on-premises, use Microsoft Defender for Identity or Azure Application Proxy.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/ms-102/microsoft-cloud-app-ms102