CASB Guide: Visibility, Data Protection and SaaS Control

Most organisations run far more SaaS applications than their security team has approved, and the sanctioned ones hold data that leaves the network without passing any firewall. A cloud access security broker (CASB) is the control that discovers those applications, inspects what users and integrations do inside them, and applies data protection policy where the traditional perimeter cannot see. This guide explains the two ways a CASB connects (API and proxy), how shadow IT discovery actually works, how CASB DLP and session controls behave in practice, where a CASB now sits inside a security service edge (SSE) platform, and how to roll one out without breaking applications. It is written for security architects, cloud and SaaS security engineers and the people who will run the CASB day to day.

Key takeaways

• API and proxy modes solve different problems. API connectors see data at rest, admin activity and OAuth grants in sanctioned apps; proxies control live sessions, including from unmanaged devices. Most programmes need both.
• Discovery is only as good as the logs you feed it. Firewall and proxy logs miss remote users; endpoint or SSE agent telemetry closes that gap.
• Marking an app unsanctioned does not block it. Blocking needs an enforcement point: an endpoint agent, a secure web gateway or exported block lists.
• Session controls apply to browser sessions. Native desktop and mobile clients can bypass reverse proxy policy unless access policies block them.
• The CASB is a privileged non-human identity. Its API connectors usually hold admin-level tokens into your most sensitive tenants, so govern them like any other high-value credential.

What a CASB does and where it sits today

The original CASB category grew up as a standalone product between users and cloud services. Today most CASB capability is delivered as one module of an SSE or secure access service edge (SASE) platform, alongside a secure web gateway (SWG), zero trust network access (ZTNA) and shared DLP. NIST SP 800-215, Guide to a Secure Enterprise Network Landscape, places cloud services access, SWG, ZTNA and SASE in the same discussion of how enterprise network security has moved away from a single perimeter. The SASE and SSE architecture decision is covered elsewhere: see the SASE and SSE Guide. This guide focuses on what the CASB function itself must do well.

• Visibility: which cloud services are in use, by whom, from where and how much data moves to them.
• Data security: finding sensitive content stored in SaaS, controlling uploads, downloads and sharing, and applying labels or encryption.
• Threat protection: detecting compromised accounts, mass downloads, malware in cloud storage and risky third-party apps.
• Posture: many CASBs now include SaaS security posture management (SSPM) checks against benchmarks such as CIS. The configuration side is covered in the SaaS Security Guide.

"Legacy CASB" usually refers to the standalone, proxy-centric products of the mid 2010s; "next-generation CASB" is mostly a marketing term for CASB combined with SWG, inline DLP and API scanning in one policy engine. The useful question is not the label but which modes, apps and enforcement points a product actually supports.

API mode versus proxy mode

A CASB reaches cloud services in two fundamentally different ways, and the difference drives almost every design decision.

API mode (out of band)

The CASB authenticates to the SaaS provider's management APIs and pulls users, activity logs, files and app grants. Microsoft documents that its API connectors can provide account information, audit trails, account governance actions (suspend user, revoke password), visibility of issued OAuth tokens and their permissions, token removal, and file scanning both periodically (every 12 hours) and when a change is detected. Cloudflare's API CASB describes read-only, least privilege integrations that rescan typically every 1 to 24 hours and raise posture findings per asset. Coverage depends on what each provider exposes: Microsoft notes, for example, that Salesforce visibility requires Salesforce Shield, and that each service throttles API calls, so a first full scan of a large tenant can take hours or days.

Proxy mode (inline)

Traffic passes through the CASB in real time. A forward proxy intercepts traffic from managed devices, usually steered by an endpoint agent, PAC file or tunnel, and decrypts TLS with an enterprise root certificate. A reverse proxy needs nothing on the device: the identity provider redirects the sign-in through the CASB, which rewrites the application's URLs. In Microsoft's implementation, for example, the session for myapp.com becomes myapp.com.mcas.ms for non-Edge browsers, and controls apply only to interactive browser sessions for apps using SAML 2.0 or OpenID Connect sign-in.

Decision guidance: start with API mode for the three to five sanctioned apps that hold the most sensitive data (typically the office suite, file sharing, CRM and code hosting), because it gives value without touching users. Add forward proxy controls through the SSE agent for managed devices. Use reverse proxy selectively for unmanaged and third-party access to a small number of sensitive apps, where an agent is not an option. Smaller organisations can often meet most needs with the native controls of their identity provider and office suite plus API scanning; large or regulated organisations usually need all three modes and a single DLP policy engine across them.

