How to evaluate CASB tools for multi-cloud deployments
When it comes to evaluating CASB tools, it's essential to be an informed customer. Identify your organization's usage and security goals to get the context you need before you buy.
In the abstract, having more of something does not necessarily mean more complexity or time investment. Sometimes, it does, but it's not a given. For example, consider the difference in time investment between baking one muffin as opposed to baking a dozen. After baking the first initial muffin, how much more work and time is added in baking the next eleven in the batch? Not much. You still must complete all the same steps: measure out the ingredients, prep the oven, bake and cool. With a few minor exceptions, each incremental step is about the same duration to complete with one as it would be with 12.
Now, modify the example slightly. Imagine that, instead of baking 12 of the same muffin, you decide each of the 12 in the dozen will be different kinds of muffin -- one is corn, one is oat, one is blueberry and so forth. In this case, there is considerably more work added when baking a dozen.
Sometimes, adding more requires a disproportionate amount of complexity or time investment, and sometimes, it doesn't. That's because the specifics of what is added -- and how it is added -- dictate if and how much extra work is required.
Believe it or not, there is a direct parallel between this hypothetical and how we select controls, such as cloud access security broker (CASB) tools or gateway products, for multi-cloud environments. There are situations where adding new SaaS offerings adds little in the way of extra time or complexity to a CASB deployment. Conversely, there are other situations where they add quite a bit of time and effort or worse: They are simply not tenable for the intended use case.
The devil is in the details. Understanding where and why these cases vary is useful because it can help organizations decide how architecturally to employ the CASB tools and, therefore, what factors to consider when evaluating options in the marketplace.
CASB modes of operation
CASB tools are designed to layer additional security functionality on cloud services -- usually SaaS. Additional features may include authentication, encryption or monitoring. Such tools make up for any features that are not natively supported by the cloud service but that the customer deploying the CASB needs to control risk, meet compliance requirements or otherwise adhere to organizational policy.
CASB tools generally operate in one of two ways: either via proxying or via API integration. The proxy model sits between a client's browser and the remote destination SaaS web server. Depending on the features targeted, this can be considered intrusive to normative web browsing. For example, controlling access to SaaS options or enforcing whether users can go to certain SaaS offerings, a CASB might operate in a manner directly analogous to a traditional HTTP forward proxy. By this, I mean it will respect the HTTP CONNECT verb from browsers, enabling it to tunnel Transport Layer Security traffic to the remote destination without terminating the TLS session.
Approaching a decision like this means being an informed customer.
Some features, such as encryption, require CASBs actively inject or modify content as it flows between a browser and the remote SaaS -- for example, to enable encryption of data sent by the browser. Another tool might terminate the TLS session at the proxy and initiate a new TLS session on the back end between it and the destination.
By contrast, the API integration model uses the native API features built into a SaaS offering to accomplish the same goal. Instead of proxying the traffic, it instead builds new features on top of SaaS offerings that add the additional security functionality desired.
This difference in the architectural deployment model is one of the more significant factors to consider when it comes to the amount of complexity involved in supporting multiple SaaS offerings on the same SaaS. As you can imagine, the APIs offered from vendor to vendor vary significantly. For example, the API feature set supported by Office 365 is different from that offered by Salesforce, which, in turn, is different from Slack or Concur. The support offered for a service by the SaaS vendor is extremely important then for this model.
Selecting an approach
Which approach is better for your multi-cloud SaaS usage? It depends on the context. If an organization's multi-cloud deployment supports a small subset of different product offerings -- all of which can be accommodated via an API integration approach -- it may favor that API integration approach. Should an organization's usage be a complex mix of dozens or hundreds of smaller, more niche SaaS offerings, it may find a proxy model is the only alternative that can support its usage. Should an organization lie somewhere between these two extremes a hybrid approach -- in which a product supports both proxy and API integration models depending on SaaS -- may be the right fit.
It is critical to factor in both usage and security requirements when evaluating CASB tools. There is often more flexibility in a proxy model as they are less directly coupled to the specific API of the SaaS offerings. However, there are other concerns with a proxy model. For example, Microsoft recommends against it for Office 365, and the U.S. Computer Emergency Readiness Team issued an alert about HTTPS interception as products that purposefully break the TLS connection can, in some cases, undermine the security of the TLS model -- for example, by failing to check certificate revocation status.
Approaching a decision like this means being an informed customer. Customers need to understand their own usage, including what SaaS offerings they intend to secure. It starts by building an inventory of what the organization is using and how. Next, customers must identify their own security goals. Is the organization looking to prefix authentication to SaaS usage because it wants to control shadow IT? Or does it have a contractual requirement that demands the organization encrypt data stored at third parties or outside its environment? Understanding an organization's own context is paramount.
