3 Must-Know Pieces of Cloud Access Security Brokers
Knowing what CASBs can offer will help you find the right fit.
Let’s dive into one of the most buzzworthy cloud security topics today: cloud access security brokers, or CASBs (pronounced KAZ-bees). Previously, I discussed securing your organization if you use any cloud apps. Having a CASB in place is one of those critical components of a layered security approach with cloud-based apps. We already discussed the basics, so let’s dig a little deeper into how this is deployed and what may be the best fit for you.
Since Software as a Service (SaaS) applications generally offer access to the presentation layer, there can be less ability to change or customize the application to meet your specific policy or standards needed to use it across your organization. CASBs offer three different methods to beef up that security. I’ll review those, and provide a chart to show each of them side by side at the end.
The API Approach
Working on the application program interface (API) level is an out-of-band solution. It doesn’t sit directly between the request and the data. Rather, it works directly with known API’s of specific cloud applications. For example, a CASB that employs API as its primary access protection methodology will have written its software to work directly with cloud apps like Office 365, SFDC, etc. The Cloud Security Alliance has a great diagram to help explain:
SOURCE: Cloud Security Alliance
The Reverse Proxy Approach
Many companies today use a reverse proxy for certain data flows and understand the basic concept. A proxy is an intermediary that sits between a requestor (client) and one or more data sources (servers). This is an “in-line” approach to securing cloud apps because it sits directly in the network traffic path. A reverse proxy broker’s connections are coming from the internet to your app servers. This approach can also hide the information behind it coming from the original source.
SOURCE: Wikipedia.com
The Forward Proxy Approach
A forward proxy is just like it sounds, the opposite path of a reverse. Both use a proxy to sit between requests and data, and both are considered in-line. Forward proxies filter connections going out to the internet from clients sitting behind the firewall. Specific to CASB, the biggest thing forward proxies offer is the ability to integrate any application. While this sounds great, there is always a cost or benefit associated with any feature. The downside to working with any application is that it can be more difficult to deploy, reduces end-user privacy and requires digital certs.
SOURCE: Cloud Security Alliance
There are costs and benefits to all of these approaches. Many CASBs today are employing a hybrid approach and offering a blend of API and proxies as part of their solution. It is important to bring that up and have the CASB explain their offerings when going down these discussion paths.
For further consideration, here’s a breakdown of some of the most important features to look at when considering a CASB for your applications and organization:
| API vs. Proxy | |||
|---|---|---|---|
| API | Reverse Proxy | Forward Proxy | |
| Deployment Friction | Low (out of band; matter of minutes) |
Medium (SAML redirections and app tie-ins) |
High (in-line) |
| App Coverage | Sanctioned (must have API development and access; limited to number of supported apps) |
Sanctioned (need to re-write URL; some custom integration available) |
All applications (several hundred possible) |
| Policies, DLP, Threat Protection | Near real time (policy on objects once in application) |
Real time (prevent before it happens, i.e. during download or upload) |
Real time (prevent before happens, i.e. during download or upload) |
| Inspect Data in Sanctioned App | Yes (inspect data in Box, OneDrive, SFDC, etc.) |
No | No |
| Inspect All Real-time Traffic to/from Cloud Service | No | Maybe (only on sanctioned) |
Yes |
