New eBook: Which CASB Deployment Architecture is Right for …
Breakdown of the features, devices, and access scenarios covered by each architecture
When enterprises embark on a cloud security project, they usually discover pretty quickly that there are multiple ways to deploy a cloud access security broker (CASB). Deciding on the right architecture for your project is one of the most important decisions you’ll make since it impacts what CASB features you’ll be able to apply to which users, devices, and services and under what conditions. The enforcement point in the on-premises era was clear – it was at the network edge. In the cloud era, the perimeter is undefined. When deploying a CASB, how do you ensure you have visibility and control over all users, all devices, and all cloud services?
The primary deployment modes for a CASB include:
Log collection – consuming event logs from existing infrastructure such as firewalls, secure web gateways, and SIEMs. Generally, logs capture user activity but not content.
Forward Proxy – inline deployment between the endpoint and cloud service in which the device or network routes traffic to the CASB proxy.
Reverse proxy – inline deployment between the endpoint and cloud service in which the cloud service or identity provider routes traffic to the CASB proxy.
API – direct integration of the CASB and cloud service. Depending on cloud provider APIs, the CASB can view activity, content, and take enforcement action.
Deciding on the right architecture for your project goes beyond ease of deployment, although this is an important consideration. There are key CASB features that, due to the nature of how they work, are only available in one or more deployment modes and not for others. When assessing a CASB, you’ll want to confirm the solution supports deployment modes you need now and in the future. In most cases, enterprises combine multiple deployment modes to achieve complete coverage. In Gartner’s latest CASB report How to Evaluate and Operate a Cloud Access Security Broker (download a complimentary copy here), they note:
CASB features supported by each deployment mode
At McAfee (formerly Skyhigh Networks), we offer all four CASB deployment modes and customers frequently ask us which ones are right for their use cases. The availability of a feature is not just dependent on whether a vendor has built it, it’s dependent on whether that feature is even feasible in that architecture. Simply put, some features are possible in one architecture, but not in another. For example, you can scan data stored at rest via cloud app APIs, but you cannot scan data already stored in the service via an inline proxy. We’ve compiled a reference below showing key CASB capabilities and whether they are feasible for each deployment mode.
Log Collection
Forward Proxy
Reverse Proxy
API
Top-level usage statistics (which employees use which services)
·
Risk assessment (risk profile of cloud services in use)
Detect enforcement gaps (access of apps not effectively blocked)
Collaboration analytics (sharing permissions on files/folders)
Activity monitoring (audit trail of user and admin actions)
Detect insider threats
Detect compromised accounts
Detect malware (exfiltrating data via unsanctioned apps)
Detect malware (stored within sanctioned apps)
DLP inspection (data at rest within sanctioned apps)
DLP inspection (data in transit)
DLP enforcement (quarantine, delete, modify collaboration)
DLP enforcement (block, tombstone)
Security configuration audit (security settings of apps)
Encrypt data (at rest in cloud apps)
Encrypt data (in transit to the cloud)
Decrypt data (for end-user access)
Manage access (based on device, user, location)
Policy-based authentication (require two factors)
Apply rights management (to data on download or upload)
While this table is a simplification and there are nuances not captured here, it gives a good overview of what capabilities to expect with different CASB architectures.
Log collection is a natural starting place for many CASB projects because companies need to scope their cloud usage before determining their security policies and priorities. Log collection, when paired with a robust cloud registry, provides a high-level overview of all cloud apps in use, data volumes uploaded to the cloud, and the risk of those apps. For enterprises that decrypt SSL, these logs can also provide detailed insight into the activities performed within cloud apps. However, logs from egress infrastructure do not provide insight into the content flowing to and from the cloud. For visibility into content, you will need an inline proxy and/or direct API connection to the app. Log collection is also a monitor-only mode, with the caveat that you can enforce coarse level allow/block policies for cloud services if your CASB integrates with your firewalls and proxies. To enforce granular policies based on specific data types and activities, you will need to augment log collection with another mode.
The two inline proxy modes – forward and reverse proxy – offer a similar set of capabilities. The real difference between the two comes down to coverage for users, devices, and access scenarios. We will cover those in the following sections. For now, note that both inline proxy options offer the ability to inspect content to and from the cloud and enforce real-time policies (such as blocking an upload to an app, stopping download to an unmanaged device, etc. ) While a CASB can encrypt existing data in a sanctioned cloud app via API, an inline proxy is needed to decrypt data for end users accessing the app, so they see their data, not cipher text.
The API mode is the only way to inspect content stored at rest within cloud apps since an inline proxy only has visibility into data uploaded to the app after the proxy has been deployed. Since many enterprises already have a large volume of data stored in the cloud, the API mode is used to enforce policies on this data. Other capabilities only possible when connecting directly to an app via API include the ability for the CASB to scan security configuration settings within the app and suggest changes that bolster security, as well as the ability to scan the sharing permissions on files and folders to assess the risk of third-party and external access to corporate data.
Now that we’ve looked at what core capabilities are possible in each deployment mode, let’s take a deeper look at coverage for cloud access scenarios commonly found in enterprises today:
Sanctioned vs. unsanctioned apps
On-network vs. off-network users
Managed vs. unmanaged devices
Data at rest vs. data in motion
IT control over the app
If you’re like most organizations, your employees use a combination of cloud apps that are sanctioned and delivered by the IT department, as well as apps employees introduce themselves that are not sanctioned by IT. Within the apps that are not sanctioned by IT, you find a mix of apps that IT may choose to permit, as well as those that are not suited to store corporate data. To fully secure corporate data in the cloud, you need to consider sanctioned and unsanctioned cloud applications and deployment architectures that cover each.
If you think about the placement of a visibility and enforcement point for the cloud, sanctioned and unsanctioned applications present very different scenarios. For unsanctioned cloud apps, you want to ensure the broadest range of coverage for all cloud apps that employees use. Log collection and forward proxy modes are both first-mile deployment modes – they provide coverage for all apps that a user accesses. For sanctioned applications managed by IT, it makes more sense to focus on enforcement at the last mile to extend coverage to the broadest range of users. Both API and reverse proxy modes are well suited to provide complete coverage for all users and devices accessing a specific cloud service managed by IT.
Unsanctioned
Sanctioned
Log collection (monitor only)
Forward proxy
Reverse proxy
Unsanctioned cloud apps – which may or may not be permitted – fall under the log collection and forward proxy modes. Collecting logs from egress infrastructure provides coverage for all cloud apps in use by the user. Similarly, routing cloud traffic through a CASB’s forward proxy provides deep content-level visibility and control for unsanctioned cloud apps. There are key functional differences between these two modes that are outlined in the preceding section. Log data generally captures usage and individual activities, but not content. The forward proxy mode adds support for content inspection and inline control.
The most common deployment modes for sanctioned apps managed by IT are API and reverse proxy. Both may be deployed to provide broader feature coverage not available in one mode or the other (e. g. data at rest and in motion). Since a sanctioned app is managed by IT, it’s possible to connect the CASB to the cloud app via the cloud provider’s API for visibility and policy enforcement. Similarly, IT can configure traffic routing after authentication through the CASB’s reverse proxy. While a CASB’s forward proxy mode can be used to secure sanctioned cloud apps, there are some device limitations that, in practice, make the coverage for API and reverse proxy modes more comprehensive. We’ll cover that in the next section.
Device and access scenarios
Log collection is well suited to provide coverage for on-network access of cloud apps. On the network, a firewall and SWG capture traffic destinations in their log files. Managed devices off-network that are configured to route traffic through a cloud-hosted SWG provide additional insight into cloud activity for corporate users on the road or at home. There are many similarities between the device and access scenarios that log collection and forward proxy support. They both provide coverage for on-network devices, as well as off-network managed devices. They do not provide coverage for off-network unmanaged devices.
On-network
Off-network
Managed
Log collection
Unmanaged
There are several ways to route traffic through a CASB’s forward proxy. Similar to an SWG deployment, you can install an agent on the endpoint or configure the network to route traffic through the CASB. Many organizations have already deployed a secure web gateway (SWG), and in this case, you’ll likely want to chain cloud traffic from the SWG to the upstream CASB proxy rather than split traffic at the endpoint. Proxy chaining has the benefit of avoiding a potentially painful agent rollout and ensuring cloud traffic does not bypass controls in your SWG.
One of the limitations of the forward proxy architecture is that it does not cover off-network unmanaged devices. The reverse proxy mode covers the same device and access scenarios as the forward proxy mode as well as off-network unmanaged devices. A reverse proxy can support this access scenario because traffic is routed in the last mile during authentication to a cloud application, and therefore the CASB covers all users regardless of their device or network. With growing acceptance of BYOD and remote work, this deployment mode ensures coverage for employees who access cloud apps from personal devices from anywhere – whether the office or the coffee shop.
The API deployment mode connects directly to a sanctioned cloud app via standard APIs and therefore provides coverage for that app regardless of the user’s device or network.
Type of data
Broadly speaking, there are two types of data: data stored at rest in cloud apps and data that is in transit to or from the cloud. It turns out that while the API mode for CASB provides excellent coverage for data stored at rest since its enforcement options rely on the cloud provider, not all enforcement actions are possible. For example, most cloud provider APIs that are leveraged by CASBs do not support real-time controls such as preventing the download of sensitive data to an unmanaged device (while allowing the device to preview the content).
Data at rest
Data in motion
API (near real time)
Forward proxy (real time)
Reverse proxy (real time)
While neither inline proxy modes for CASB cover data already stored at rest in the cloud, they do enable real-time controls. For example, a CASB in proxy mode can block the download of a file containing sensitive data to an unmanaged device that does not have adequate endpoint security controls such as encryption and a password lock. They also ensure that policies are enforced before data even reaches the cloud. For some enterprises, waiting a few seconds for a CASB to enforce a control via API is not fast enough, they need the policy to be enforced before the action occurs within the app. Both proxy modes meet that use case.
For this comparison, we have excluded log collection because, while it provides insight into activity, it does not support content inspection for data in the cloud.
Putting it all together
No single CASB deployment architecture covers all cloud applications, users, and devices under all conditions. For this reason, most CASB projects involve multiple deployment modes working together to provide visibility and enforcement coverage that meets the needs of the enterprise. By assessing the functionality, apps, and users that are most important to you, you’ll be better positioned to prioritize your rollout of a CASB. McAfee has helped over 600 enterprises securely enable their use of cloud services. When you’re ready to begin a cloud security project, our team of cloud enablement specialists would be glad to assist you in mapping out a solution architecture that meets your needs.
Cloud Access Security Broker (CASB) Deployment Modes …
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.
Download the CASB Magic Quadrant
Download the inaugural MQ report that identifies and analyzes CASB leaders
Download Now
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 McAfee, 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 CASB 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 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/CASB 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 ’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 CASB deployment modes, customers are often challenged to select one or more deployment modes for their CASB solution. The following CASB diagram gives a simple matrix on the various deployment modes – and the use case deployment modes best-practice ROI recommendations
While a customer would need all the CASB 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.
Additional references:
For more detailed information on each CASB 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.
API vs Proxy CASB: Which Is Right For You? – ManagedMethods
The differences between an API vs Proxy CASB are important to understand for your organization’s cloud security
To understand why there are differences in an API vs. Proxy CASB, we must first look at where the term cloud access security broker, or CASB, came from. It was coined by Gartner when the first proxy-based CASBs started making it big in the cybersecurity market—approximately around 2012/2013.
Gartner defines a CASB as: “on-premises, or cloud-based security policy enforcement points, placed between cloud service consumers and cloud service providers to combine and interject enterprise security policies as the cloud-based resources are accessed. ”
[FREE CHECKLIST] MAKE SURE YOUR G SUITE AND OFFICE 365 SECURITY SETTINGS ARE PROPERLY CONFIGURED >>
CASB architecture has changed significantly in just several short years. New approaches to the cloud security problem have stretched the original definition of CASB. These changes have made it difficult for those in charge of organizational information security to determine what type of CASB solution is right for them. Here, we’re going to take a quick look at the differences between an API vs Proxy CASB and help point out the differences, pros, and cons of each.
Proxy-Based CASB
When the CASB was first born, the technology used what is known as a proxy to secure cloud traffic and activity in an organization’s environment. At the time, this was a breakthrough in cloud security. IT and InfoSec teams could secure multiple cloud-based SaaS applications using a single solution, rather than layering disparate security functions for each app.
From PC Magazine, a proxy is a system or router that breaks the connection between sender and receiver. It is one of several tools used to build a firewall that protects private networks from hackers.
In a CASB solution, a proxy acts as a gateway that checks for known users and devices as they attempt to access information stored in the cloud. The benefit is that proxies can take security action in real time.
Proxy-based CASBs will often use a forward proxy, but some use reverse-proxy only technology. No matter what type of proxy the solution uses, the most common issues with a proxy-based CASB is that it causes significant delays in network performance and only secures known users. As you can imagine (and have likely experienced yourself) this causes big problems for those in IT and InfoSec, as well as for employees and other important stakeholders trying to access information quickly.
In early 2018, Microsoft released a blog post discussing it’s position on using proxy-based CASBs with its Office 365 SaaS product. Basically, Microsoft does not recommend using proxy CASBs. Though the company does not block customers from using them, they also don’t support the inherent performance and security issues that results from them. They also note that the company may make changes to protocols, authentication methods, and more without notifying vendors that could render proxies, or other 3rd party “man in the middle” cloud security solutions, ineffective. The article states that they will only notify 3rd party vendors using their documented public APIs of important changes.
Further, if you already have a Next-Gen Firewall (NGFW) and/or Security Gateway (SGW) in place, a proxy-based CASB is likely duplicating the functions that you already have, while adding cost and complexity to your data security infrastructure.
Because of these known issues with proxy-based CASBs, a new generation of cloud access security was born. Built entirely on APIs.
The New CASB
From, API stands for “Application Programming (or Program) Interface. An API is a set of protocols used to create applications for a specific operating system or to interface between the different modules of an application. ”
Once the CASB concept was born, it didn’t take long for some smart people to realize that there was a better way to secure data stored and shared in the cloud. Rather than simply re-apply old school technology to the new era of computing, they figured out a way to use cloud application’s native APIs.
The new breed of API-based CASB provides users with direct, secure access to the cloud from any device, anywhere in the world with no impact on network performance. It provides IT and InfoSec teams to customize access rules, automate compliance policies, and more. They gain visibility into activity in the cloud that proxy-based CASBs are not able to provide, giving them the upper hand when it comes to compliance, threat protection, and data security.
Rather than duplicating security features that many organizations already have, like proxy CASBs do, API-based CASBs integrate with in-line security solutions, such as NGFW and gateways. Rather than duplicating functionality, it’s an additive solution to your layered data security architecture.
Is CASB Still The Right Term?
For lack of a popular, and accurate, industry term, API-based cloud security platforms have continued to use the term CASB to define their product. But it’s not really accurate. The main difference is in the definition “…placed between cloud service consumers and cloud service providers…”
As we’ve learned, and API-based CASB doesn’t put anything between the consumer and the provider. It is integrated, almost as much a part of the application (“provider”) as the features of the app itself. That is what it’s time to retire CASB and start thinking in terms of the Cloud Application Security Platform (CASP). The difference is far more than semantics, it’s a fundamentally different (and better) way of securing your sensitive data stored, accessed, and shared in the cloud.
Frequently Asked Questions about casb forward vs reverse proxy
Is CASB a reverse proxy?
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.May 1, 2017
What is a CASB proxy?
In a CASB solution, a proxy acts as a gateway that checks for known users and devices as they attempt to access information stored in the cloud. The benefit is that proxies can take security action in real time. Source: Cloud Security Alliance.Jan 22, 2019
Is zscaler a CASB?
Zscaler and CASB The Zscaler Cloud Security Platform provides full inline CASB functionality to protect all users, on- or off-network, and gives you real-time visibility into all incoming and outgoing traffic along with granular controls.
