Best Practices for CASB Security

Last updated
Save as PDF

This article outlines the security best practices recommended by Versa Networks for deploying and operating Versa Cloud Access Security Broker (CASB) as part of a unified SASE strategy. Designed for security architects, cloud security engineers, and IT decision-makers, it provides actionable guidance for designing, implementing, and maintaining a defensible CASB posture for SaaS access. The guidance is organized around three control domains:

Shadow IT classification
SaaS tenant control
CASB enforcement (inline and API)

These are described in the order they should be established. Terminology is consistent with the Versa Concerto management portal.

This article is a security reference model, not a deployment guide. It describes the control expectations and operating safeguards required to securely adopt SaaS applications using Versa CASB. For information on how to perform the configurations in Concerto, see Configuration from Concerto.

Shadow IT

Zero Trust starts with knowing which SaaS applications the organization uses. Without this, security rules cannot tell approved SaaS applications from unsanctioned ones, and the same rule applies to both. Shadow IT discovery lists common SaaS applications used in the environment and lets you set a state for each one: Sanctioned, Allowed, Unsanctioned, or Uncategorized. The Sanctioned and Unsanctioned states can be used as match criteria in an internet protection rule. You set this match condition under Applications & URLs, in the Shadow IT Applications tab. This is how the classification becomes an allow or deny action in the rule.

Initial Classification

SaaS applications used in the customer environment appear in the Active Applications view only after they have been observed in secure web gateway (SWG) or SASE client traffic. The All Applications view contains a default list of common SaaS applications and can be used to set the Sanctioned or Unsanctioned state even before an application is detected in user traffic. The customer's existing approved-SaaS list and prohibited-SaaS list serve as the policy reference against which each application is classified.

Apply pre-existing corporate approved/prohibited lists—In the All Applications view, set the state to Sanctioned for applications on the approved list, and to Unsanctioned for applications on the prohibited list. Applications left as Uncategorized are not matched by Sanctioned or Unsanctioned rules.
Adjust default risk scores—Each application has a Versa Risk Score (1–100) that places it in one of five risk bands. If the default score does not match how you view the application's risk, use the Calculated or Custom Confidence Score in Concerto to adjust the rating.

Active Application Visibility

The Active Applications view for shadow IT discovery shows which SaaS applications are currently being used, who is using them, and each application's risk and confidence scores. Use this view to classify the applications that appear.

Identify accessed applications, users, and scores—In the Active Applications view, identify the SaaS applications being used in the environment, the users accessing each one, and each application's Versa Networks risk and confidence scores.
Classify based on corporate requirements—Based on corporate requirements and the observed risk, set each application's state to Sanctioned or Unsanctioned.
Regular review of active applications—Review the Active Applications view at a defined interval (monthly is recommended) to find newly-appeared applications and applications whose usage has changed significantly. Each new application starts as Uncategorized and does not match Sanctioned or Unsanctioned rules. Without regular review, the list of Uncategorized applications grows, and unsanctioned SaaS continues to be used without enforcement.
Off-network coverage using SASE client—Deploy the Versa SASE client on managed devices so shadow IT discovery sees off-network use. Most unsanctioned SaaS adoption happens off the corporate network, and on-network discovery misses much of what is actually in use.

Enforcement in Internet Protection Rules

Classification only takes effect when used as a match condition in the Shadow IT Applications tab of an internet protection rule.

Unsanctioned deny rule—Configure an internet protection rule that matches Unsanctioned applications and denies the session. This blocks the specific SaaS applications that URL categories alone cannot identify.
Sanctioned allow-with-inspection rule—Configure an internet protection rule that matches Sanctioned applications and attaches CASB, data loss prevention (DLP), and advanced threat protection (ATP) profiles. Without these profiles, traffic to Sanctioned applications is not inspected.
Risk-band-based matching—In addition to state matching, the Shadow IT Applications tab lets you match on Application Risk Bands (Trustworthy through High Risk). The two conditions combine with AND. For example, deny applications in the Suspicious or High-Risk bands, or limit allow rules to Sanctioned applications in the lower-risk bands.
Rule ordering—Place the Sanctioned and Unsanctioned rules above any general URL-category allow rules. Otherwise, a permissive URL-category rule will match the traffic first and override the Unsanctioned deny.

