Cloud access security brokers (CASBs) extend an agency’s security policy to third-party cloud services, providing visibility into the cloud services an agency uses and then building policies to control the usage of sanctioned versus unsanctioned cloud apps.
That makes a CASB a critical cloud security tool.
But is it enough on its own for the federal government’s data security needs?
The answer is sometimes yes and sometimes no. Why? Because CASBs do not provide security protection features, such as (but not limited to) web content filtering and advanced threat protection. For that level of security, the CASB needs to be bundled with a secure web gateway (SWG).
An SWG protects enterprises and users from cyberthreats while enforcing corporate policies.
A cloud-delivered SWG may also implement functionalities found in CASB through its inherent deployment model—inline visibility provides protection and enforcement for cloud apps.
It is imperative to determine if:
The first step is to look at the four implementation areas for CASB solutions in the market today: forward proxy, reverse proxy, out-of-band CASB, and log parsing.
The next step is to look at how stand-alone CASB works with each.
There is no forward proxy service that exists as part of a platform to provide active blocking and protection. Some CASB providers partner with an SWG security vendor to integrate with the log parsing scenario.
For example, Microsoft partners with Zscaler to provide the SWG for its Microsoft Cloud App Security (MCAS). In 2019, Zscaler was awarded the Microsoft Technology Partner of the Year in part because of the integration we built with MCAS.
There is no reverse proxy capability as part of a CASB service. An SWG can enable this use case through the identity proxy functionality. This capability enables an agency to build policy from within the vendor’s app that prevents a user from signing on to a protected cloud application unless the traffic to the cloud application is sourced from the vendor.
Out-of-band CASB is accomplished through an API-based approach for connecting to supported cloud app services and scanning content at rest, as well as through activity indicators associated with supported cloud apps. Blocking capabilities are subject to the limitations of the supported cloud service partners. That means only a subset of integrations may support the app functions.
MCAS covers log parsing via the use of a log ingestion service. This is handled through one of the following approaches:
Log parsing only provides visibility into traffic violations (for example, users accessing an unsanctioned cloud app) and configuration of governance policies around which cloud apps are blocked. There is no actual blocking of the traffic (enforcement) function.
A technician, such as a SOC resource, needs to perform that function manually to correlate cloud app usage and identify violations—based on the log data fed to the CASB—to a policy (block script) on a third-party traffic inspection device, such as a web content filter or firewall. There is no way to correlate and validate that a third-party device has all the blocks that are configured in the CASB without doing a manual audit. That enforcement/blocking function would need to be scripted manually if the CASB vendor does not have out-of-the-box integrations for third-party tools.
CASB is a fantastic tool that every federal agency should be using to make data more secure. However, it does not meet all of an agency’s security needs by itself. When sourcing a CASB solution, make sure your vendor of choice has an integrated SWG or is partnering with a provider that does.