If you use an on-premises data loss prevention solution such as Symantec DLP, RSA DLP, or McAfee DLP, you’ve likely made significant investments in creating policies and remediation workflows in these applications. However, as cloud services become one of the primary ways information is stored and exchanged within the enterprise, there’s a need to extend DLP policy enforcement to the cloud. Existing DLP solutions offer limited capabilities when it comes to cloud services. A cloud access security broker (CASB) functions as a control point for data in the cloud, enforcing a wide range of security and compliance policies including DLP policies. While a CASB does not require the use of an enterprise DLP solution, they work well together.
CASB solutions generally offer their own DLP policy engine, allowing you to configure DLP policies in a CASB and apply them to cloud services. If you already have an on-premises DLP solution, a CASB can integrate with your existing solution to leverage policies configured in the on-premises DLP solution and enforce them across cloud services. In this case, DLP violations can be viewed within the on-premises DLP solution and the CASB can take remediation action within the cloud service and register the action in the system where the policy is managed. Before diving in to how a CASB and DLP solution integration together, it may first be useful to understand the DLP capabilities of a CASB that are not available in on-premises DLP solutions:
- CASBs maintain a data model for each cloud service. This allows support for cloud services without standard content disposition headers (more on that below).
- A CASB can be deployed in an inline proxy mode to natively enforce DLP policies inline for all cloud services. This enables a CASB to stop uploads of data to the cloud.
- Integration with web proxies, in combination with a CASB’s data model for each cloud service, enable the enforcement of DLP policies using existing network infrastructure.
- CASBs integrate with a broader set of cloud services via API to scan existing data at rest as well as new events (e.g. upload of a file, sharing of a file).
- A CASB can enforce tiered remediation actions in cloud services including quarantine, tombstoning, selective encryption, etc. based on the severity of the violation.
Cloud support from DLP solutions today
DLP solutions offer minimal support for cloud services today. There are several ways an on-premises DLP solution can support cloud services. First, a DLP solution can consume a feed of network traffic via a SPAN port or TAP and evaluate the content for DLP violations. When a cloud service uses standard content disposition headers, this approach enables violations to be identified in cloud traffic over the network (although no action can be taken). Organizations that have a web proxy (secure web gateway) can integrate their DLP solution via ICAP to inspect content for violations and enforce blocking of sensitive content via the web proxy. Again, this solution is limited to cloud services that support standard content disposition headers.
The advantage of using a CASB for the enforcement of cloud DLP is that CASBs are 100% focused on securing cloud services. Many popular cloud services today including Slack, Evernote, and Google Drive do not use standard content disposition headers because their custom headers enable faster performance for their web applications. A CASB maintains a registry of cloud services with detailed and up-to-date signatures for each application. Whether you integrate a CASB with a web proxy to inspect content via ICAP, or deploy a CASB’s forward or reverse proxy, these signatures enable the CASB to understand the traffic to and from a cloud service and enforce DLP policies inline for cloud services that do not use standard headers.
Finally, some DLP solutions offer API connectivity to scan data in cloud services, but their remediation options are limited. For example, in some instances a DLP solution can apply a tag to documents in file sharing services that contain sensitive data. The tag indicates to the end user who owns the file that they are required to perform self-remediation. However, this approach is limited to the user performing remediation. It does not automatically perform a remediation action to remove the violation. In doing so, it does not addresses orphan files (whose owner has left the company) because there is no one to perform remediation. It also relies on end users who may not be vigilant about removing files with sensitive data.
How a CASB integrates with a DLP solution
CASBs integrate with on-premises DLP solutions via ICAP, which is a standard protocol for sending content to a DLP solution for inspection. The most popular deployment path for a CASB is a cloud deployment. To integrate with an on-premises DLP solution, the CASB uses a piece of software on premises that serves as a connector. The CASB can enforce DLP policies against existing data in a cloud service and new files as they are uploaded. When a CASB is connected to a cloud service via API, the CASB’s cloud platform scans it for document metadata and passes a list of documents to the CASB’s on-premises connector requiring deeper inspection.
The connector downloads files directly and passes them to the DLP solution for content inspection. The DLP solution inspects files against its existing DLP policies. When the DLP solution identifies a violation, it sends the violation to the CASB cloud platform via the connector. The CASB cloud platform enforces remediation action with the cloud service via API. For example, a CASB can take a quarantine action for a file containing sensitive data, quarantining the file in place in the cloud service so the end user can no longer access it. Once the file is quarantined, the CASB cloud platform notifies the on-premises DLP solution via the connector so that remediation action is registered in the solution for closed loop reporting.