# CASB Explained: — Governing the SaaS and Shadow IT You Cannot See Source: https://ai.techclick.in/blog_casb_cloud_security_broker Markdown: https://ai.techclick.in/blog_casb_cloud_security_broker.md Publisher: Techclick Infosec Pvt Ltd CASB (Cloud Access Security Broker) for L1/L2 engineers and CCSP: the shadow-IT problem, the 4 CASB pillars, inline (proxy) vs API (out-of-band) mode, reverse proxy for BYOD, and how CASB fits in SSE with SWG + DLP. CASB Explained: — Governing the SaaS and Shadow IT You Cannot See student learning map A visual study map for CASB Explained: — Governing the SaaS and Shadow IT You Cannot See showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP CASB Explained: — Governing the SaaS and Shadow IT... SASE · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The shadow-IT problem — the SaaS... 4. Practice ② The 4 CASB pillars — Visibility,... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers hear 'CASB' and picture 'just a firewall for cloud apps' — one box in the path that blocks the bad SaaS sites and waves the good ones through. So they treat it like a URL filter with a cloud sticker. Wrong — and that mental model misses the whole point. A firewall or SWG can stop you reaching random Dropbox, but it is blind inside your sanctioned Google Workspace or M365 tenant. CASB's actual job is to govern the SaaS you do allow — who shares what file with whom, whether a Confidential document can be downloaded to an unmanaged laptop, and to scan the data already sitting at rest in the cloud. It does this two ways at once: inline (a proxy in the live path that can block in real time) and API (out-of-band, talking to the SaaS's own API to inspect data-at-rest and fix old leaks). It is a data-and-identity control point, not a website blocklist. ## ① 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. 👉 So far: 30 apps you knew about, 340 you didn't, and perimeter tools that can't see inside any of them. Next: the control point that closes that gap. 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. Figure 1 — A firewall guards the gate; data still walks out the side door of every SaaS app On the left a user inside the corporate office. A blue firewall and SWG inspect the obvious outbound web path. But arrows lead sideways from the user to a cluster of SaaS apps: a sanctioned Microsoft 365 and Google Workspace tenant in blue that the firewall cannot see inside, and a red cluster of shadow IT apps — personal Google Drive, a free PDF converter, an unknown AI tool — that IT never approved. A central data file leaks into both. An amber CASB box sits between the user and all the cloud apps as the new control point that gains visibility and control over the side doors. The perimeter holds the gate — the data leaks out the side User · Flipkart managed laptop pricing.xlsx Firewall + SWG inspects the obvious web path - Sanctioned SaaS M365 · Google Workspace firewall is blind INSIDE Shadow IT (340 apps) personal Drive · free PDF tool unknown AI tool · file-share site no IT approval, no oversight CASB the new control point visibility + control data path now goes via CASB sanctioned shadow — discovered + risk-scored Key idea: the firewall guards the gate, the CASB governs every SaaS side door untrusted / shadow IT trusted / inspected policy / decision key insight allowed Read left to right: the firewall/SWG (blue) inspects the obvious path, but the user's data leaks sideways into sanctioned AND shadow SaaS (red) where the perimeter is blind. The CASB (amber) is the new control point that finally sees those side doors. Daily-life analogy — the society gate register vs the side gate Think of your apartment society. The main gate guard (the firewall/SWG) checks everyone who drives in the front. But there's a side gate the delivery boys use, and nobody writes them in the register — that's shadow IT. A CASB is hiring a second guard who watches every gate, keeps a register of who carried what in and out (visibility), and is allowed to say 'that parcel of company papers does not leave through the side gate' (control). The front guard alone gives you a false sense of safety. Pause & Predict Predict: your SWG already blocks malware and bad URLs perfectly. Name ONE data-loss event it still cannot stop inside a sanctioned, allowed app like Google Workspace. Type your guess. Reveal answer Answer: It cannot stop a logged-in user sharing a confidential file to an external personal Gmail (or making it 'anyone with the link'). The SWG sees encrypted HTTPS to an allowed domain and waves it through — it has no idea the payload is a customer list going outside the org. That share happens inside the app, at the data/identity layer, which is exactly the blind spot CASB exists to cover. Quick check · Q1 of 10 Aditya at HCL says: "We have a great firewall and SWG, so we don't need a CASB." What is the flaw in that reasoning? a) The firewall and SWG can see inside encrypted SaaS sessions and govern file sharing, so a CASB is redundant b) A CASB only blocks websites, which the SWG already does c) The SWG is blind to what happens inside a sanctioned SaaS app — like a confidential file being shared externally — which is the data/identity layer a CASB governs d) A CASB replaces the firewall entirely, so he should remove the firewall Correct: c. The SWG inspects the path to a site but can't govern actions inside an allowed SaaS tenant — sharing, downloading to BYOD, data-at-rest. That SaaS data/identity layer is exactly what CASB adds. CASB doesn't merely block websites (that's the SWG's job), and it complements — not replaces — the firewall. ## ② 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. 👉 So far: four pillars — discover & score (Visibility), satisfy the rules (Compliance), protect the data (Data Security), catch abuse (Threat Protection). Next, see them on one card and test them. Figure 2 — One CASB, four jobs — discover, comply, protect, defend Four large tiles arranged in a two-by-two grid, each a CASB pillar. Tile one Visibility: discover sanctioned and shadow apps and risk-score them via cloud discovery. Tile two Compliance: enforce data residency and regulatory rules like PCI and report violations. Tile three Data Security: DLP on cloud data plus encryption and tokenisation to stop sensitive data leaving. Tile four Threat Protection: detect account takeover via impossible-travel and scan cloud storage for malware. A centre badge stresses that all four are one CASB control point. The four CASB pillars — one control point, four angles 1 · Visibility Q: which apps are we using, how risky? Cloud Discovery from firewall/proxy logs → risk-score every sanctioned + shadow app 30 known → 340 found, ranked by risk 2 · Compliance Q: do we satisfy the rules we're bound by? data residency · PCI / RBI / privacy law → flag regulated data in the wrong region report + alert, not just block 3 · Data Security Q: is our sensitive data protected? DLP: PAN / Aadhaar / 'Confidential' label + encryption / tokenisation of cloud data the pillar that stops the file leaving 4 · Threat Protection Q: is someone abusing our accounts? account takeover: impossible-travel login + scan cloud storage for malware the anti-abuse pillar ONE CASB Four tiles, each a pillar with the question it answers and one real feature. Notice all four are the SAME CASB control point looking at the SAME cloud traffic from four angles — not four separate tools. ### 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. 🔍 Visibility tap to flip Discover every sanctioned + shadow app from logs and risk-score it. So: you finally know your real cloud footprint, not the 30 you assumed. 📋 Compliance tap to flip Enforce + report on data residency and regs (PCI, privacy law). So: regulated data stays where the law says, and you can prove it. 🔐 Data Security tap to flip DLP on cloud data + encryption/tokenisation. So: a Confidential file or PAN number can't quietly leave or over-share. 🛡️ Threat Protection tap to flip Catch account takeover (impossible-travel) + malware in cloud storage. So: a stolen login or a planted file gets flagged fast. Pause & Predict Predict: a hospital in Pune must keep patient records inside India. A doctor starts using a free US-hosted note app. Which TWO CASB pillars light up, and what does each do? Type your guess. Reveal answer Answer: Visibility flags the new shadow app (a US-hosted, unsanctioned note tool) and risk-scores it. Compliance is the second: it detects that regulated health data would now sit outside India, breaching data-residency law — so it alerts (and can block) before patient data lands in the wrong region. Data Security/DLP may also trigger if patient identifiers are detected in the content. Quick check · Q2 of 10 Karthik at ICICI gets a CASB alert: a user logged in from Mumbai at 10:00, then the same account logged in from Brazil at 10:08. Which pillar caught this and what is it called? a) Visibility — it discovered a new shadow app b) Compliance — a data-residency violation c) Data Security — a DLP match on a file d) Threat Protection — an impossible-travel sign of account takeover Correct: d. Two logins from cities you can't physically travel between in 8 minutes is the classic impossible-travel indicator of account takeover — the Threat Protection pillar (behaviour analytics). Visibility is app discovery, Compliance is residency/regs, Data Security is DLP on content — none of those describe an anomalous login. ## ③ 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. 👉 So far: inline blocks live (forward = all apps/managed, reverse = BYOD/one app), API scans data-at-rest off-path after the fact. Next: why you need both, drawn out. Figure 3 — Inline blocks the upload as it happens; API cleans up what already leaked Two horizontal lanes comparing CASB modes. Top lane labelled Inline: a user uploads a file, the arrow passes through an amber CASB proxy that is in the path, which blocks the upload to a personal drive in real time before it reaches the SaaS. Bottom lane labelled API out-of-band: the same CASB connects via the SaaS admin API directly to the cloud app, off the user path, to scan files already stored at rest and revoke a public link that leaked earlier. A note stresses inline equals real-time block, API equals retro scan with zero added latency, and you usually run both. Inline vs API — block live, or scan at rest INLINE (proxy, in the path) User uploads pricing.xlsx CASB proxy decides in real time Personal Drive unsanctioned ✗ BLOCKED before any byte lands API (out-of-band, off the path) CASB OAuth admin API Sanctioned SaaS OneDrive · Box (data-at-rest) old public link found scan at rest · retro-inspect · revoke link zero added latency — but acts a beat AFTER the event Key insight: inline = stop it now; API = clean up what already slipped — run both Top lane (inline, blue/amber): the upload passes THROUGH the proxy, which blocks it in real time. Bottom lane (API, green): the CASB talks to the SaaS API off-path to scan files already at rest and revoke an old public link. Same CASB, two reaches. ### ▶ Watch one risky share — caught two different ways Neha at PhonePe tries to make a Confidential deck 'anyone with the link'. Follow how inline catches it live, and how API would have caught it if it had already happened. Press Play for the healthy path, then Break it to see the failure. ① User action Neha sets Q3-strategy.pptx sharing to anyone-with-link (external) ▼ ② Inline sees it request passes through the CASB proxy ; DLP matches the 'Confidential' label live ▼ ③ Real-time block proxy returns deny — the external share never takes effect, user sees a coach page ▼ ④ API safety net for files that pre-date the proxy, API scan finds the old public link and revokes it Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Microsoft Defender Portal → Cloud Apps → Policies → Policy management → Information Protection → Create policy → File policy . (Recreated for clarity — your console matches this.)"> 🖥️ This is the screen you'll use to build the DLP rule — Microsoft Defender Portal → Cloud Apps → Policies → Policy management → Information Protection → Create policy → File policy . (Recreated for clarity — your console matches this.) security.microsoft.com · Cloud Apps · Policies · Policy management · File policy 1 Policy name Block external share of Confidential files 2 Policy severity High 3 Category DLP Filter — Access level External / Public 4 Content inspection method Data Classification Services Sensitivity label Confidential 5 Governance action Remove external users / Make private Create CASB DLP file-policy intent (vendor-neutral JSON — the kind of rule the GUI compiles) { "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 } } Expected output 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) Common mistake — "the CASB blocked our access to a sanctioned app it should allow" Symptom: after turning on inline reverse proxy for a SAML app, users get login loops or a broken app. Cause is almost always that the proxy must re-sign the SAML assertion (it rewrites the IdP response so the session is steered through the CASB) and that option wasn't enabled, or the IdP's reply URL still points straight at the app and bypasses the proxy. Fix: enable Re-Sign SAML Assertions on the reverse-proxy app config and point the IdP's ACS/reply URL at the CASB's proxy URL, not the app's native URL. Separately, a certificate-pinned app (it hard-codes the real server's cert) will refuse the proxy's cert entirely — for those, inline can't decrypt, so you cover them with API mode instead. Sneha at Infosys faces this Sneha, an L1 analyst, gets a ticket: a contractor on an unmanaged personal laptop can log into the corporate Microsoft 365 tenant fine, but the CASB DLP rule meant to block downloading 'Confidential' files to that device never fires — the contractor downloaded a labelled deck anyway. Likely cause The contractor's device is unmanaged, so the forward-proxy agent (which only runs on managed devices) isn't in the path. The reverse proxy — the mode meant for unmanaged BYOD — was configured but the M365 app wasn't actually steered through it: the IdP reply URL still pointed at the native login.microsoftonline.com, so the session bypassed the CASB and DLP never saw the download. Diagnosis She separates the two reaches: managed-device traffic uses the forward-proxy agent; unmanaged BYOD must be forced through the reverse proxy via SAML. She checks whether this session ever traversed the CASB at all (it didn't), then checks the IdP app's reply/ACS URL and the Re-Sign SAML Assertions toggle. Microsoft Defender Portal → Cloud Apps → Conditional Access App Control (or Netskope → Settings → Reverse Proxy → App config → Re-Sign SAML Assertions) Fix Point the IdP's reply/ACS URL for the M365 app at the CASB reverse-proxy URL and enable Re-Sign SAML Assertions, so every BYOD session is steered through the CASB. Add a session policy: device-state = unmanaged AND label = Confidential AND action = download → block. Verify Re-test from the unmanaged laptop: login still works, but downloading a Confidential file now returns the CASB block/coach page; the policy shows a match in the activity log. Pause & Predict Predict: an attacker steals a Drift-style OAuth token your tenant granted to a third-party app. Which CASB mode is positioned to even SEE that, and why does inline-only miss it? Type your guess. Reveal answer Answer: API/out-of-band mode is the one that can see it: it inventories the OAuth grants and third-party app connections to your SaaS tenant and can flag a token doing bulk data exports. Inline-only misses it because the attacker isn't going through your proxy at all — they call the SaaS API directly with the stolen token, off your network path. This is exactly the 2025 Salesloft Drift breach pattern: stolen OAuth tokens, direct API access, no user traffic to inspect inline. Quick check · Q3 of 10 Arjun at Airtel needs to retroactively find and unshare every file that was made public in the company OneDrive over the last 3 months — including before the CASB was bought. Which mode does this, and why can't the other? a) Inline forward proxy — it inspects all live traffic b) Inline reverse proxy — it steers BYOD sessions c) Neither — old files can never be found d) API (out-of-band) mode — it scans data-at-rest via the SaaS API and can retro-inspect history Correct: d. API mode connects to the SaaS's own API and scans data already stored, including history from before deployment — perfect for finding and revoking old public links. Inline modes (forward/reverse) only see traffic happening live in the path now, so they can't reach back to files shared months ago. ## ④ 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. 👉 So far: CASB shares the SWG's decrypted stream and the DLP engine to enforce real cross-module policy. Next: the gotchas that bite in production, then your cheat-sheet. 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. Figure 4 — Decide which CASB mode (and where DLP runs) for a given need A top-down decision tree. Start: what do you need to protect? First amber diamond asks do you need to block an action in real time. If yes, go inline; a sub-question asks is the device unmanaged BYOD, if yes use reverse proxy via SAML, if no use forward proxy with an agent. If real-time blocking is not the need, a second amber diamond asks is it data already at rest, an old leak, a cert-pinned app, or an OAuth-grant audit; if yes use API out-of-band mode. Green leaves show the chosen deployment. A note says most real deployments combine inline plus API. Which CASB mode do I deploy? What's the need? Block an action in REAL TIME? YES → inline NO → Unmanaged BYOD device? Forward proxy agent · sees ALL apps (managed) Reverse proxy SAML · BYOD, no agent NO YES Data-at-rest, old leak, cert-pinned, OAuth audit? API (out-of-band) scan at rest · retro · OAuth grants In production you almost always run inline + API together Walk the decision tree from the top: real-time block needed? → inline. Unmanaged BYOD? → reverse proxy. Old data / cert-pinned app / OAuth grant audit? → API. The amber diamonds are the decision points; green leaves are what you deploy. Daily-life analogy — Aadhaar-based KYC vs the security guard Inline CASB is the security guard frisking you at the door in real time — he stops the banned item before you enter. API mode is the Aadhaar/KYC back-office audit that runs over your records after account opening: it can't stop a transaction as it happens, but it methodically reviews everything already on file and flags what's wrong. A good bank uses both — a guard at the door and a back-office audit. So does a good CASB deployment. 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. Figure 5 — CASB on one card — pillars, modes, ports of entry and the gotchas A six-tile cheat sheet. Tile one the four pillars Visibility Compliance Data Security Threat Protection. Tile two inline mode equals in the path real-time block. Tile three API out-of-band mode equals scan data-at-rest retro-inspect zero latency. Tile four forward proxy versus reverse proxy, forward for managed all apps, reverse for unmanaged BYOD one app via SAML. Tile five a sample policy block download of Confidential to unmanaged devices. Tile six the four gotchas API coverage gaps, app sprawl, API rate limits HTTP 429, certificate pinning. CASB — your one-glance card The 4 pillars Visibility · Compliance Data Security · Threat Protection discover · comply · protect · defend Gartner's framework Inline mode sits IN the live path (proxy) blocks in REAL TIME adds some latency · live apps only stop the upload before it lands API (out-of-band) off-path · SaaS admin API scan data-at-rest · retro-inspect zero latency · acts AFTER the event fixes old leaks · sanctioned apps Forward vs reverse forward: agent · ALL apps · managed reverse: SAML · BYOD · one app reverse = unmanaged, no agent re-sign SAML assertions! Sample policy IF label = Confidential AND device = unmanaged AND action = download THEN block + coach user The 4 gotchas 1 API coverage gaps (no API = blind) 2 app sprawl (hundreds discovered) 3 API rate limits (HTTP 429) 4 cert pinning breaks inline → API CASB in SSE + CCSP shares the SWG's decrypted stream + one DLP engine — decrypt once, every module reads it real policy = CASB (app/device) + DLP (content/label) + proxy (enforce) combined CCSP Domain 4 (17%): define CASB · 4 pillars · proxy vs API deployment — recite cold Your one-glance revision card: the 4 pillars, inline-vs-API at a glance, the proxy types, and the four gotchas. Keep it open before any CASB interview or the CCSP Domain 4 questions. Prove you own CASB Cold, in 45 seconds: name the four pillars (Visibility, Compliance, Data Security, Threat Protection); explain inline vs API (in-path real-time block vs out-of-band data-at-rest scan) and when you'd choose each; say why you'd reach for a reverse proxy (unmanaged BYOD, no agent, via SAML); and write the policy 'block download of Confidential to unmanaged devices' in terms of which piece (CASB / DLP / proxy) supplies what. If you can do that without notes, you're ready for CCSP Domain 4 and the next lesson. Recap: Secure Web Gateway (SWG) Next: NDR — catching the threat the firewall let in Quick check · Q4 of 10 An interviewer asks Meera: "In one sentence, why does a real CASB deployment almost always run BOTH inline and API mode rather than picking one?" a) Because inline is cheaper and API is just a backup nobody really uses b) Because inline gives real-time blocking of live actions while API scans data-at-rest, retro-inspects history and covers cert-pinned apps — each reaches what the other can't c) Because API mode replaces inline once it's fully scanned d) Because regulators require exactly two modes to be enabled Correct: b. Inline (in-path) is the only way to block an action in real time; API (out-of-band) is the only way to scan data already at rest, fix old leaks, audit OAuth grants and cover cert-pinned apps. They're complementary reaches, which is why mature deployments run both. The other options are false — API doesn't replace inline, neither is a token backup, and no regulator mandates 'two modes'. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What's the simplest way to remember the four pillars without mixing them up? Inline vs API — which one is 'better'? Why would I ever use a reverse proxy instead of a forward proxy? How is CASB different from the SWG we did last lesson? Our CASB found 300+ apps. Do I block all the shadow ones? How much of CCSP does CASB actually cover, and where? Pre-curated from SASE docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which are the four pillars of a CASB as framed by Gartner? a) Firewall, IDS, VPN, Antivirus b) Visibility, Compliance, Data Security, Threat Protection c) Encryption, Hashing, Signing, Tokenisation d) Inline, API, Forward proxy, Reverse proxy Correct: b. The four CASB pillars are Visibility, Compliance, Data Security and Threat Protection. The first option lists generic network controls; the third lists crypto operations; the fourth lists deployment modes (inline/API, forward/reverse), not the pillars. Q6 · Apply A user at Wipro on a managed laptop tries to upload a customer list to their personal Google Drive. You need the CASB to BLOCK it the instant they click upload. Which mode does this? a) Inline (proxy) mode — it's in the live path and blocks in real time b) API (out-of-band) mode — it scans data-at-rest later c) Cloud Discovery — it only reads logs d) A risk score — it only rates the app Correct: a. Only inline mode sits in the live traffic path, so it can deny the upload before any byte lands. API mode is off-path and acts after the fact; Cloud Discovery and risk scores are Visibility-pillar functions that inform policy but don't block a live action. Q7 · Apply A contractor on an unmanaged personal phone (no agent can be installed) must access the corporate M365 tenant, but you still need CASB DLP on their downloads. Which deployment fits? a) Forward proxy with an endpoint agent b) API mode only c) Reverse proxy via the identity provider (SAML) d) Block the contractor entirely Correct: c. A reverse proxy steers the session from the app side via SAML, so an unmanaged BYOD device with nothing installed is still forced through the CASB for that sanctioned app. A forward proxy needs an agent (impossible here); API alone can't block a live download; blocking the contractor defeats the business need. Q8 · Analyze Your CASB reverse proxy is configured for a SAML app, but users hit login loops and the DLP rule never fires. Control of other apps is fine. Most likely root cause? a) The four pillars are misconfigured b) Cloud Discovery hasn't ingested logs yet c) Re-Sign SAML Assertions is off and/or the IdP reply URL points at the app's native URL, so sessions bypass the proxy d) The app's API rate limit returned HTTP 429 Correct: c. Reverse proxy works by re-signing the SAML assertion and having the IdP's reply/ACS URL point at the proxy; if that toggle is off or the reply URL points at the native app, the session never traverses the CASB, so login breaks or DLP never sees the traffic. Pillars and Cloud Discovery don't cause login loops; HTTP 429 is an API-mode throttle, unrelated to inline SAML steering. Q9 · Analyze An attacker steals a third-party app's OAuth token your tenant granted (Salesloft-Drift style) and bulk-exports data straight from the SaaS API. Why does an inline-only CASB miss this, and what would have surfaced it? a) Inline misses it because the attacker uses the stolen token directly against the SaaS API, off your traffic path; API mode auditing OAuth grants and anomalous exports would surface it b) Inline catches everything; nothing was missed c) Only a firewall could have seen this d) Cloud Discovery blocks all OAuth tokens automatically Correct: a. Inline only inspects traffic flowing through the proxy; a stolen OAuth token is used directly against the SaaS API, never touching your path, so inline can't see it. API/out-of-band mode that inventories OAuth grants and flags anomalous bulk exports is what surfaces this — the 2025 Salesloft Drift pattern. A firewall sees less than the CASB here, and Cloud Discovery doesn't auto-block tokens. Q10 · Evaluate Two designs for the same goal — stop sensitive data leaking out of sanctioned SaaS: (A) deploy inline proxy only, for real-time blocking; (B) deploy inline AND API together. Which is the stronger design and why? a) A — inline alone blocks everything in real time, so API adds nothing b) B — inline blocks live actions, while API scans data already at rest, fixes pre-existing leaks, audits OAuth grants and covers cert-pinned apps inline can't decrypt c) A — running two modes just doubles cost for no benefit d) Identical — both reach exactly the same data Correct: b. Inline-only can't see data that already leaked before deployment, can't audit OAuth grants used directly against the API, and can't inspect cert-pinned apps it fails to decrypt — all of which API mode covers. B closes those reach gaps, so it's the stronger design. A and 'identical' wrongly assume inline reaches data-at-rest and off-path API access, which it cannot. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line, why must a CASB run inline AND API mode rather than just one? Then compare to the expert version. Compare with expert answer Expert version: Because inline sits in the live path and is the only mode that can block an action in real time, while API is off-path and is the only mode that can scan data already at rest, retro-inspect old leaks, audit OAuth grants and cover cert-pinned apps — each reaches exactly what the other cannot. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on CASB at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary CASB Cloud Access Security Broker — a control point between users and cloud apps that gives visibility and enforces policy. Shadow IT Cloud apps employees adopt without IT approval, leaking data into apps no one governs. The 4 pillars Gartner CASB framework: Visibility, Compliance, Data Security, Threat Protection. Cloud Discovery CASB analysis of firewall/proxy logs to find and risk-score every cloud app in use, including shadow IT. Risk score A rating of an app based on its certifications, encryption, breach history and data-residency — used to triage apps. Inline mode CASB sits in the live traffic path (as a proxy) so it can block an action in real time. API (out-of-band) mode CASB connects to the SaaS's own admin API off-path to scan data-at-rest and retro-inspect history; zero added latency. Forward proxy Steers traffic from the user side (agent/tunnel) — sees all apps but needs a managed/steered device. Reverse proxy Steers from the app side via the IdP (SAML) — forces unmanaged BYOD through the CASB for one app, no agent. DLP Data Loss Prevention — detects and blocks sensitive content (PII, card numbers, Confidential labels) from leaking or over-sharing. Data residency The legal requirement that certain data be stored within a specific country or region. SSE Security Service Edge — the cloud-delivered security stack (SWG + CASB + ZTNA + DLP) where CASB shares one decrypted stream. #### 📚 Sources Microsoft Learn — "File policies in Microsoft Defender for Cloud Apps" (exact console path: Cloud Apps → Policies → Policy management → Information Protection → Create policy → File policy; fields: Policy name, Policy severity, Category=DLP, Access level filter, Content inspection method = Data Classification Services, Sensitivity label, governance actions; API-based, 50-policy limit, ms.date 2025-09). learn.microsoft.com/en-us/defender-cloud-apps/data-protection-policies - Netskope — "What is a CASB?" + "Deployment Options" (the four Gartner pillars Visibility/Compliance/Data Security/Threat Protection; most customers combine API with forward and/or reverse proxy for full use-case coverage). netskope.com/security-defined/what-is-casb · netskope.com/products/deployment-options - TechTarget SearchSecurity — "Choosing between proxy vs. API CASB deployment modes" + CSA "API vs. Proxy: best protection from your CASB" (inline proxy acts in real time and can block; API is out-of-band, off the data path, scans data-at-rest, needs admin API access to sanctioned apps). techtarget.com/searchsecurity/tip/Choosing-between-proxy-vs-API-CASB-deployment-modes · cloudsecurityalliance.org/blog/2016/08/11/api-vs-proxy-get-best-protection-casb - Netskope docs — "SAML Reverse Proxy" + "Universal Reverse Proxy" (reverse proxy steers unmanaged BYOD via the IdP/SAML, requires Re-Sign SAML Assertions; API Rate Limits doc notes HTTP 429 throttling on the data-protection API). docs.netskope.com/en/saml-reverse-proxy/ · docs.netskope.com/en/api-rate-limits-on-next-generation-api-data-protection/ - Google Cloud / Mandiant Threat Intelligence — "Widespread Data Theft Targets Salesforce Instances via Salesloft Drift" (Aug 2025 UNC6395 stole third-party Drift OAuth tokens to bulk-export Salesforce/Workspace data across 700+ orgs — the real shadow-IT/OAuth-grant risk CASB API mode is meant to surface). cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift - ISC2 CCSP Certification Exam Outline — Domain 4 Cloud Application Security (17%): define CASB, the four pillars, and proxy (inline) vs API deployment models. isc2.org/certifications/ccsp/ccsp-certification-exam-outline · ccsp.alukos.com/certification/domain-4/ - Cloudflare Learning Center — "What is a CASB?" (vendor-neutral explainer of the broker concept, shadow IT, and the four pillars). cloudflare.com/learning/access-management/what-is-a-casb/ ### What's next? A CASB governs the SaaS and data you can see into — but what about the attacker who's already slipped past every gate and is moving quietly inside your network? Signature defences and the firewall already waved them through. NDR is the control that watches behaviour and east-west traffic to catch the intruder the perimeter missed. Next · NDR: Catching the Threat the Firewall Already Let In → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt