CASB Explained: — Governing the SaaS and Shadow IT You Cannot See

① The shadow-IT problem — the SaaS you cannot see

Meet Priya, an L1 security analyst at Flipkart. Her firewall and SWG are clean: malware blocked, bad URLs filtered, every laptop reporting in. Then an audit asks one question she can't answer: which cloud apps is the company actually using? She assumed maybe 30. The CASB discovery report comes back with 340 — free PDF converters, AI writing tools, personal Dropbox and Google Drive accounts, a no-name file-sharing site an intern found on Google. None of them went through IT. That gap is Shadow IT.

Why does it happen? Not malice — friction. Signing up for a SaaS app is a credit-card-free, two-minute act: an email address and a password and you're in. An employee at TCS on a deadline pastes a client contract into a free online PDF tool to compress it; an intern at Zomato drops the pricing sheet into a personal Google Drive to 'finish at home'. No download, no executable, no alarm — and yet corporate data has just left the building into an app IT never sanctioned and cannot govern.

Here is the uncomfortable part for a network person: your perimeter controls don't help. A firewall sees an IP and a port; an SWG can block you from reaching a sketchy site, but it is blind to what happens inside an app you allow. Once a user is logged into a sanctioned Google Workspace or Microsoft 365 tenant, the SWG just sees encrypted HTTPS to google.com — it cannot tell a normal save from a customer list being shared to an external Gmail. Cloud broke the old model: the data isn't on your network any more, it's in someone else's.

A CASB (Cloud Access Security Broker) is the answer. The name says it: it brokers — it sits as a control point between your users and the cloud apps, and it gives you the two things the perimeter lost: visibility (every app in use, sanctioned or shadow, risk-scored) and control (policy on what data can move where). It is the SASE/SSE building block that governs the SaaS layer — the layer your firewall was never designed to see.

② The 4 CASB pillars — Visibility, Compliance, Data Security, Threat Protection

Gartner, who coined the term, frames every CASB around four pillars. Learn them as four jobs, not four products — a single CASB does all four. They are Visibility, Compliance, Data Security and Threat Protection. Walk through each with the question it answers.

Pillar 1 — Visibility. The question: what cloud apps are we actually using, and how risky is each one? The CASB does Cloud Discovery — it ingests your firewall and proxy logs and produces a list of every app touched, then assigns each a risk score based on its certifications, encryption, breach history and data-residency. Now Priya's 340 apps become a ranked list: sanction the good, coach users off the risky, block the worst.

Pillar 2 — Compliance. The question: does our cloud use satisfy the rules we're bound by? An Indian fintech under RBI rules, a hospital under data-protection law, a card processor under PCI DSS — each has constraints on where data may live (data residency) and what may be exposed. The CASB enforces and reports on this: flag any app storing regulated data in the wrong region, alert on a card number sitting in a public link.

Pillar 3 — Data Security. The question: is our sensitive data protected inside the cloud? This is DLP on cloud data — detecting a PAN/Aadhaar number, an 'Internal-Confidential' label, source code; plus encryption / tokenisation so the SaaS only ever holds a useless surrogate. This is the pillar that stops the pricing sheet leaving.

Pillar 4 — Threat Protection. The question: is someone abusing our cloud accounts or hiding malware in them? The CASB watches for account takeover (impossible-travel logins, a login from Mumbai then Brazil ten minutes later), and scans cloud storage for malware sitting in a shared OneDrive folder waiting to be opened. It's the anti-abuse pillar.

The four pillars, one tap each

Tap each card. This is the exact list a CCSP question or an interviewer will expect you to recite cold.

③ Inline vs API (out-of-band) — block live, or scan at rest

A CASB can connect to your cloud world two completely different ways, and the single most-tested fact about CASB is knowing both. The first is inline; the second is API (out-of-band). They are not rivals — mature deployments run both. Let's take them one at a time.

Inline mode — sit in the live path, act in real time

