Many customers that deploy Cloud Access Security Broker (CASB) solutions to secure their shadow, sanctioned and custom IaaS apps very quickly realize that they need to navigate through different deployment options to secure their users and data across mobile, desktop, remote and on-prem users.
Gartner recommends that customers consider a multi-mode deployment (aka traffic steering) CASB solution to cover all their use cases across all users, devices, and services. However, not all deployment modes are equal – they vary significantly in terms of the use case coverage, complexity, friction, and return of value for the investment.
Based on the experience from hundreds of customers that deployed CASB solutions at scale, we cover some of the highlights here.
CASB Deployment Modes
The CASB deployment modes (aka traffic steering mechanisms) are broadly categorized into the following two categories:
1) Out-of-band deployment modes
These deployment options do not sit in the traffic path of user-to-cloud or cloud-to-cloud. Instead, they use “asynchronous” (out-of-band) APIs to receive all cloud service traffic (log events, user activities, data files and objects, configuration state etc.) for the CASB platform to do security analysis and neforce the necessary policy action (e.g., quarantine, delete, change permission, coach, and block high risk services etc.)
The main advantages of out-of-band deployment modes:
- Zero friction: These modes do not result in any change in user experience such as adding latency to user experience or breakage of application behavior. In addition, the deployment usually takes hours to set these up.
- Universal coverage: The API-based solutions cover not-only the “north-south” (user-to-cloud) traffic but also provide coverage for “east-west” (cloud-to-cloud) traffic. As cloud adoption increases in organization, cloud-to-cloud traffic becomes the significant portion of cloud usage in any organization.
- Ability to introspect traffic: Inline security solutions can only apply changes in security policies for the new traffic coming forward. However, the APIs allow you to retrospectively apply the policies for all data-at-rest, including all new traffic.
The main disadvantages of out-of-band deployment modes:
- Limited real-time policy enforcement: The APIs usually have latency from 15s – a few minutes for the event to come to the CASB platform to enforce policies. This may not be applicable for all use cases. However, some of the major cloud service providers are now providing “synchronous API” mode to mitigate this issue. CASB platforms, such as Skyhigh, have built advanced APIs to reduce the latency to sub-1 minute response times, per contractual SLAs (Service Level Agreements), for very near real-time DLP enforcement via API, and real-time enforcement for collaboration control policies via synchronous API.
- No contextual access control policies: To enforce some real-time policy use cases such as “granular access controls based on device, location”, CASB needs the real-time context in order to apply the control. In the future, many cloud service providers will provide this – but at this time, this capability can only be available using the “inline modes”.
2) Inline Deployment modes
These deployment modes usually refer to a “proxy” that sits in between the traffic from “user-to-cloud” – and in some cases between “cloud-to-cloud”. The CASB proxies primarily come in two flavors 1) Reverse Proxy and 2) Forward Proxy.
- Reverse Proxy: A reverse proxy is usually referred to as “last mile” technology that sits in front of a cloud service (e.g. Salesforce, Box, Office 365 etc.) to provide inline security capabilities.CASBs seamlessly integrate into the IDaaS (Identity-as-a-service) solutions such as Okta, OneLogin, and ADFS so that users are automatically “steered” to the CASB reverse proxy upon successful login using the SAML/SSO solution. This results in the best user experience and no-friction – and also no ‘security concerns” related to SSL man-in-the-middle.
- Forward Proxy: A forward proxy is usually referred to as “first mile” technology that sits closer to the user, proxying traffic to many cloud services. The forward proxy uses “SSL man-in-the-middle” technique to inspect the cloud traffic for users.CASB’s use a variety of mechanisms to “steer” users’ traffic to the CASB forward proxy, including:
- PAC Files: Users’ browsers or devices (agents) are configured with proxy PAC files to route the “cloud services” traffic to the CASB forward proxy – and all other hosts go to the regular proxy or direct. The main disadvantage of the PAC files are that they can easily be circumvented by the users – and require more intrusive config changes for enforcement.
- DNS Redirect: Customers DNS can be configured with a special forward zone for the “select cloud services” so that the cloud service hostnames are resolved to the CASB forward proxy. The main disadvantage of this mode is that many customers do not want an external entity to dynamically modify the DNS entries in their environment – and, in many organizations, DNS is managed by a different group or an outsourced entity.
- Proxy Chaining, Advanced Forwarding and TAP: In this mode, customers configure their existing proxy or NGFW (Next-gen firewall) to forward the selected cloud services traffic to the upstream CASB forward proxy using one of the advanced forwarding, chaining, or TAP mechanisms. In this mode, the forwarding can be done in the “passive” mode for visibility only or in the “active” mode for full enforcement. The main disadvantage of this mode is the increased friction in configuring these rules on many egress proxy/FW devices, and figuring out how to do SSL MITM on one or more multiple locations.
- Agents: In this mode, customers deploy “agents” (yet-another-agent) on the users’ endpoints to intercept the selected cloud services traffic to the CASB forward proxy using a secure VPN tunnel. The main disadvantages for the agent approach is that this causes the most friction as most agents do not work well with each other (AV agent, DLP agent, VPN agent, Proxy agent, Config Management agent plus CASB agent) and sometimes result in BSOD (Blue Screen of Death). In addition, agents only work on managed corporate devices leaving the BYOD use cases completely unsecured.
Important: To mitigate the challenges with deploying multiple agents, Skyhigh CASB introduced a “One Agent” solution that seamlessly works with your existing SWG Proxy resulting in consistent security policies and user experience for mobile and remote users.
CASB Deployment Modes Coverage Matrix
From the above deployment modes, customers are often challenged to select one or more deployment modes for their CASB solution. The following chart gives a simple matrix on the various deployment modes – and the use case coverage.CASB deployment modes best-practice ROI recommendations
While a customer would need all the deployment modes (Logs, API, Reverse Proxy and Forward Proxy) to cover all use cases across all users and devices for shadow, sanctioned, and custom apps, the complexity, friction, and the use case priorities result in a different ROI based on the deployment modes.
Using the Cloud Governance framework developed by the Skyhigh customer community, here are our recommendations for customers on prioritizing your “CASB deployment journey”.
The summary recommendations are as follows:
- Customers get the most value per investment by deploying the “out-of-band” deployment modes – Logs and API. This covers both shadow and sanctioned services – particularly the most widely used services such as Office365, Box, Slack, Dropbox, Google and Salesforce.
- Customers can add a reverse proxy to add some of the inline use cases such as device access control, encryption, EDRM for the most valued cloud services such as O365, Salesforce and ServiceNow.
- Customers can then incrementally add one of the forward proxy options (agent or proxy chaining) to add additional use cases such as advanced shadow IT controls.
For more detailed information on each deployment mode, how they work, what specific use cases they cover, please refer to the following Skyhigh resources:
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.