As cloud computing platforms rapidly evolve, Information Security executives are finding it difficult to choose the right CASB technology that ensures Cloud DLP requirements are met.
In this blog post, I will address the key dimensions of Cloud DLP and show what use cases are critical in order to come as close as possible to complete coverage from a data protection perspective. I will also address common issues such as Bring Your Own Device (BYOD) as well as off-network access to both sanctioned and unsanctioned services.
DLP in the Cloud
A Brief Lesson on the history of DLP
DLP Technology has been around for some time now, but with the rapid expansion of cloud computing, requirements are changing. The original on-premise DLP products are heavily focused on endpoint protection. The goal is to prevent documents from a user’s managed device from being shared through such channels as a USB device connected to the machine, or via the corporate email system. On-premise DLP tools provide rich capabilities for analyzing document contents and searching for specific data necessary to flag the document as restricted – for example, by looking for personally identifiable information (PII) or data that could be in regulatory violation, such as HIPAA information. Based on this analysis, the tools are able to restrict inappropriate sharing on traditional vectors.
The Cloud
The rise of Cloud as a platform has created gaps that traditional on-premise DLP is unable to fill. Users might now create their documents in the cloud, on a platform such as Office365, and share them inappropriately with tools such as Box or iCloud. Users are also much more likely to work from home or work on unmanaged devices that do not have an endpoint protection agent. Cloud Access Security Brokers (CASB) have evolved in part to fill this gap.
The Scope of Cloud Coverage
This section will focus on the various dimensions of coverage that need to be addressed. I will then look at CASB DLP features, and how they can be used in concert to meet this set of requirements.
1. User Location
This encompasses the following distinct dimensions:
Network connectivity: is the user connected to the corporate network, or not? (Note that this also includes VPN connected users)
Physical location: a user might be working in their usual office, at home, or at some other remote location. Note that the user’s physical location could potentially have a regulatory impact, based on data protection jurisdiction (e.g. a US-based user working on a mobile device while traveling in Europe)
2. Device Protection
The user could be working on a corporate-owned device that is managed and locked down, or on a personal device that is unmanaged.
3. Sanctioned or Unsanctioned Application
The user could be working with a sanctioned cloud application that they need to log into using corporate credentials, such as Salesforce or Amazon Web Services (AWS). Alternatively, they could be sharing a document on an untrusted cloud service such as Photobucket or Baidu SkyDrive.
4. Corporate vs Personal instances
Even if a user is working with a sanctioned application, such as Box, they could also have an individual account with the same service. The DLP requirements may be different between these two cases. In addition, as we will see, the CASB capabilities for monitoring one or the other may also be different.
CASB DLP Options
CASBs provide (up to) three distinct operational models for applying DLP content aware policies to cloud traffic. When selecting a CASB, it’s important to understand these models, and which requirements they address. It’s also important to look at the details of how they are can be implemented to ensure that they fit into your existing network and security architecture.
1. API Integration
Most CASB’s provide the ability to set up API connectors to some number of applications, typically widely used enterprise level applications like Office365, Salesforce or Box. A trusted connection is created between the CASB and the target application (typically using OAuth) and the CASB is able to monitor the data stored in the application, looking for policy violations. Depending on the capabilities of the API, this may be quasi-real-time (using Webhook based callbacks) or periodic (using polling).
This model covers:
Sanctioned applications only (there has to be a corporate account)
Corporate instances only
User activity from any location (it’s not inline, so no network restrictions)
Activity from any device, managed or unmanaged
However, note that the model is reactive – there is no way to prevent the activity from happening, but the violation will be reported, and usually quite quickly.
2. Reverse Proxy
Another feature of many (but not all) CASB’s is the Reverse Proxy. As with API, this only applies to a small number of well-known applications that are specifically configured in the tool. It also requires that the application is accessed using the customer’s SAML-based single signon capability, as it is implemented by inserted the CASB into the SAML flow as a proxy. The CASB is configured to look like a Service Provider to the SAML Identity Provider (ADFS, Okta, Ping etc.) and to look like an IdP to the Service Provider (SaaS application).
This model covers:
Sanctioned applications only (there has to be a corporate account)
Corporate instances only
User activity from any location (does not rely on any network level forwarding)
Activity from any device, managed or unmanaged
As you can see, the scope of coverage is similar to the API model. The difference is that this is real-time coverage, in line with the user’s interactions with the tool, so now the DLP can be more proactive, and can actually prevent restricted activities from taking place.
3. Forward Proxy
The final model is the forward proxy, which should be noted is the only model that covers activity in non-sanctioned applications. In this scenario, traffic that is being sent from the user’s device to a cloud application is first routed in some way to the CASB. There are several possible ways in which this routing can happen:
An agent or mobile profile might be installed on the device, and used to control the traffic routing to the CASB
For on-premise or VPN connected traffic, network level routing might be used to direct appropriate traffic. This might be implemented in a variety of ways, including PAC file, DNS, and Proxy Chaining from the existing Web Proxy.
The capabilities are slightly different between the agent and agentless models, so we will address them separately.
For the agentless model, it covers:
Sanctioned and unsanctioned applications
Corporate or Individual instances
User activity from devices that are connected to the corporate network only
Activity from any device, managed or unmanaged
For the agent/mobile profile model, it covers:
Sanctioned and unsanctioned applications
Corporate or Individual instances
User activity from devices in any location, on any network
Activity from managed devices only.
Forward proxy covers most use cases, other than the access to sanctioned applications from an unmanaged device that is not connected to the network. For sanctioned applications, this gap can be filled by either the API or Reverse Proxy model. But note that for complete coverage of all unsanctioned traffic from any location, you would probably need a combination of both the agent and the network routed (agentless) solutions.
There are good reasons to implement both. For example, even when using the agent, there may be older devices on the network that are not able to install it (e.g. older versions of Windows still in use in some departments.)
4. Gaps
If you were looking carefully, you might have noticed that there is still a gap that CASB does not cover. This is the use case where the user is accessing an unsanctioned application from an unmanaged device that is not connected to the corporate network. But in this case, we need to ask the question, how did the offending document get onto that device in the first place? If it was sent via email, or the user attached the device as a USB, then we are back in the realm of traditional on-premise DLP. This is not replaced by CASB, the two work together to provide more complete coverage.
CASB Selection
As you can see from this article, there are a lot of factors involved in choosing the right CASB in order to have the most comprehensive Cloud DLP coverage. Here are some of the key items to consider:
Does the CASB support all three of the major operational models for DLP policy enforcement (Reverse Proxy, Forward Proxy, and API)?
For Reverse Proxy and API, does it support the applications that you care about most?
Does it support both agent and agentless models for Forward Proxy?
Does it support network routing options that work inside your network infrastructure?
Does it provide the ability to offload DLP decision making to your existing on-premise DLP engine, or does it support compatible DLP policy rules?
Can it distinguish between corporate and private instances of the same application?
Does it work with the set of devices that you use in your enterprise?
I hope this article will help you choose wisely when selecting a CASB, and if you have any additional questions, feel free to reach out to me at paul.ilechko@cedrus.digital
Interested in CASB but unsure where to start? Download The Road to CASB: 2019 Business Requirements Whitepaper.
The goal of this paper is to provide a kickstart through a working set of requirements for you to leverage, and modify as needed in your search for a CASB solution. This set of requirements provides some structure on how CASBs can fit in your organization’s overall Information Security strategy.