Shadow IT discovery and app governance

Discovery matches outbound traffic against a catalogue of cloud services and scores each one. Microsoft, for instance, documents matching against a catalogue of more than 31,000 apps using more than 90 risk factors, with continuous reports refreshed four times a day. The quality of the result depends on the data sources:

• Snapshot uploads: a one-off upload of firewall or proxy logs. Useful to size the problem before buying anything.
• Log collectors: a collector on the network receives firewall and proxy logs over Syslog or FTP. Check the log level: Microsoft notes Cisco ASA must log at information level 6 for discovery to parse it.
• Endpoint telemetry: an endpoint or SSE agent reports traffic from laptops wherever they are, which is the only reliable view of remote and home workers.
• SWG integration: the secure web gateway shares logs with the CASB and enforces its block decisions. See the Secure Web Gateway and Web Filtering Guide.

Once discovered, apps are triaged as sanctioned, tolerated (monitored) or unsanctioned. Be clear about what the tag does. Microsoft's documentation states that marking an app unsanctioned does not block it by itself; blocking requires an enforcement stream such as Defender for Endpoint network protection, an integrated SWG, or a generated block script imported into a firewall or proxy. A tolerated category with user coaching ("this app is not approved, use X instead") usually reduces risky use faster than outright blocking.

The fastest growing shadow IT is now third-party apps and AI tools connected to sanctioned tenants through OAuth consent, which never appear in network logs. API mode is how a CASB sees them. The full governance process for those grants, including consent policies, publisher verification and periodic review, is covered in the SaaS and OAuth App Governance Guide, and generative AI tools specifically in the Shadow AI Discovery Guide.

Data protection: CASB DLP and session controls

CASB DLP uses the same detection types as any DLP engine (patterns, exact data match, fingerprints, sensitivity labels, trainable classifiers), applied at points other tools cannot reach. The Data Loss Prevention (DLP) Guide covers detection design; here the question is where and how the CASB enforces.

Session policies in Microsoft's implementation, as an example of the mechanics, offer four control types: monitor only, block activities, control file download (with inspection) and control file upload (with inspection). Two limits matter in every product. First, session controls only work for browser sessions: Microsoft states that session controls do not cover the Teams desktop application, and recommends access policies that block native clients so users cannot route around the proxy. Second, when content cannot be scanned (encrypted archives, oversized files), decide explicitly whether the action applies anyway; leaving the default can make policy silently fail open.

Threat protection and the identity angle

A CASB is one of the few tools that sees what an account does inside a SaaS tenant, which makes it a key detection source for credential abuse. Useful detections include impossible travel, sign-ins from anonymising VPNs, mass download or deletion, new inbox forwarding rules, and a newly consented app suddenly reading large volumes of data. Map them to ATT&CK so they can be tested: Valid Accounts: Cloud Accounts (T1078.004), Data from Cloud Storage (T1530), Exfiltration to Cloud Storage (T1567.002), Steal Application Access Token (T1528) and use of an Application Access Token (T1550.001).

Two identity points are genuine here, not decoration:

• Non-human actors dominate SaaS data access: integrations, service accounts and OAuth apps often pull more data than people do. Bulk exports by a connected app should be an alert in their own right. See the SaaS and OAuth App Governance Guide.
• The CASB's own connectors are privileged credentials: API connectors often need global or system administrator consent to read every user and file. Microsoft documents that its CASB is deployed with system admin privileges to access all objects. Record each connector token's owner, scope and expiry, restrict who can change connector settings, and alert if a connector is disabled, because that is also how an attacker would blind it.

Implementing a CASB: phased rollout

1. Baseline discovery (weeks 1 to 4): upload snapshot logs from the main egress firewalls and proxies, then deploy continuous collection and endpoint telemetry. Produce a ranked list of apps by users, data volume and risk score. Do not block anything yet.
2. Connect sanctioned apps by API: connect the highest value tenants with a dedicated, documented integration account. Run DLP and sharing policies in alert-only mode for two to four weeks and tune false positives with data owners.
3. Triage and coach: tag apps sanctioned, monitored or unsanctioned with a named business owner for each sanctioned app. Turn on warn-and-educate pages for risky categories before blocking.
4. Enforce for managed devices: through the SWG or endpoint agent, block clearly unsanctioned apps and apply upload DLP. Use pilot rings (security team, then IT, then one business unit) and keep a published exception process.
5. Add session control for unmanaged access: route only the sensitive apps that unmanaged or partner devices may reach through the reverse proxy. Start with monitor only, then block or protect downloads. Block native clients for those users at the identity provider.
6. Automate remediation: once false positive rates are acceptable, let API policies remove public links and quarantine files automatically, with owner notifications.
7. Rollback: every inline policy should be scoped by group so it can be reverted by removing the group; keep the SSO redirect to the reverse proxy in a single conditional access policy that can be disabled; keep TLS inspection bypass lists for pinned applications under change control.

