<img src="//pixel.quantserve.com/pixel/p-_JKXxuL8SR7wu.gif?labels=_fp.event.Default" style="display: none;" border="0" height="1" width="1" alt="Quantcast">
blog-banner.jpg

Next-Gen CASB Blog

Integrating a CASB with Premises DLP

By Rich Campagna | August 31, 2016 at 7:27 AM

cloud_dlp.jpgMany enterprises, especially those in regulated industries like Financial Services or Healthcare, have made major investments in Data Leakage Prevention (DLP) systems over time. These products, deployed across company managed endpoints, strategic network locations, or both, often serve as systems of record for compliance and data leakage events, company-wide. As organizations make the shift to cloud applications, network and endpoint DLP solutions are unable to protect against data leakage, and cloud access security brokers (CASBs) have quickly become the primary cloud DLP enforcement point.

Given large investments and internal inertia, a lot of enterprises decide to integrate their CASB and their premises DLP system. To do this, there are three integration possibilities that we see organizations consider most often:

  1. Forward traffic from the CASB to the DLP system for enforcement - in this method, the premises DLP system is doing policy enforcement for all events. The CASB optionally does some pre-screening for sensitive or regulated data, and then forwards some or all to the premises, usually via the ICAP protocol. The DLP system runs through its policy check and then returns a result to the CASB, which then takes the appropriate action (such as block a share or prohibit a download). 
    Pros: All of the policy objects have already been built on the DLP system, and personnel are already trained in its use, so the initial deployment can be faster, and with less learning curve. 
    Cons:
     Performance! Unlike premises-based security products that incur low latency LAN hops, the thought of "chaining" security products as you move to the cloud means WAN hops for an integration like this - a performance nightmare. 
  2. Build policies entirely on the CASB - in this model, the enterprise decides to start from scratch and build all policies entirely on the CASB, with no direct connection to the premises-based DLP system. The organization might optionally send data to the premises DLP system (via the same ICAP protocol) in order to maintain a single point of visibility on premises, even though all enforcement is done in the CASB. 
    Pros: No additional WAN hops or latency - a properly architected CASB is globally deployed in the cloud and, even with data processing latency, can actually achieve faster performance versus users connecting directly to cloud applications. 
    Cons: Policies and policy objects have to be completely rewritten in the CASBs DLP language, which might be similar or different from that of the premises-based system. From there, tuning of policies and retraining of IT, security and compliance staff adds to the onboarding tasks.

  3. Sync policies from the DLP to the CASB and enforce on the CASB - the goal here is to solve for the challenges with each of the aforementioned models. In this case, policies and objects are exported from the premises DLP system to the CASB, but with all enforcement done directly on the CASB itself. 
    Pros: Takes the best of both worlds - the performance of enforcing policies directly on the CASB, with the fast time-to-deploy of leveraging the premises DLP system. 
    Cons: None that I can think of. 

What we see across our customer base is that most organizations start with the first approach as their preference, but through trials or proof-of-concept deployments, decide that the third approach is the best way to go to production. Regardless of the approach that you decide to take, a CASB like Bitglass can help make your plans a reality. Why not check out a demo? 

15 minute live demo