As IT operations began to move from on-premises installations to the cloud, organizations looked for ways to bring security and access controls from internal data centers to cloud operations. One of the tools they found was the CASB — Cloud Access Security Broker. Now, a decade on from their introduction, CASBs are common parts of the enterprise security infrastructure. But for many individuals, knowing precisely what a CASB does — and why it’s different than a next-gen firewall — is still something of a mystery.
Let’s look into the CASB and find out where it came from — and what it’s evolved into.
The original purpose of a CASB was to provide visibility into all the cloud services in an enterprise infrastructure. In the war against “shadow IT” and its use of unapproved cloud services, the CASB was one of the first purpose-built weapons. Deployed at the network edge and using a variety of proxy types, the CASB could identify every call to or connection from a cloud service, whether or not the cloud was approved.
In the early days of CASB, they were frequently deployed as physical appliances in the customer data center. Now, they can still be deployed as appliances, but are much more likely to be deployed as cloud services themselves, applied in a “security-as-a-service” model. In both cases, today CASBs use both proxies and APIs to identify the greatest possible range of cloud services and to act on the additional functions products are now capable of.
Knowing about the presence of cloud services isn’t the same as doing something about securing them (or enforcing security controls against specific services), so CASB began to evolve to do more for security teams. As it did, the category developed to include what Gartner calls the “four pillars” of CASB — labels taken up by much of the industry: Visibility, Compliance, Data Security, and Threat Protection.
The four areas of function are important in the shared responsibility cloud security model, in which the cloud provider is responsible for the protection of their infrastructure while the cloud customer is responsible for the security of their applications and data.
So what do each of these four pillars really mean, and how can they be used in securing an enterprise cloud? Let’s look at each one.
A CASB should let you know all the horribly insecure cloud services employees insist on using while on your network. While necessary and frightening, it’s not all the visibility a modern CASB can provide. Given the ways that a CASB can seek out and monitor traffic to and from cloud services, it can also tell the security team which employees are using cloud services and how they’re getting to them. This can be useful information when having the “you’re personally destroying our security plan” conversation with rogue workers.
As CASBs have evolved — and especially as they moved to use APIs rather than proxies to increase visibility into cloud activity — they gained the ability to look at the data being moved from one cloud to another, and between on-prem infrastructure and the cloud. In addition to providing security teams with a better picture of an organization’s cloud infrastructure, this allowed the teams to see the data being stored on and processed in the cloud.
Many aspects of regulatory compliance depend on knowing where and how data is stored. Aside from external regulations, many organizations have internal rules on how particular types of data must be stored and treated. A CASB can allow security teams visibility into the state of cloud-bound data so that cases of employees storing — or moving — data outside of policy can be detected and corrected.
With visibility into the state of data in the cloud, a CASB can take the next step toward protecting that data. Acting through the API controls that allow the CASB visibility into transactions (such as those between cloud services) that never enter the enterprise network, CASBs can enforce policies like data encryption or obfuscation, specific requirements for authentication and access controls, and other parameters to insure that data is stored in a safe manner.
“Access” is written into the very name of a CASB, and products in the category can provide threat protection by enforcing access and authentication controls for data and applications in the cloud. In many cases the CASB will monitor activity and enforce policies by interacting with existing single-sign-on or identity as a service tools. That ability to integrate with existing security infrastructure is one of a CASBs strengths, along with another that separates a CASB from other tools.
While next-gen firewalls, web application firewalls, and other security tools are generally considered complex to set up to greatest advantage, the CASB has traditionally been a tool that is relatively easy to configure and deploy, even for less experienced security teams.
Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and … View Full Bio