Cloud Access Security Brokers (CASB) Explained

Cloud Access Security Brokers (CASBs) occupy a defined control point between enterprise users and cloud service providers, enforcing security policy across sanctioned and unsanctioned cloud applications. This page covers the functional definition, technical architecture, deployment modes, regulatory alignment, and organizational decision criteria for CASB adoption. The sector spans government, healthcare, financial services, and any regulated industry where cloud data flows cross compliance boundaries.

Definition and scope

A CASB is a software-based enforcement gateway — on-premises, cloud-hosted, or hybrid — that intercepts traffic between cloud consumers and cloud providers to apply visibility, compliance, data security, and threat protection controls. The term was formally categorized by Gartner in 2012, and CASB capabilities are now addressed within NIST SP 800-210, "General Access Control Guidance for Cloud Systems", which establishes access control guidance applicable to infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) environments.

CASB scope extends across four functional pillars recognized across the industry:

  1. Visibility — Discovery and classification of all cloud services in use, including shadow IT applications not approved by IT governance
  2. Compliance — Policy enforcement aligned to frameworks such as HIPAA (45 CFR Part 164), PCI DSS, and SOC 2 requirements
  3. Data security — Application of data loss prevention (DLP) policies, encryption, and tokenization to data at rest and in transit
  4. Threat protection — Detection of anomalous user behavior, compromised accounts, and malware propagation through cloud storage services

The Cloud Security Alliance (CSA) Security Guidance, version 4.0, positions CASBs within the broader enterprise cloud risk management architecture, particularly where identity and access management in cloud environments intersects with data sovereignty requirements.

How it works

CASBs operate through three primary deployment architectures, each with distinct traffic interception mechanisms:

API-based mode connects directly to cloud service provider APIs (such as Microsoft Graph or Salesforce REST APIs) to inspect data at rest, audit configuration states, and enforce policy without sitting inline with user traffic. This mode supports retroactive scanning and is non-disruptive to user sessions, but it cannot intercept real-time uploads in transit.

Forward proxy mode routes outbound user traffic through the CASB before it reaches the cloud service. This is typically implemented via agent-based endpoint configuration or PAC file deployment and enables real-time blocking of unauthorized uploads, DLP policy application to in-transit data, and session-level controls.

Reverse proxy mode intercepts inbound traffic from users to cloud applications without requiring an endpoint agent. Access is routed through the CASB regardless of device type, making this the preferred model for unmanaged or bring-your-own-device (BYOD) environments.

Modern enterprise deployments frequently combine all three modes — a multimode architecture — to achieve coverage across managed endpoints, unmanaged devices, and cloud-resident data stores simultaneously. The shared responsibility model defines the boundary at which a cloud provider's native controls end and customer-side enforcement — including CASB — begins. CASB sits definitionally within the customer's zone of responsibility for access governance, data classification, and user activity monitoring.

Policy enforcement within a CASB follows a structured sequence:

  1. Traffic or API event is intercepted and logged
  2. User identity and device posture are evaluated against directory services (e.g., Active Directory, SCIM-provisioned IdP)
  3. Data content is inspected against DLP rule sets and sensitivity labels
  4. Activity is scored for behavioral anomaly against a baseline (UEBA component)
  5. Policy action is applied: allow, block, encrypt, alert, or quarantine

Common scenarios

Regulated data exfiltration prevention — Healthcare organizations subject to HIPAA enforcement by the HHS Office for Civil Rights deploy CASBs to prevent protected health information (PHI) from being uploaded to unauthorized SaaS applications or personal cloud storage accounts. DLP policies tied to PHI classifiers trigger real-time blocks on data egress.

Shadow IT discovery — Enterprises with distributed workforces find unsanctioned application usage constitutes a measurable share of cloud traffic. CASB visibility tools enumerate application risk scores against databases maintained by providers, supporting cloud misconfigurations risk assessments and formal sanctioning decisions.

FedRAMP-adjacent compliance — Federal contractors and agencies operating under the Federal Risk and Authorization Management Program (FedRAMP) use CASBs to extend continuous monitoring requirements from the agency ATO boundary into SaaS environments not natively covered by a FedRAMP-authorized CSP. This aligns with controls under NIST SP 800-53, Revision 5, specifically the AC (Access Control) and AU (Audit and Accountability) control families (NIST SP 800-53 Rev 5).

Zero trust enforcement — CASBs serve as a conditional access enforcement point within zero trust architecture frameworks, blocking or limiting cloud application sessions based on real-time device compliance status, geolocation, and risk signals rather than network perimeter position.

Decision boundaries

CASB adoption is most clearly justified when an organization's cloud application portfolio exceeds what native cloud provider controls can uniformly govern. The key differentiation criteria include:

CASB vs. Secure Web Gateway (SWG) — SWGs focus on general web traffic filtering and URL categorization. CASBs provide application-layer intelligence, SaaS-specific policy objects, and data-level controls that SWGs do not offer. For environments with significant SaaS adoption, CASB provides governance depth that SWG cannot replicate.

CASB vs. CSPM — Cloud Security Posture Management addresses IaaS and PaaS misconfiguration risk at the infrastructure level. CASB operates at the access and data layer, primarily covering SaaS interactions and user-to-cloud data flows. The two functions are complementary, not substitutable.

Organizations under active regulatory examination — including those subject to SEC cybersecurity disclosure rules (17 CFR Part 229 and 249) or FTC data security requirements — face documented expectations for cloud access visibility and control that CASB architectures are specifically designed to satisfy. Procurement decisions should be evaluated against the CSA Cloud Controls Matrix (CCM), which maps CASB-relevant controls to ISO/IEC 27001, NIST CSF, and PCI DSS simultaneously.

The depth of CASB integration with an organization's broader cloud compliance frameworks and cloud data protection strategies determines whether a CASB functions as a point solution or a foundational component of enterprise cloud governance.

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator