Cloud Security

Conquering CASB Confusion

By Adrian Sanabria

7 examples that demonstrate where CASBs excel... or not

Q: Remind me, what's a CASB again?

A: CASB, or Cloud Access Security Broker, is an enterprise security market devoted to filling the security control gap for cloud-based IT services. The most well known examples include:

  • Software-as-a-Service, or SaaS (think Salesforce, Google Drive, Office 365)
  • Platform-as-a-Service, or PaaS (think MongoHQ, Heroku,
  • Infrastructure-as-a-Service, or IaaS (Amazon AWS, Microsoft Azure, Google Cloud Platform)

The tradeoff of any 'as-a-service' offering is typically convenience, simplicity and lower capital expense in exchange for potentially greater operational expense along with reduced visibility and control. The latter is what led to interests in building CASB services, which are typically as-a-service offerings in their own right.

When Acme Widget Services (a fictional example, any acronym similarities are entirely coincidental) lacks a particular security control, a CASB can provide a substitute for that control by sitting in-line with the service or interfacing with it through an API. Other common tenets of a CASB is the ability to discover which services are being used without IT's formal knowledge (Shadow IT) and can normalize policies across many platforms and services, allowing for a single policy to apply to payroll, CRM and file share services simultaneously, for example.

CASB Today

NewProductCASB was widely regarded as the quickest-growing market ever in cybersecurity. It seemingly exploded out of nowhere in 2014 and 2015. Part of that accelerated growth means that it has already arrived at the consolidation and unavoidable 'cooling' phases any new market goes through. The security market is a lot like a relationship in that way — hot and heavy when a new market emerges; lots of excitement over something new. Then, as heads cool, we all start to think: but where does this fit in the larger picture? Should I be buying it as a standalone product, or wait for the inevitable acquisitions to occur so I can get it as part of a larger package/platform?

One of the key markers of this stage that we look for is when a majority of the acquirable market has been consolidated into larger vendors that can't be considered pure play in the same market. One of the interesting things that often occurs is that the market extends into other areas, which has happened here as well. While CASB vendors started off targeting business and backoffice-focused SaaS, many vendors have now extended to addressing security for public cloud infrastructure management. In other words, IT administrator use of Amazon AWS, Microsoft Azure, and other API-enabled public cloud offerings. Palerra (acquired by Oracle) was the first notable CASB vendor to go this route and draw attention to the opportunity.

Currently, buyers can purchase CASB from a pure play vendor, like SkyHigh, Netskope, Managed Methods, or BitGlass, or as part of a suite from a large vendor like Symantec, Microsoft, or Cisco. A lot of the purchase decision comes down to use cases and priorities. What is it you actually need a CASB to do?

3 no-brainer CASB examples you should be using right now

Awareness and Control

This is probably the most recognizable use case, and is a large part of why CASB exists in the first place — a distinct lack of visibility and loss of control in the cloud. Shortly after corporate employees started adopting SaaS at a rapidfire pace, a variety of questions started popping up. Most organizations knew SaaS use was occurring — most next-gen firewalls can tell you that much — but what were users doing in these applications? Personal tasks? Work tasks? Both?

Furthermore, this is a general use case that builds on itself, starting with application discovery. The reward for working through these layers is the ability to put rules and alerts in place that are more likely to prevent risk and will be easier to manage. Advanced anomaly and behavioral detection is attractive, but difficult without building the base detailed below.

  1. Discovery (aka Shadow IT Discovery): What SaaS apps are in use? Which are the most popular? Which are transferring the most data? Which are in use by the most people? Which are the least common?
  2. Usage Analysis: What are employees doing with/in these applications?
  3. Data Analysis: What kind of data is getting stored in it? Corporate data? Personal? Both?
  4. Context: Are they only logging into it and using it from work and work-owned systems, or also from personal systems at home?
  5. Behavioral/Anomaly Detection: What if an employee uses a SaaS application to steal corporate secrets? How would we know? Are they using a new device for the first time? Sending more data than usual? Sending a lot of emails to their personal account with attachments?

The initial reaction to Shadow IT was to shut down all unauthorized use. Next-gen firewalls made it a simple task to disable services like Evernote or Dropbox without having to create rules tied to the specific IP addresses behind a service, which could (and do) regularly change. The problem was, a lot of these services increased productivity dramatically, so IT and security staff were pressured to find a way to allow it. Something more nuanced than a binary allow/block decision was needed.

CASB emerged in response to this need, giving organizations much deeper visibility into cloud and SaaS use — down to individual file names, sizes, and content. Visibility into usage patterns and anomalies. Most importantly (but possibly least used?) — control over individual SaaS features and actions. Need to give the helpdesk an admin role so that they can modify user accounts, but don't want them to be able to modify billing? The SaaS vendor may not have separated these roles, but CASB can. Maybe your organization likes Yammer, but is using a different product for IM? Simply block Yammer's IM functionality and insert a reminder to use the company standard instead.

Discovery, awareness, and control provide the foundation that most other CASB use cases are built upon.


Data Loss Prevention (DLP) is a critical component to any CASB offering. Without the ability to monitor, identify, and categorize data going into the cloud, we wouldn't be able to determine the risk of that data being transferred. In other words, we need to know if a document being uploaded contains cat pictures or private employee data, like social security numbers and salary information. Addressing the problem as if all data is sensitive (one extreme) or as if all data is harmless cat pictures (the other extreme) guarantees failure. Tracking and protecting data, however, is tricky. Most data can't travel with protection or security policy without seriously hampering usability.

Encrypting data might seem like a plausible panacea until it is tested. Workflows become significantly more difficult. Productivity falters. Employees find shortcuts around security controls that get in the way of getting work done. Still, there are cases where encryption is essential, or a no-brainer. Unfortunately, it isn't the panacea we want and need it to be.

Ever been asked to download and install an application, just so that you can read an email or document you've been sent? What if each of your business partners used a different security solution to do this? It isn't uncommon for auditors and consultants to have half a dozen applications installed and a dozen more accounts, just to be able to send and receive data securely with different clients.

These days, DLP isn't just about pattern matching sensitive data types either. Criminals still steal easily-recognizable financial data and PII, but they also understand the value of email, source code, and other intellectual property. In some cases, it might be normal for an employee to access a dozen customer records, but not a hundred.

Conclusion: DLP is a constant struggle against a tide of alerts and false positives, which isn't unique to doing DLP with CASB. While any successful DLP program should extend to SaaS and the cloud, be weary of simply adding more haystack to needles that are already deeply buried.

Compliance and Regulation

Among organizations in finance, healthcare, and other highly-regulated verticals, compliance is a common use case for CASB. In this specific context, CASB is what we call a 'missing feature market." It exists to fill the gaps in SaaS products that prevent wider adoption. Gaps that prevent organizations from using the application because some missing feature or capability represents a regulatory deal-breaker.

When talking missing features, Proofpoint's CASB offering leaps to mind. A company better known for email security offerings, Proofpoint acquired a CASB vendor called FireLayers in 2016. What's interesting about FireLayers is that this company introduced the ability to add features or functionality to someone else's SaaS application. This could be very advantageous for a regulated organization required to restrict certain roles or functions within an application that lacks the necessary access controls.

The classic example of adding functionality is a situation where a company wants to require step-up authentication whenever a critical function is performed. For example, an employee's salary can be changed in a SaaS payroll application like Paychex or Paylocity. Another use case is simply applying compliance policies to specific users, files, or customers that those policies have been designed for (PCI, HIPAA, internal policy, OCC, etc). One of the key attractions of a CASB is the ability to build a policy once and apply it across multiple applications.

For example, say the policy details "users may view, but not download data on non-corporate devices." Applied to Office 365, this policy would allow users to view emails and their attachments in "online-mode," but not to download either to the device. This same policy should function the same way in Dropbox — files can be viewed and browsed through the web interface, but attempts to download to local storage get blocked.

2 use cases to be weary of

The GeoIP Paradox

This is a favorite example to show in customer demos. It seems like a sure-fire way to identify stolen credentials: someone logging in from China within five minutes of the legitimate employee logging in from Austin, Texas. Clearly, the employee can't travel thousands of miles in five minutes...

Problem #1: VPNs are all the rage now — everyone is recommending using VPNs to avoid threats associated with public Wi-Fi, government spying, and a host of other scenarios. That means it could be normal for an employee to log in from the corporate network, drive to a coffeeshop, connect a VPN to a point in, say Canada, and reauthenticate. Only 30 minutes have transpired, but the distance between the two points might be thousands of miles.

Problem #2: Third-party logins have also become commonplace. It might be normal to see logins coming from Virginia and Texas simultaneously. One is the employee logging in, and the other is a third party logging in to enable some automation or integration via another SaaS. Say, Expensify and Intuit's Quickbooks Online, for example.

Conclusion: GeoIP Paradox rules may still have value, but take them with a grain of salt. Resolving forward DNS (not reverse) can help determine if it's a false positive or a legitimate concern.


The anti-malware case is an interesting one. While it might seem a natural choice for cloud services that handle files, like Office 365 or Dropbox, we've heard from many CASB vendors that malware in the cloud is rare. When we consider that most cloud services that handle files already scan for malware, this result isn't terribly surprising.

Some vendors integrate with simple services like Virustotal, that just return a score upon receiving a hash. Others will check files against malware sandboxing vendors, and will submit any files that haven't already been analyzed to a sandbox for detonation. It's worth a word of caution that sensitive data and files could be sent off to a third-party sandbox if this service is in use.

In conclusion, this seems like a solution in search of a problem — there are better malware prevention strategies out there.

2 interesting future use cases

These two cases are ones that we haven't yet seen in the market, but think would be useful to defenders.

EvilAP Detection

Early on, the security industry approached mobile security as if these devices were just more endpoints. As it turns out, Android and iOS were designed from the start to be resilient against malware and local attacks. Some of the more practical attacks against these devices actually come from outside the device — upstream on the network. In fact, we're starting to see more and more services and phones that have integrated abilities to detect untrustworthy wireless networks.

Thing is, there are ways to detect attacks upstream on a network. ARP route poisoning, fake cell towers, and man-in-the-middle (MITM) attacks all have telltale signs. Skycure is one company that specialized in detecting these sorts of threats, using mobile apps as sensors and crowdsourcing the detection of these malicious networks. Once detected, it's a simple matter to integrate the data with a CASB provider.

Symantec (Blue Coat, specifically) invested more in the CASB market than any other vendor, acquiring both Perspecsys and Elastica in 2015. They recently acquired Skycure, so there's a chance this use case could be offered by Symantec soon.

From Discovery to OSINT: Taking the blinders off

Discovery is often the first step an enterprise takes into the land of CASB, though it has little to do with CASB technology or services. Technically and architecturally, the discovery process is often completely separate from everything else CASB related. While CASB most commonly use proxies and APIs to hook into SaaS activity, the discovery process often uses firewall logs, proxy logs, or DNS cache to create a list of sites and apps used by employees.

The downside of this approach is that visibility is restricted to a corporate-owned, on-premise perspective, which is very limiting at a time when it's not uncommon for some employees to be 100% remote. Or perhaps an organization has many small branch offices, and it's not feasible to feed logs from these devices to the CASB discovery mechanism. How to extend discovery capabilities to offsite devices and employees, then?

There are a few approaches already in use. An agent or forward proxy can achieve this goal, and what's more, they can be used to both discover and control SaaS activities. However, some organizations are already agent-laden and would prefer not to add another. Others are adverse to forward proxies or third-party VPNs due to performance or privacy issues. Furthermore, there's the issue of employees working with company data on systems that are not corporate owned or managed.

The next logical step may be to merge some OSINT techniques and processes with CASB, and correlate the findings with existing data. There are even a handful of data loss detection vendors that can match proprietary data with data found on the open Internet or the less open dark and deep webs. The idea here is to discover data that misbehaves, showing up in places it shouldn't be.

Wrapping up — the wheel of InfoSec turns on

Ultimately, this is the nature of infosec — new problems emerge and security products are created to address the problems. Some of these products consolidate into suites or platforms, or the problem is addressed at the root and the need for the security product disappears. CASB is now at the latter end of this cycle. Acquisitions by Symantec, Microsoft, Cisco, Proofpoint, and others have consolidated a considerable chunk of the market.

The acquirers will integrate and the remaining pure play vendors must innovate. As both groups mature, it will be interesting to see if a portion of the market remains independent or if CASB becomes just a feature set in a larger "cloud security" suite.


Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.