Inline means the CASB is in the path of the traffic, as a proxy, so it can block a transaction the instant it happens — the moment a user clicks 'upload' to a personal drive, the proxy can deny it before a single byte lands. There are two flavours. A forward proxy steers traffic from the user side (an endpoint agent or a tunnel), so it sees every app — sanctioned and shadow — but needs the device to be managed/steered. A reverse proxy steers from the app side via the identity provider (SAML), so even an unmanaged BYOD phone is forced through the CASB for a chosen sanctioned app — without installing anything on the device. That last point is the reverse proxy's whole reason to exist.

API mode — talk to the SaaS, scan what is already there

API mode (also called out-of-band) doesn't sit in the path at all. The CASB connects to the SaaS using the app's own admin API — you grant it OAuth access to your Microsoft 365 or Box tenant — and from there it can scan data-at-rest (every file already sitting in OneDrive), retro-inspect history (find the card number someone made public last month, before the CASB even existed), and fix it (revoke the public link, apply a label, quarantine the file). Because it's off-path, it adds zero latency to users — but it's not real-time: it acts a beat after the event, and only on sanctioned apps whose API it has access to.

{
  "policy": "block-confidential-external-download",
  "applies_to": { "apps": ["Office365", "GoogleDrive", "Box"] },
  "match": {
    "sensitivity_label": "Confidential",
    "content_dlp": ["PAN", "Aadhaar", "PCI-card"]
  },
  "condition": {
    "device_state": "unmanaged",
    "action": "download"
  },
  "enforce": { "mode": "inline", "do": "block", "notify_user": true }
}

policy 'block-confidential-external-download' compiled OK
  scope: 3 apps · inline (reverse-proxy) for unmanaged devices
  match: label=Confidential OR dlp{PAN,Aadhaar,PCI-card}
  action on download from unmanaged: BLOCK + user coaching page
status: ENABLED — 0 matches (last 24h)

④ CASB in SSE — sharing the stream with SWG + DLP, real policy & gotchas

CASB doesn't live alone. In a SSE platform it sits beside the SWG (from the last lesson) and shares one decrypted stream. When the SWG already terminates TLS to inspect web traffic, it hands that same decrypted view to the CASB engine — so the CASB can identify the app, the user and the action without decrypting twice. DLP is then a shared engine on top: one set of detectors (PAN, Aadhaar, 'Confidential' label) that the SWG uses on web uploads and the CASB uses on SaaS sharing alike. That sharing is the whole efficiency of SSE — decrypt once, let every module read it.

Concretely, a real policy reads like an English sentence built from those shared parts: "block download of files labelled Confidential to unmanaged devices." CASB supplies the app + device-state context (it knows this is M365 on an unmanaged BYOD phone via the reverse proxy), DLP supplies the content/label match (the file is 'Confidential'), and the SWG/proxy supplies the enforcement point (it's in the path to deny). No single box could write that rule — it's the integration that makes it possible.

Now the production gotchas — the things that turn a clean demo into a 2 a.m. ticket. Gotcha 1: API coverage gaps. API mode only works for SaaS apps that expose a rich admin API and that you've connected — M365, Google Workspace, Box, Salesforce are well covered; that niche app the marketing team loves may expose nothing, so its data-at-rest is invisible to your CASB. Gotcha 2: app sprawl. Discovery routinely finds hundreds of apps; you cannot sanction or block all of them by hand, and over-blocking just pushes users to worse workarounds. Gotcha 3: API rate limits. Out-of-band scanning calls the SaaS API constantly — vendors throttle it (Netskope's data-protection API, for instance, returns HTTP 429 past roughly 300 requests/minute per token), so a huge retro-scan can lag for hours. Gotcha 4: certificate pinning (from sec3) — some apps refuse inline decryption outright, so you must cover them by API instead.

For your CCSP path, CASB sits squarely in Domain 4 — Cloud Application Security (17% of the exam). The exam expects you to define a CASB, recite the four pillars, and crucially distinguish proxy (inline) from API deployment and say when each fits — the exact distinction you just learned. It also threads into the SSE/SASE topics across the cloud-security blueprint. Nail inline-vs-API and the pillars and you own the CASB questions cold.