SaaS Tenant Control

Many SaaS applications use the same domain for both corporate and personal accounts. For example, login.microsoftonline.com serves both corporate Microsoft 365 and personal Outlook accounts. Without tenant restriction, a user on a corporate device can authenticate to a personal tenant and use it as a data exfiltration path, with traffic that is indistinguishable from corporate traffic by domain alone.

The SaaS Tenant Control profile in Concerto injects HTTP headers into traffic destined to these applications to allow only the specified corporate tenant.

Tenant Restriction

Enforce tenant restriction headers—Configure the SSE gateway to insert tenant restriction headers for traffic destined to sanctioned domains (for example, Restrict-Access-To-Tenants for Microsoft 365 or X-GoogApps-Allowed-Domains for Google Workspace). Without tenant restriction, a user can authenticate to a personal Microsoft 365 or Google Workspace tenant from a corporate device and use it as an exfiltration destination that is indistinguishable from corporate traffic by domain alone.
Enable Delete Existing on each rule—Turn on the Delete Existing option for every insert header rule so any pre-existing header with the same name is removed before the gateway inserts its own. Without this, a client that sends its own tenant header could override the gateway's value and bypass the restriction.
Block consumer variants—Use the same profile to block consumer versions of these applications (for example, personal Outlook, personal OneDrive, consumer Gmail, or personal Dropbox) on managed devices. Consumer accounts use the same infrastructure as corporate but are outside corporate policy controls and audit.
Verify TLS decryption covers tenant-control domains—Header insertion requires the SSE gateway to decrypt the session. A tenant-control domain excluded from TLS decryption cannot have restriction headers injected, which silently disables the control for that traffic.

CASB (Inline and API)

CASB enforcement can be implemented using two deployment models: inline CASB through the SSE gateway and API CASB through direct integration with the SaaS application. The two approaches are complementary, as each covers scenarios the other cannot. Deploy both for every in-scope tenant. Inline CASB covers real-time user-to-SaaS traffic, and API CASB covers data at rest, sharing events, and certificate-pinned or cached activities. Neither mode alone provides complete enforcement.

Inline CASB

Inline CASB inspects SaaS traffic in real time as users access cloud applications through the gateway. It is most effective for user-to-application transactions like logins, uploads, and downloads. Inline CASB is enforced by attaching a CASB profile to an internet protection rule in Concerto.

Enforce activity-level CASB rules—Match specific user actions (login, upload, download, share, post) under the CASB profile rather than blocking or allowing entire applications. This lets you allow business-critical actions while blocking risky ones on the same SaaS application.
Attach CASB profiles to every SaaS allow rule—Review each internet protection rule that permits SaaS access, whether it matches on the Sanctioned shadow IT state, URL categories, or specific applications, and attach a CASB profile to it. An allow rule without a CASB profile passes SaaS sessions with no activity-level control, so risky activities on that path go unchecked.
Integrate DLP and ATP for data protection—Although optional, combining inline CASB with DLP and ATP profiles is a recommended best practice for applications that allow uploads or downloads. DLP helps detect and prevent sensitive data exfiltration, while ATP inspects files for malware before they are delivered to users.
Apply Constraint Profiles for high-risk collaboration activities—Use Share From/To, Send From, and Call From/To constraint profiles (in Concerto Releases 12.1.1 and later) to restrict which user groups can perform high-risk activities on collaboration tenants such as SharePoint Online, Box, Dropbox, OneDrive, Outlook, and Microsoft Teams. This enforces least privilege at the SaaS activity layer.

TSL Decryption of CASB Apps

