SDWSCS Part 8: CASB, DLP & Securing Microsoft 365

Part 7 got the traffic into Umbrella; this part is about the controls that only make sense once it’s there — the CASB layer. Firewalls and SWGs answer “may this user reach this destination?”; CASB answers the questions SaaS actually raises: which SaaS apps are in use at all, whose tenant is being accessed, and what data is moving into it.

Shadow IT: App Discovery

The entry-level CASB function is visibility. Umbrella’s App Discovery classifies the SaaS applications seen in your DNS and proxied web traffic — a few thousand apps with risk scoring (data handling, compliance attestations, breach history) — and the output is a ranked answer to “what is our estate actually using?”. Every CASB deployment starts here for a boring reason: you can’t write app policy against an inventory you don’t have. The usual discovery-phase finds: three file-sharing services nobody procured, a couple of AI tools with paste-sensitive-data risk, and personal cloud storage from exactly the departments you’d guess.

From discovery you graduate to app controls: block by app (not just domain — the classification follows the app across its CDN spread), or allow the app but block activities (upload allowed, sharing blocked; view allowed, download blocked for unmanaged devices). Activity-level control needs HTTPS inspection on — the SWG has to see the request path to tell an upload from a page-view. No decryption, no activity granularity; that dependency chain (Part 4 → Part 7 → here) is the one to remember.

Tenant restrictions: the M365 problem

The sharpest CASB use case, and the one the syllabus names explicitly. Once you allow *.sharepoint.com and login.microsoftonline.com — which you must, because you run M365 — you have also allowed every other organisation’s M365 tenant, and a personal or attacker-controlled tenant is the cleanest exfiltration channel there is: the traffic looks identical to the traffic you bless.

Tenant controls fix this by having the proxy inject Microsoft’s tenant-restriction headers (Restrict-Access-To-Tenants, Restrict-Access-Context) into the decrypted login traffic, so Entra ID refuses token issuance for any tenant not on your list. Requirements stack up exactly as you’d expect: SIG in path for the login flows, HTTPS inspection enabled for the Microsoft auth domains (pin-sensitive — follow Microsoft’s supported-proxy guidance rather than improvising), and your tenant IDs enumerated. The same mechanism covers Google Workspace and Slack workspace restrictions.

This pairs with, not replaces, the Cloud OnRamp for SaaS machinery — Part 10 optimises the path to M365; tenant controls constrain which M365. Deployments that steer M365 traffic to local DIA for performance need the DNS-layer + edge enforcement story for those flows instead, and that trade-off (performance path vs inspection path for the same app) is a design decision the course wants you to be able to argue both ways.

DLP

Umbrella’s data loss prevention inspects decrypted uploads and posts in real time against content rules: built-in identifiers (card numbers, national IDs, credentials) plus custom dictionaries and regexes, scoped by identity and destination app. Verdicts: block or monitor, with the incident (matched rule, snippet context, user, app) landing in the DLP report.

Two deployment truths from the field: start in monitor mode — DLP rules against live traffic always match things you didn’t predict, and a week of monitor-mode incidents tunes the rules without blocking payroll’s legitimate workflow; and DLP is only as good as the decryption scope — an exempted category or pinned app is a DLP bypass. The API-based flavour (out-of-band scanning of data at rest in sanctioned tenants) complements the inline flavour and doesn’t depend on the data path at all.

Remote browser isolation

For the destinations you neither trust enough to allow nor can justify blocking — uncategorised, newly-registered, personal webmail — RBI renders the page in a cloud-isolated browser and streams pixels to the user. No active content executes on the endpoint; paste/upload/download can be disabled per policy. It’s the pragmatic middle verdict between allow and block, priced and sized for the risky sliver of traffic rather than everything.

What the SD-WAN engineer owns in all this

The controls live in Umbrella’s console, but their preconditions are fabric-side, which is why this module is in an SD-WAN course at all:

Control	Fabric prerequisite
App Discovery	DNS policy (min) or SIG in path
Activity controls	SIG + HTTPS inspection
Tenant restrictions	SIG in path for MS auth domains, decryption on
Inline DLP	SIG + decryption covering the upload paths
RBI	SIG web policy issuing the isolate verdict

Steering policy that accidentally sends login.microsoftonline.com out local DIA (because an over-broad OnRamp/M365 optimisation matched it) silently disables tenant restrictions — the single best exam-question-shaped gotcha in this module.

Next up, Part 9: ThousandEyes — because after Parts 7–8 your users’ traffic transits infrastructure you don’t own, and when M365 is slow you need evidence, not vibes.