kentoh - Fotolia
Choosing between proxy vs. API CASB deployment modes
Curious how to choose the right CASB deployment mode for your organization? Before you buy, compare how proxy vs. API CASB architectures work to secure SaaS applications.
SaaS can be difficult for cybersecurity teams to secure. On one hand, SaaS looks nearly identical to other types of user-initiated web traffic. This makes it difficult to monitor and prevent users from employing unexpected services, known as shadow IT.
On the other hand, unlike IaaS and PaaS, the entirety of the application stack is within the operational purview of the provider. This can be a challenge for infosec teams that are unsatisfied with the security measures employed by the SaaS application. Opportunities to introduce new controls not provided natively by the service provider, such as encryption or enhanced monitoring, are constrained.
Cloud access security brokers (CASBs) help address these issues, which has made them popular among organizations with SaaS security concerns. In fact, 89% of organizations are researching or already using CASB offerings, according to a recent survey from Cloud Security Alliance. Additionally, CASBs offer better visibility into cloud services used, encrypt data, bolster monitoring and address shadow IT considerations in the cloud.
With that in mind, let's examine how a CASB works, beginning with its two modes of operation: proxy-based and API-based. Understanding these differences will be critical when evaluating which might be a better choice for your organization.
Comparing 2 CASB deployment modes
1. Proxy-based CASB
The first mode of operation for many CASB tools is proxying. This CASB deployment mode operates as an HTTP proxy, which sits between connections among users and the remote SaaS provider. There, the CASB has visibility into the traffic as it passes through the proxy. This positioning enables CASBs to make changes to the application data stream to add additional controls, such as encryption, as well as record and monitor events that happen within the application, such as access attempts, logins or use of functionality. The proxy-based CASB architecture also acts as a participant in the overall application session.
There are two fundamental modes for HTTP proxies: forward proxy mode and reverse proxy mode. Many CASB products operate as either one but, in some cases, both. A forward proxy is known to the user's agent -- the browser -- and the agent is configured to relay traffic to the proxy, as seen in Figure 1.
In contrast to forward proxy mode, a reverse proxy intercepts traffic bound to a particular destination, acting as a proxy transparently without the browser knowing about it. This is illustrated in Figure 2.
To better understand how proxy CASB architectures work, consider a case where a user wishes to access a SaaS application on the internet. First, the user makes a request to the remote service. But, instead of the user's session being directed to the cloud provider's service, its traffic is routed to the proxy instead. The proxy initiates a new request on behalf of the user with the web service and relays data sent between the user and the remote service. It is at this point that the CASB can add security-relevant functionality. These functions may include encrypting and decrypting data sent to the service, logging actions taken by the user and blocking the user from performing certain actions, as well as filtering or blocking data.
The primary advantage of a proxy mode CASB is flexibility. Because the CASB operates on the underlying data stream directly, it can service even SaaS applications that it might never have encountered before.
However, there are three primary downsides to keep in mind. First, there are the obvious performance considerations of having one device act as a proxy for a large volume of internet traffic. Second, there is the architectural issue of where to host the CASB -- whether internally or externally -- to minimize performance affects and likelihood of a single point of failure. Third, and perhaps most importantly, is the question of how TLS sessions must be handled for the CASB to function effectively.
Remember that one of the goals of TLS is to prevent an attacker from intercepting communications between a user's browser and destination -- typically a website. However, since the CASB requires access to the HTTP stream to perform its function, it will often purposefully break or intercept the TLS session so that it can operate on the underlying session contents. Because of this, the CASB must perform much of the security decision-making that would ordinarily be performed by the browser. For example, checking certificate revocation or expiration status, validating certificate common name values match the requested DNS domain and negotiating appropriate cipher suites.
Making these effective security decisions can be challenging. If a check fails, appropriately informing the user that something is amiss can become difficult. It is for this reason that service providers, such as Microsoft, have actively recommended against taking protocol-level action for services, including Microsoft 365. The U.S. Computer Emergency Readiness Team has also issued technical guidance about risks that can be introduced when TLS sessions are purposefully broken.
2. API-based CASB
The alternative CASB deployment mode is API-based operation. In this case, the CASB builds the additional desired security functionality directly into the SaaS using the SaaS's own development API. Instead of operating at the level of the underlying application transport protocol (HTTP/HTTPS), the functionality is written using APIs supplied by the cloud providers themselves to interface with the SaaS service.
One advantage of an API-based CASB deployment mode is that it does not have the TLS and session management issues of proxy mode. However, the APIs developed and exposed by SaaS providers are generally unique to their service offering. Thus, a given API-based CASB vendor offering will likely work only in the context of a particular SaaS. For example, a product developed for Microsoft 365 may not be compatible with Google Workspace and vice versa. For this reason, customers should begin the purchasing decision process with a clear idea of which supporting SaaS applications are necessary.
Weighing the prospects of proxy vs. API CASB architectures
Over the years, some have argued that API-based CASBs will ultimately eclipse proxy-based models. It is possible; there are architectural complexities associated with proxy modes of operation, which can be a challenge.
Ultimately, deciding between a proxy- or API-based CASB deployment model should be informed by what services are in use, as well as the organization's technology and business context. It will also depend on the organization's use cases for the CASB offering. For example, SaaS application discovery as an alert point for shadow IT is a germane use case. It can be harder for API-based models to provide as much value there.
Keep in mind that many product offerings employ a blended strategy. Some vendors may provide the option of API or proxy mode, have support for both simultaneously or offer additional functionality -- such as automated parsing of log files -- to bolster discovery.
