As enterprise IT gets smarter and more nuanced about cloud security, it now expects to exert controls over cloud services according to a multitude of contextual factors. IT and security professionals are now asking their cloud access security broker (CASB) to enable them to enforce their policies in a way that involves a “base” policy (for everyone) and one or more “exception” policies based on users, groups, devices, device classifications, locations, activities, cloud services, cloud service instances, and a host of other contextual factors. These layered policies can work in tandem to create an else-if logic to control cloud access, activities, and data in a granular manner.
Enforcing layered policies in CASB requires an architecture that is flexible and enables IT not only to see, but also control activity based on the factors that make up a cloud transaction’s context. Netskope customers have deployed our ALL-MODE architecture (with more than three-quarters of them going beyond a single mode) to achieve their most critical use cases. We have noted 15 of these use cases in our recent e-book, The 15 Critical CASB Use Cases, and we’re highlighting them and more (and we want to hear from you too!) in this blog.
Here’s use case #10: Enforce layered policies that include a “base” and “exception” policy.
One of Netskope’s customers is in the entertainment industry. The company develops high-end animation for motion pictures. Nearly all of its artists’ pre-production creations are not only proprietary, but carry serious financial consequences if they are leaked before the final production is released. The company is a big Google shop and, as such, uses Google Drive to store and collaborate on artists’ creations. The organization realized that simply allowing Google Drive and blocking everything else at the perimeter (a tactic employed not only by web gateways and firewalls, but also other CASBs) was not an effective strategy because users could upload – either inadvertently or intentionally – proprietary content to personal versions of Google Drive. Moreover, the organization wanted to allow its users to access and download from other Cloud Storage and Collaboration services without being concerned about data leakage. The organization enforces a policy that identifies its corporate version of Google Drive, and allows content upload to that. That is the “exception” policy. For other versions of Google Drive, as well as other Cloud Storage services, the organization enforces a “no upload” policy while allowing “view,” “edit,” and “download” from those services.
How can a CASB enable this use case? A CASB sits in between the user and the cloud service provider and monitors and enforces activity- and data-level policies based on all of the contextual factors that make up a cloud transaction. It must do this not just in a sanctioned cloud service, but at the service instance level. Moreover, it needs to recognize all other non-corporate versions of that same service and disallow the activity in those. Finally, it needs to take a broad sweep of all cloud services in the broader category and disallow the activity in those. To achieve this use case, the organization needs to deploy the CASB in an inline, forward proxy mode for real-time activity-level monitoring and policy control. Here are seven critical functional requirements that are needed to achieve