Enable TLS decryption on CASB-enforced domains—Inline CASB requires the SSE gateway to decrypt TLS. A domain excluded from decryption is also excluded from CASB enforcement, so the decryption scope and the CASB scope must match.

Inline CASB Coverage Gaps and Compensating Controls

Some SaaS traffic never reaches the SSE gateway or cannot be decrypted, so inline CASB cannot inspect it. Each limitation below describes one such case and the control that covers it, which in most cases is API CASB on the same tenant.

Certificate-pinned applications—Some SaaS native clients pin certificates and cannot be inspected inline; attempting to decrypt them breaks the application rather than providing inspection. Catalog these applications and route them to API CASB instead.
End-to-end encrypted content—Some SaaS applications or specific features use end-to-end encryption, so inline CASB cannot inspect messages or file content even when traffic passes through the SSE gateway. Where the application offers API access, cover the tenant with API CASB so stored data and sharing events remain visible, and use alternative controls where content cannot be inspected by either mode.
Unsupported applications and activities—Inline CASB coverage depends on the Versa-supported application catalog, and the set of supported activities (upload, download, post, form-post, share) varies by application. Verify application and activity support before designing policies and cover unsupported tenants with API CASB where a connector exists.
Browser-cache activities—Certain SaaS actions, such as downloads from Excel Online and generating share links, are completed in the browser cache and never traverse the gateway. Pair inline CASB with API CASB on the same tenant so these activities remain covered.
Limited activity coverage on mobile—On mobile platforms where inline CASB activity coverage is limited, integrate Versa Networks with the organization's IdP conditional access and MDM/MAM solution so activities invisible to inline CASB are still constrained by a different control.

API CASB

API CASB connects directly to SaaS tenant management APIs to inspect stored data and monitor sharing events. Unlike inline CASB, API CASB sees data at rest, historical content, and sharing changes that would never traverse a gateway. API CASB is configured in Concerto by adding a connector for each SaaS tenant and applying API Data Protection (API-DP) policy rules.

Connector Deployment

Connect every in-scope SaaS tenant—Enable API CASB connectors for every SaaS tenant that supports them (Microsoft 365, Google Workspace, Salesforce, Box, Slack, Dropbox, and 80+ others). API integration is the only path that sees data at rest and sharing events that never traverse the gateway.
Use dedicated service accounts with least-privilege scopes—Create a named service account per API CASB connector with the minimum API scopes required, and rotate credentials on a defined schedule (e.g., 90 days). A leaked or unrotated connector token grants tenant-wide read access.
Match the same instance inline and API—Configure each API CASB connector against the same corporate SaaS instance that inline CASB enforces. Mismatched instance scope leaves a blind spot or duplicated enforcement that disagrees with itself.
Monitor connector health and alert on failure—Monitor API CASB connector status in Concerto and configure alerting on prolonged failure (for example, the connector is down more than 1 hour). A silently broken connector creates a tenant blind spot that no other CASB control compensates for.

Policy Configuration and Scanning

Attach DLP, offline CASB, and ATP companion profiles—API DP policy rules support three companion profiles that must be attached explicitly: DLP for content, offline CASB for remediation actions within the SaaS application, and ATP for malware. Omitting any one leaves a class of risk unaddressed.
Set Pending ATP Action by tenant risk—Use Block for high-risk tenants where a first-time false negative is unacceptable, Wait until timeout where deterministic verdicts matter more than latency, and Allow and Scan first time for general productivity tenants.
Run Retro Scan with a Start After delay at onboarding—When connecting a new tenant, enable Retro Scan with a Start After delay so policies and exclusions are finalized before pre-existing content already stored in the tenant is processed, preventing mass false-positive remediation on day one.
Set scan frequency by data sensitivity—Run high-sensitivity tenants, such as finance, source code, and customer PII, on hourly or daily schedules, and run low-sensitivity tenants weekly.

Sharing Controls and Remediation