For federal and regulated Microsoft 365 or Google Workspace tenants, align posture checks with CISA's Secure Cloud Business Applications (SCuBA) baselines. CISA's Binding Operational Directive 25-01 implementation guidance made the "shall" policies of the Microsoft 365 SCuBA baselines mandatory for federal civilian agencies, with the ScubaGear assessment tool used for continuous reporting. ScubaGear is open source and usable by anyone as an independent check of what a CASB's SSPM module reports.

Detection, logging and measurement

What to log: CASB alerts, policy matches and governance actions to the SIEM; connector health events (disconnected, token expired, throttled); admin changes to CASB policies; and the underlying SaaS audit logs, which remain the primary evidence during an incident.

• Discovery coverage: percentage of users and devices whose traffic reaches discovery (target: all managed endpoints, including remote).
• Sanctioned app connection rate: share of sanctioned apps holding sensitive data that are connected by API.
• Unsanctioned app usage trend: active users of unsanctioned apps per month, which should fall after coaching and blocking.
• Exposure removed: count of publicly or externally shared sensitive files, and median time from detection to remediation.
• Policy precision: percentage of DLP alerts confirmed as true positives in review; below roughly half, analysts start ignoring them.
• Unmanaged device control: share of sessions to sensitive apps from unmanaged devices that pass through session control.

Common failure patterns

• Discovery only from the office: feeding only on-premises firewall logs misses everyone working remotely, so the shadow IT report understates real usage.
• Unsanctioned in the console, open in practice: teams tag apps but never connect an enforcement point, so nothing is blocked.
• Proxy bypass through native clients: session policies are configured but desktop and mobile apps still sync files to unmanaged devices.
• Ignoring credential-based access to data platforms: in the Snowflake Breach, attackers logged in with infostealer-harvested passwords to accounts without MFA or network allow lists and bulk exported data. A CASB watching those tenants by API and alerting on unfamiliar clients and large exports is the kind of control that shortens such incidents, but it does not replace MFA.
• Treating OAuth apps as out of scope: in the ShinyHunters Salesforce Data Theft Campaign, callers persuaded staff to authorise a modified Data Loader connected app, which then pulled whole tables through the API. Alerts on new app authorisations and bulk API exports are exactly the API-mode detections that catch this.
• Over-privileged, unowned connectors: the CASB integration account is a standing global admin token nobody reviews.

Framework mapping

Practitioner checklist

• Run a snapshot discovery from egress logs and endpoint telemetry before choosing a product.
• Connect the most sensitive sanctioned SaaS tenants by API and run sharing and DLP policies in alert mode first.
• Assign a business owner to every sanctioned app and publish the sanctioned list with approved alternatives.
• Confirm that every "unsanctioned" tag has an enforcement point (agent, SWG or block list) behind it.
• Block native clients for users subject to reverse proxy session controls.
• Alert on new OAuth app authorisations with broad scopes and on bulk exports by apps or users.
• Inventory the CASB's own connector accounts and tokens with owner, scope and expiry, and alert when a connector is disabled.
• Maintain a reviewed TLS inspection bypass list for pinned applications.
• Check posture of Microsoft 365 tenants independently with ScubaGear against the SCuBA baselines.
• Report the six metrics above monthly and review policy precision with data owners.

Standards and references

• NIST: SP 800-215 Guide to a Secure Enterprise Network Landscape
• CISA: Secure Cloud Business Applications (SCuBA) Project
• CISA: BOD 25-01 Implementation Guidance, Implementing Secure Practices for Cloud Services
• CISA: ScubaGear
• NIST: Cybersecurity Framework 2.0
• Microsoft Learn: Conditional Access App Control in Defender for Cloud Apps
• Microsoft Learn: Connect apps to get visibility and control with Defender for Cloud Apps
• Cloudflare Docs: Cloud Access Security Broker

Related NHI Mgmt Group resources: SASE and SSE Guide · SASE and SSE Buyer's Guide · ZTNA Guide · SaaS Security Buyer's Guide · Remote Browser Isolation Guide