In our most recent Netskope Cloud Report, we reported that, for every sanctioned cloud storage service that an organization has, at least half of the users have a personal instance of the same service. For popular services like Box, Dropbox, and Google Drive, it’s even higher. As organizations get more advanced in their use of the cloud and IT gets savvier about the risks, the ability to tell different instances of popular cloud services apart in their monitoring as well as differentiate them in policy has become a critical requirement. Enterprise IT is increasingly turning to its cloud access security broker (CASB) to assist with this issue.
Netskope customers have deployed our all-mode architecture to differentiate and enforce different policies in different instances of the same cloud service, as well as other 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 each one in this blog. We want to hear from you too!
Here’s use case #15: Enforce different policies for personal and corporate instances of the same cloud service.
Here’s a use case we see frequently: A hospital has sensitive data types it allows in certain cloud services, for example, electronic protected health information in Box. However, it only allows ePHI in its corporate instance of Box, not in the thousands of personal instances or even partners’ instances that users may access to collaborate across organizations. The enterprise needs to enforce a policy that says, “Allow upload of ePHI to ‘corp instance’ of Box, but disallow upload of ePHI to any other instance of Box.” That’s a simplified version, of course. There are many nuances to this policy, including slicing by service instance (corporate, marketing, research, and all other), data type (ePHI, PII, PCI, confidential and proprietary, sensitive, etc.), user group (directors and above, healthcare professionals, full-time, etc.), network location, geo-location, time of day, policy enforcement action (upload and encrypt, coach, require justification, block, etc.), and by many other factors. We see different variations of this policy every day.
How can a CASB enable this use case? A CASB sits in between the user and the cloud service provider and monitors usage, secures data, and guards against threats. In the case of differentiating between cloud service instances for the purpose of monitoring and policy enforcement, a CASB must be able to first pick up all traffic that could potentially be to an unsanctioned instance of a sanctioned service, whether that instance is accessed from on-premises, remotely, from a mobile device, and even from a laptop’s sync client.
This use case can only be achieved with the CASB deployed as a forward proxy, and to have comprehensive coverage for all traffic, including remote and mobile, the CASB needs to include thin agents for remote laptops or mobile profiles for smartphones and tablets.
Beyond deployment choices, here are five critical functional requirements that are needed to achieve this use case:
- Detect sensitive data (if DLP is part of the use case – it usually is)
- Be aware of context, e.g., activities such as “upload”
- Know corporate vs. personal accounts
- Recognize and enforce different policies between service instances, e.g., corporate and personal
- See and control usage in both sanctioned and unsanctioned services
- Decrypt SSL and decode the unpublished API to understand the transaction (for forward proxy)
How are you enforcing different policies across corporate and personal instances of the same cloud service? We want to hear from you.
Learn more about this and 14 additional most impactful use cases by downloading The 15 Critical CASB Use Cases.
