InfoSec Musings: Cloud Access Security Broker (CASB)

First of several short articles on the feature sets of a typical Cloud Access Security Broker (CASB)

The Forward Proxy:

In a Cloud Access Security Broker (CASB) A forward proxy is an in-line real time protection gateway service configured to handle network requests for a group of known clients (users and devices) to any external website and/or cloud service. These users and devices can be connecting from anywhere, either on the corporate network, or across the Internet. The destination services are typically cloud based.

The CASB forward proxy is primarily a policy control, and in it's most basic un-authenticated form, would simply apply policy enforcement to allow or deny access to specific sites and services on the internet. This form of the service could be used to police the corporate "Code of Conduct" ie: "No corporate device is allowed to browse Pornography, Violence/Hate, Drugs, Gambling, etc... " or to block access to Cloud Storage sites to reduce risk of Data Loss.

This however, is a very limited use case, and easily subverted.

Typically, you would configure the Forward proxy to authenticate the endpoint (Either User, or Device, or both) to your corporate directory. This can be done through Microsoft's ADFS (Active Directory Federation Service) or better through a Cloud Identity Provider such as Okta, Ping, OneLogin, or Centrify.

For sites that are Corporately Sanctioned, you can manage/report/alert on the context of Who visited the website or service, from where, on what device, and at what time. Any or all of these attributes can be used to modify access. IE: If going to a specific service from an unknown device over public WIFI, you may want to enforce Two Factor Authentication, and restrict file transfer.

For sites and services that are unknown or not Corporately Sanctioned (Shadow IT), you may want to validate the type of service through URL/Content filtering, and then allow access, while logging verbosely.

Scenario: With authenticated forward proxy, you can say:

This user is from accounting - these are the apps they should potentially be able to access.
This user is on a corporate laptop from within the corporate network, allow full access.
This user is on a corporate laptop on a public network. (Starbucks or Hotel)

Enforce two factor auth to these apps, and deny access to these apps.

This user is on a personal device on a public network.

Enforce two factor auth to these apps, and deny access to these apps
Deny file transfer.

etc...

And of course the Cloud Identity Provider would manage credentials on the end service, therefore direct connection would be prohibited.

Typical Forward Proxy use cases:

Inspect content between Endpoint device (user) and Website/Service for Malicious Activity.
Inspect content between Endpoint device (user) and Website/Service for Data Leakage.
Enforce Corporate "Code of Conduct" via URL filtering.
Provide granular access control based on "context" of user's source device/network/time.
Provide list of "un-sanctioned apps" for security review.
Encrypt Field level/table level data on the fly.
Tokenize Field level/table level data on the fly.

As an inline implementation, the forward proxy requires a method to direct/enforce traffic from the endpoint device through the proxy, to the destination service. For legacy on-premise proxy, we had a few options for redirecting traffic to the proxy:

Typically, PAC (Proxy Auto Config) files would be used. This was an intrusive configuration of the endpoint, that could be easily bypassed by the user.
DNS "URL redirect" was also a good choice for redirecting "sanctioned applications" through the proxy to control/monitor that traffic.
Finally, an endpoint agent on the device could be used to control/redirect traffic. (Do not do this! Please!)

Most CASB providers today rely on the Single Sign On Identity Provider (IdP) that authenticated the end user to provide a SAML redirect to the CASB forward proxy service. This also allows the Identity provider to add "context" to the interaction. "Michael is authenticating after standard work hours with his corporate credentials, on a valid certificated corporate device, from what appears to be a home network".

Next up: Cloud Access Security Broker (CASB) - The purpose of a reverse proxy