Cloud access security broker (CASB)

The request, step by step

1. Get into the path, or see nothing

   Inline coverage is a placement problem. A managed device is steered to a forward proxy by its agent; an unmanaged device is pulled through a reverse proxy by the identity provider at sign-on. A device that is neither steered nor redirected is not covered.

   • Request: Salesperson to Managed laptop, “Exports a customer list from the CRM”
   • Request: Managed laptop to Forward-proxy position, “Agent steers cloud traffic to the proxy”
   • Context: Salesperson to Identity provider, “Single sign-on to the sanctioned tenant”
   • Request: Identity provider to Reverse-proxy position, “Session redirected through the broker after sign-on”
   • Request: Personal device to Reverse-proxy position, “Unmanaged device, covered without an agent”

   Emphasised at this step: Forward-proxy position.

2. Decide before the data moves

   Both inline positions present the action to one data policy and wait for the verdict, so an upload can be refused, coached or redacted before anything leaves. This is the only point in the diagram where prevention is possible.

   • Request: Forward-proxy position to Data policy, “Upload presented for a verdict before it leaves”
   • Request: Reverse-proxy position to Data policy, “Session and download presented for a verdict”
   • Request: Forward-proxy position to Sanctioned CRM tenant, “Permitted traffic continues to the tenant”
   • Request: Reverse-proxy position to Sanctioned CRM tenant, “Permitted session reaches the tenant”

   Emphasised at this step: Data policy.

3. Read the tenant out of band

   The connector authenticates to the service's own API and reads activity, files and sharing state. It sees things no proxy can, including files placed there by other routes, and it sees them only once they already exist.

   • Request: Sanctioned CRM tenant to Files and sharing links, “Application stores files and creates sharing links”
   • Telemetry: Sanctioned CRM tenant to Out-of-band connector, “Activity, file and sharing state read through the API”
   • Context: Out-of-band connector to Data policy, “Findings evaluated against the same policy”

   Emphasised at this step: Out-of-band connector.

4. Act after the fact

   The same policy applies to a finding, but the only available actions are retrospective ones: unshare, quarantine, revoke, notify. Between the event and the scan that found it, the exposure was real and unmitigated.

   • Request: Data policy to Files and sharing links, “Sharing link quarantined two days after the fact”

   Emphasised at this step: Files and sharing links.

5. Discover what nobody sanctioned

   Egress logs from the network name the services in use and who uses them, without any integration with those services. Discovery produces a catalogue and a recommendation, not a control, and its findings feed both the policy and the evidence trail.

   • Telemetry: Managed laptop to Firewall and web proxy logs, “Outbound destinations recorded at the network edge”
   • Telemetry: Firewall and web proxy logs to Shadow-IT discovery, “Logs ingested to build the service catalogue”
   • Context: Shadow-IT discovery to Data policy, “Service risk rating and usage volume”
   • Telemetry: Shadow-IT discovery to Security operations, “Newly seen services and who is using them”
   • Telemetry: Data policy to Security operations, “Every verdict and the signals behind it”

   Emphasised at this step: Shadow-IT discovery.

Attempts shown, and where each one stops

• Insider or hijacked account attempts:

  • Attack: Insider or hijacked account to Forward-proxy position, “Customer list uploaded to a personal account”
  • Attack: Insider or hijacked account to Personal file-sharing service, “The same upload from a device with no agent”
  • Terminated here by Forward-proxy position — “Refused: customer records to an unsanctioned service”. The line stops short and takes a bar, not an arrowhead.

Annotations

1. Why this line is observation, not a request path

   Relationship — Telemetry: Sanctioned CRM tenant to Out-of-band connector, “Activity, file and sharing state read through the API”

   No user traffic travels here. The connector polls or subscribes to the service's API and receives a record of things that already happened, so the relationship is one of reporting rather than carriage. Drawing it as a request path would imply the broker sits between the user and the tenant, which in this mode it does not.

2. An action that runs backwards into the tenant

   Relationship — Request: Data policy to Files and sharing links, “Sharing link quarantined two days after the fact”

   This is the one thing out-of-band mode can enforce, and it reaches the stored file rather than the person who moved it. It repairs an exposure that already existed for as long as the scan interval, which is why the interval is a security parameter and not an operational detail.

3. Which position could refuse, and why only that one

   Relationship — Blocked: Insider or hijacked account stopped at Forward-proxy position, “Refused: customer records to an unsanctioned service”

   The bar means the attempt ended before reaching its destination. It starts at the forward proxy because that position was already in the path with the upload held open. Neither the connector nor a reverse proxy for a different application was anywhere near this flow.

4. Why this attempt has no refusal

   Relationship — Attack: Insider or hijacked account to Personal file-sharing service, “The same upload from a device with no agent”

   Nothing is between this device and that service. No agent steers the traffic, the destination has no connector, and the identity provider is not involved because the service does not use it. Discovery will name the service afterwards, which is a report, not an intervention.

5. Why the inline positions are grouped

   Boundary “Inline positions” (managed)

   Everything inside this boundary can hold a request open and change its outcome. That single property, and not the vendor or the console, separates preventive coverage from reporting. Both positions inside it depend on a steering mechanism that can be absent, misconfigured or deliberately avoided.

6. No agent, but not free of conditions

   Component “Reverse-proxy position”

   This position needs the application to federate to your identity provider and needs sign-on to redirect through the broker, so it covers only applications you control the login for. It rewrites what the client sees, which is where pinned certificates, native clients and machine-to-machine integrations break.

7. Discovered is not the same as controlled

   Boundary “Discovered, unsanctioned services” (untrusted)

   Services in this boundary appear in reports with names, users and volumes. Nothing in the broker sits between a person and them until somebody either sanctions the service and connects it, or blocks the category at an inline position that is actually in the path.

8. This catalogue is built from people's records

   Component “Shadow-IT discovery”

   Its input is a log of where the workforce went. That makes it a monitoring capability with a lawful basis, a retention period, a restricted query surface and something the workforce should be told, settled before ingestion rather than after the first report is shared.