Cloud Access Security Brokers are now an integral part of any organization’s IT security infrastructure. IT leaders are realizing just how important cloud security is. As more organizations move to the cloud and more employees rely on cloud-based SaaS applications, such as G Suite and Office 365, the need to secure data in the cloud is greater than ever.
IT leaders are much more aware of what cloud access security brokers (CASBs) are than they were just a couple of years ago. But, in the short time since the term was coined, there have been some changes in available technology that beg the question: Is it time to remove the “broker” from cloud access security broker?
The dictionary definition of a broker is one who acts as an intermediary, this is how you can think of a “broker” in the cybersecurity world.
A broker routes traffic from inside a network to the Internet (and vice versa), the extent to which it is able to filter and control this traffic depends on the type of broker. In the early days of cloud security, all the available technology was built using some sort of broker. This includes gateways, proxies, and agents—all of which are lumped into the generic term “broker”.
So, what is a CASB? CASBs are enforcement points between a customer and a cloud service vendor. The term was coined by Gartner in 2014 to help describe the relatively new industry of cloud security vendors. The first CASB Gartner Magic Quadrant was published in 2017.
At the time, most CASB vendors were still using a broker-type appliance to secure access to cloud applications. These types of solutions work like a firewall; they take information that is trying to gain access to a company’s internal network from the Internet, and filter it through policy enforcements. If the information is flagged by the firewall or CASB, access is rejected. In fact, the traditional CASB is so much like a firewall that it usually duplicates the security controls most companies already have in place, which increases cost and complexity.
Most CASB solutions claiming to use a “broker”, are simply using an agent or proxy. Some use browser extensions and call their product “agentless”. While they’re not using an agent specifically, they are still using a broker.
CASBs don’t need a broker per se. It’s a term that was created before API cloud security technology entered the market space, but it is important to know that there are distinct differences between an API vs. proxy CASB.
Proxy-based CASBs (or any CASB that uses a type of “broker”) put a checkpoint between the user and the cloud application to check and verify before granting access to the app. The biggest benefit is that it can take security action in real-time, and some can stop an outgoing email that contains sensitive information, based on the organization’s data loss prevention policies, even after it’s been sent.
The disadvantages are that broker-based CASBs can be cumbersome to set up and deploy, they significantly reduce network speed and slow down user productivity, and they don’t have the ability to monitor the behavior within a cloud app. They simply filter information going in and out of the cloud app within the organization’s network. Broker CASB security can also be broken merely by cloud application updates.
API-based CASBs don’t actually use a broker at all. While these types of platforms still fall under the Cloud Access Security Broker industry category, they don’t really fit the literal term. They’re more like Cloud Application Security Platforms (CASP) because they build deep, one-to-one integrations with cloud apps using native APIs. This is important because API CASBs are able to function almost like a native feature of the application it secures.
The main benefit of API-based CASB architecture is that it can be up and running (and securing) the data in your cloud applications in mere minutes. They also don’t place any sort of filter between user access and the application, so it doesn’t slow down network speed and it won’t impact end-user experience. API CASBs can monitor and control behavior within cloud applications at a much deeper level, ensuring that your actual information and data are protected, instead of just the perimeter.
The disadvantages of an API-based CASB are that there can be a split-second delay in some security functionalities. They also cannot stop outgoing emails after they are sent like a broker CASB can. Because, again, there is no appliance between the application and user access. Both of these disadvantages; however, are usually covered by a company’s firewall and/or secure gateway that are already installed.
Perhaps it’s merely a case of semantics. But the distinctions in how CASB solutions work is important for anyone looking to secure company data that is stored, accessed, and shared in the cloud. More expensive and more complicated does not mean more secure. Your choice in cloud application security should rely on more than just a magic quadrant, it must take into account your organization’s needs and the IT security infrastructure that you already have in place.