CASB and SaaS DLP: testing the coverage of your cloud controls

A CASB (Cloud Access Security Broker) applies DLP rules to SaaS applications, either through an API (analysis of data already stored) or in inline mode (control of the flow at the moment it is sent). Testing a CASB DLP means checking, with synthetic data, that each application, each mode and each user action does trigger the expected block or alert. Without this test, you know what is configured, not what is actually covered.

Two modes, two different promises

Most disappointments around CASB come from confusing its deployment modes. They do not protect the same thing, and they are not tested the same way.

Scroll the table →

What the console does not tell you

A CASB policy shown as “active” in the console rests on a chain of conditions. It only takes one link to give way for the rule never to apply. The most common breaks:

• The API connector has lost its rights after a token renewal or a change of administrator on the SaaS side.
• The instance is not the right one: the company protects its official tenant, but not the personal instance or a partner’s instance opened in the same browser.
• The inline proxy does not see everything: a roaming workstation outside the tunnel, a desktop application that ignores proxy settings, a personal phone.
• The detection engine does not recognise the content: compressed file, password-protected document, image containing text, proprietary business format.
• The action is not covered: the rule targets uploads, but not copy and paste into a web form, nor the creation of an external sharing link.

These failures belong to the same family as those described in our article on DLP false negatives: the rule exists, it does not fire, and nobody is told.

Building a SaaS coverage matrix

Testing a CASB is not about launching a test file and seeing whether an alert comes up. It is about methodically crossing three dimensions.

1. The applications

Start from the real inventory, not the contractual list. Classify SaaS applications into three groups: sanctioned (email, storage, CRM, collaboration tools), tolerated (applications used without formal approval) and unauthorised. The CASB must treat each group differently, and each treatment must be verified. For the usage that the IT department does not see, the article on shadow IT and the browser details the paths to inventory.

2. User actions

• uploading a file;
• pasting text into a field or a message;
• creating a public or external sharing link;
• synchronisation by a desktop client;
• downloading to an unmanaged device.

3. The contexts

Managed workstation in the office, managed workstation working from home, personal device, alternative browser, personal tenant of the same application. A rule that works in a single context covers only a fraction.

The product of these three dimensions quickly gives several hundred cases. That is normal. Prioritise by the sensitivity of the data actually present in each application and by likelihood of use.

A concrete scenario: a customer spreadsheet to cloud storage

Take a mid-sized company (ETI) whose policy prohibits files containing customer data from leaving for unsanctioned storage. The test runs as follows:

1. Prepare a decoy: a spreadsheet of synthetic data, realistic in format (names, fictitious IBANs in a valid format, contract numbers), marked with a fingerprint that only you recognise. The method is described in the article on synthetic data in production.
2. Replay the action on the sanctioned tenant, then on a personal instance of the same application, then on an unauthorised application.
3. Vary the context: from the corporate network, then outside the tunnel.
4. Vary the form: raw file, compressed file, pasted content.
5. Record three results per case: blocked or not, alert generated or not, delay between the action and the reaction.

The most instructive result is rarely “everything is blocked” or “nothing is blocked”. It is the line where the official tenant is protected and the personal instance is not. Or the one where the alert exists but reaches the SOC hours later, with nobody handling it. The link with the detection chain is developed in the article detecting exfiltration on the SOC side.

Checklist before declaring a SaaS application “covered”

• The control mode (API, inline, both) is documented for this application.
• The API connector has been verified as working recently, not only at installation.
• Unofficial instances of the same application are distinguished and handled.
• The five user actions listed above have been tested.
• At least one context outside the corporate network has been tested.
• The remediation delay in API mode is measured and judged acceptable.
• Alerts arrive in the tool where the SOC actually works.
• The test is replayed after every major change (new application, CASB update, tenant evolution).

Why a one-off test is not enough

SaaS changes without you. The vendor adds a sharing feature, modifies an API, launches an AI assistant feature that opens a new channel (see Generative AI and data leakage). Your CASB is not necessarily informed, or not at the same pace. Coverage verified in January may have degraded by April without any configuration having changed on your side. Only regular replay makes this drift visible, and makes it possible to track a posture over time rather than a snapshot.

This test is part of a broader data exfiltration testing approach, which also covers the endpoint, the network and email.

Frequently asked questions