Livoa LogoLivoa
CASB Integration Architecture (Text Description)


1) Layers & Components

User & Endpoint Layer

QCAA-managed laptops/desktops with Zscaler Client Connector (or PAC/forwarding profile).

Identities sourced from Microsoft Entra ID; groups/roles map to policy.

Access & Inspection Layer (Zscaler CASB / Zero Trust Exchange)

Inline CASB (forward proxy): inspects TLS traffic to cloud/SaaS apps; enforces access and DLP policies in real time.

Out‑of‑band CASB (API mode): connects via sanctioned app APIs (e.g., M365) to scan stored data, sharing, and app config posture.

Cloud App Discovery / Shadow IT: catalogs apps in use, risk-rates them, and applies allow/block/coach policies.

Inline Threat Protection: malware/command-and-control detection on SaaS traffic.

DLP Engine: QCAA-specific dictionaries, regexes, and file-type controls.

Identity & Directory Layer

Microsoft Entra ID provides SSO/OAuth, MFA, user/group claims to CASB.

Optional HR/department attributes used for policy scoping (e.g., “Finance,” “Legal”).

Security Operations Layer

RSA NetWitness SIEM: receives CASB logs/events (policy blocks, DLP incidents, Shadow IT detections).

SIRP SOAR: ingests high‑severity CASB alerts; runs playbooks (notify owner, quarantine file/share, ticket creation).

Trend Micro XDR (optional enrichment): correlates endpoint detections with CASB events for user risk scoring.

Application & Data Layer

Sanctioned SaaS (e.g., Microsoft 365, OneDrive, SharePoint, Teams) and approved third‑party cloud apps.

Unsanctioned/Shadow IT destinations (discover → coach/block).

2) Primary Data Flows (Inline Use Case)

Auth & posture

User signs in; Entra ID asserts identity and group/role to Zscaler CASB (SSO/OAuth). Client Connector forwards SaaS traffic to CASB.

Policy evaluation

CASB checks: user group, device context (if available), app risk, destination category, and QCAA DLP rules.

Enforcement

Allowed: session proceeds with logging and threat/DLP inspection.

Coached: user gets justification page (e.g., “Business use only”).

Blocked/Quarantined: upload/download or app access is denied per policy; user sees a customized QCAA block page.

Eventing

CASB sends events/logs to NetWitness SIEM. High‑severity DLP or policy violations create SOAR tickets with context.

3) Secondary Data Flows (API Mode for Sanctioned Apps)

Connector setup

CASB connects to sanctioned tenants (e.g., M365) using application‑level APIs with scoped permissions.

Content & config scan

Scans files for sensitive data (DLP) and misconfigurations (e.g., public links, external sharing).

Evaluates tenant/app posture (e.g., third‑party sharing apps, risky OAuth grants).

Remediation

CASB can revoke risky shares, quarantine files, or notify owners. Results are logged to SIEM and, if critical, to SOAR for workflow.

4) Policy Objects & Customization (What is “customized”)

Identity‑driven policies: Entra ID groups (e.g., “Finance,” “Legal,” “Executive”) map to CASB access/DLP policies.

Data protection rules: QCAA-specific DLP dictionaries (e.g., payroll identifiers, contract references, regulator terms) with severity tuning.

App governance: sanctioned/unsanctioned catalogs; risky app categories blocked; medium‑risk apps coached.

Exception handling: time‑bound policy exceptions with mandatory business justification and auto‑expiry.

User experience: QCAA-branded block/coach pages and localized messages.

5) Metrics, Reporting, and Monitoring

Coverage: % of users/endpoints enforced by CASB; % of cloud traffic inspected.

DLP incidents: count, severity, data types, department breakdown, time trends.

Shadow IT: newly discovered apps per month; risk distribution; blocked vs coached actions.

Threat protection: malicious file/url blocks, sandbox results.

Response: mean time to notify/remediate (MTTN/MTTR) for CASB alerts via SOAR.

Compliance: quarterly exports for CISO/ISD (PDF/CSV) and live dashboards for SOC.

6) Integrations Summary (who talks to whom)

CASB ↔ Entra ID: SSO/MFA, user/group attributes for policy.

CASB → SIEM (NetWitness): logs/events for correlation and audit.

CASB → SOAR (SIRP): high‑severity alerts trigger playbooks (notify, quarantine, ticket).

CASB ↔ M365 (API): scanning + remediation of files/shares/config.

CASB ↔ Endpoints: via Client Connector/PAC for inline inspection and control.

CASB ↔ XDR (optional): context sharing for user/device risk scoring.

7) Resiliency & Privacy Considerations

Resiliency: multi‑POP cloud; client fallback modes defined by policy (fail‑open for low‑risk browsing vs fail‑close for sensitive apps).

Privacy: DLP inspection restricted to business domains; admin access RBAC; detailed logging under least‑privilege principles; retention aligned to QCAA policy.

CASB

by Tim

0
0 uses