Cloud Access Security Broker (CASB)

A Cloud Access Security Broker (CASB) is a security policy enforcement point positioned between cloud service consumers and cloud service providers. It acts as a gatekeeper, applying enterprise security policies as cloud-based resources are accessed. The term was coined by Gartner in 2012, and CASBs have become a cornerstone of cloud security, especially in Software as a Service (SaaS) environments like Microsoft 365, Salesforce, and Google Workspace.

The primary drivers for CASB adoption are: - Shadow IT Discovery: Employees often use unauthorized cloud services, exposing the organization to data leaks. CASBs discover and catalog these services. - Data Security: CASBs enforce data loss prevention (DLP) policies, such as blocking upload of sensitive data to personal cloud storage. - Threat Protection: They detect anomalous user behavior and compromised accounts. - Compliance: They help meet regulatory requirements (e.g., GDPR, HIPAA) by monitoring and controlling data access.

CASBs are defined by four core capabilities, often called the 'four pillars':

CASBs can be deployed in four modes, each with a different architectural approach:

#### 1. API-based Deployment In this mode, the CASB connects directly to the cloud service provider's APIs (e.g., Microsoft Graph API, Salesforce REST API). This provides out-of-band visibility and control without changing network traffic. The CASB reads logs, metadata, and content from the cloud service. For example, it can scan all files stored in SharePoint for sensitive data and quarantine those that violate policy.

Advantages: No network changes, works with mobile and off-network users. Disadvantages: Limited to what the cloud provider's API exposes; cannot block real-time traffic.

#### 2. Forward Proxy Deployment In this mode, the CASB acts as a forward proxy. User traffic is redirected to the CASB (e.g., via PAC files, browser proxy settings, or VPN). The CASB inspects all traffic in real time, applying policies before forwarding requests to the cloud service.

Advantages: Granular control over all traffic, including blocking malicious URLs or preventing uploads. Disadvantages: Requires client configuration; may introduce latency; not all protocols are supported.

#### 3. Reverse Proxy Deployment Here, the CASB sits in front of the cloud service. Users connect to the CASB's URL, which proxies requests to the actual cloud service. The user sees the cloud app, but traffic passes through the CASB. This is often used for sanctioned apps like Office 365.

Advantages: No client software needed; works for any user, anywhere. Disadvantages: Only works for pre-configured apps; may break some app features.

#### 4. Log Collection / Out-of-Band This mode relies on collecting logs from the cloud service (e.g., via syslog or SIEM integration) and analyzing them. It provides visibility but no real-time control. Often used as a stepping stone to full CASB deployment.

Without a CASB, attackers can:

A typical deployment involves: 1. Discovery Phase: Use the CASB to scan network logs or DNS traffic to identify all cloud services in use. 2. Risk Assessment: Categorize discovered apps as sanctioned, unsanctioned, or tolerated. 3. Policy Creation: Define policies for data protection, access control, and threat detection. 4. Integration: Connect the CASB to cloud providers via APIs and configure proxy forwarding. 5. Monitoring and Response: Continuously monitor alerts and respond to incidents.

Example API call to retrieve file metadata from Microsoft Graph (used by CASB):

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drive/root/children
Authorization: Bearer {access-token}

Example policy rule (pseudocode):

IF user.location == 'high-risk-country' AND app == 'Salesforce' THEN
    block access
END IF

CASB is a key component of Security Service Edge (SSE) and Secure Access Service Edge (SASE). SSE combines CASB, Zero Trust Network Access (ZTNA), and Secure Web Gateway (SWG) into a unified cloud-delivered security stack. SASE adds SD-WAN capabilities. For the exam, remember that CASB is not standalone; it often works alongside SWG and ZTNA.

Scenario 1: Shadow IT Discovery in a Mid-Sized Enterprise

A SOC analyst notices an unusual spike in outbound traffic to a unknown domain. Using the CASB dashboard, they discover that employees are using a new file-sharing service called 'FilePizza' (fictional). The CASB risk assessment shows that FilePizza has no encryption at rest and is not SOC 2 compliant. The analyst generates a report and presents it to management. The response is to block FilePizza via the CASB's forward proxy policy and educate users about approved alternatives. The common mistake here is to block the service without notifying users, causing productivity loss. The correct response is to communicate the change and provide sanctioned alternatives.

Scenario 2: Data Exfiltration via Malicious OAuth App

A user's account is compromised via phishing. The attacker uses the stolen credentials to grant an OAuth app access to the user's email and files. The CASB, monitoring API logs, detects that a new OAuth app with high permissions was granted from an unusual location. The CASB automatically revokes the app's access and alerts the SOC. The analyst then forces a password reset and enables MFA. The common mistake is to only revoke the app without resetting credentials, leaving the account vulnerable. The correct response includes both revocation and credential reset.

Scenario 3: Compliance Violation in Healthcare

A hospital uses a CASB to monitor access to its cloud-based EHR system. The CASB detects that a doctor is accessing patient records from a personal device in a country without adequate data protection laws. The CASB blocks the session and logs the incident. The compliance officer reviews the alert and initiates a training session on data handling policies. The common mistake is to ignore the alert because the doctor is a senior staff member. The correct response is to enforce policy uniformly and escalate if necessary.