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.”
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.
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.
From Dictionary.com, 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.
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.