Configure rules to fire on sharing events—Create event-based API-DP rules that trigger DLP and ATP reevaluation on sharing events, such as a new external collaborator, link made public, or file moved to a shared library. The risk profile of a file changes when its audience changes.
Match Internal/External plus Owned Domain Profiles on sharing rules—Configure the Internal-External match and pair it with Owned Domain Profiles listing all corporate domains. This is the single condition that distinguishes internal collaboration from external exposure.
Define User Profiles for role groups—Define API-DP User Profiles for cross-tenant role populations (privileged admins, finance, legal, source-code authors) and reuse them across rules to prevent role-policy drift across tenants.
Quarantine policy-violating content rather than deleting—Set the remediation action to Quarantine rather than Delete. Quarantine preserves evidence and gives the business owner a path to restore content flagged in error.
Use platform-specific share remediation actions—File-share remediation actions differ per application: Revert, Set Expiry, Remove User, and Remove Permission for Box, Dropbox, Google Drive, and Salesforce; Set Expiry and Remove Permission for OneDrive and SharePoint; Revert and Set Expiry for Citrix ShareFile and Egnyte.
Attach a Notification Profile on remediation rules—Attach a Notification Profile to every API-DP rule that can quarantine, delete, or revoke sharing. Without it, remediation actions happen silently in the tenant.
Configure Legal Hold profiles for DLP evidence preservation—Evaluate whether DLP policy violations should be automatically sent to a designated Legal Hold profile for compliance analysis and retention according to your organization's data governance policy. Legal Hold is transparent to end users; files are uploaded normally, and a copy is simultaneously created in the SaaS application designated as the Legal Hold profile.

IaaS API CASB Coverage

Enable object-storage coverage—Versa API CASB supports AWS, GCP, Microsoft Azure, and Oracle Cloud Infrastructure for file-upload and file-delete events on object storage. Enable it for every IaaS tenant that holds business data. Cloud buckets are the most common source of accidental public exposure of corporate data.
Alert on delete events—Generate alerts on file-delete events in IaaS even when the action is not blocked. In object storage, deletes are how attackers cover tracks and how ransomware destroys backups.
Run scheduled comprehensive scans of object storage—Configure scheduled API CASB policies (monthly is recommended) to run full scans of data at rest in cloud buckets with DLP and ATP profiles applied. Scheduled scans identify sensitive data and malware uploaded before policies were enforced and verify that DLP and ATP policies are still active; they act as a safety net for enforcement gaps that event-based rules miss.

Operational Governance

A CASB deployment degrades silently as tenants, users, and applications change. The following operational practices keep the controls established in Sections 1 through 3 effective over time.

Conduct a periodic CASB policy audit—At least quarterly, verify that every sanctioned tenant has both inline and API CASB coverage, that DLP, ATP, and Notification Profiles are attached to all enforcement rules, and that connector health has not lapsed.
Test policy changes before production deployment—Before deploying new API CASB rules or modifying existing policies in production tenants, validate them in a non-production or pilot environment. This allows you to verify detection accuracy, measure false positive rates, and refine rule logic without disrupting user workflows or triggering unintended bulk remediation actions.
Establish a feedback loop for false positive management—When DLP or ATP policies generate false positives, collect feedback from business owners, adjust policies accordingly, and validate changes in a non-production environment before applying them to production. This improves policy accuracy over time and maintains user trust in CASB controls.
Forward CASB telemetry to the SIEM—Forward inline CASB activity logs, API-DP remediation events, and connector health alerts to a centralized SIEM in real time. Correlating CASB events with identity and endpoint signals surfaces exfiltration patterns that no single control detects on its own.

Conclusion

Versa CASB provides a unified control plane spanning shadow IT classification, SaaS tenant governance, and CASB enforcement across inline and API modes. As with any Zero Trust enforcement control, its effectiveness depends not on initial deployment but on continuous classification, tenant governance, and enforcement discipline across all three domains.