The Most Critical CASB Use Cases in the Market Today: Enforce Conditional, Activity-level Policies

As we wrap up our quarter and fiscal year this week at Netskope, I’ve been reflecting on our business metrics and how they have changed over the past year. Ninety percent of our customers chose to deploy the Netskope Active Platform as a multi-mode cloud access security broker (CASB). Similarly, nine out of 10 are using our advanced, enterprise cloud DLP. And, on the other side of the spectrum, fewer than 15 percent are using us for Discovery only. It’s clear that the world has moved beyond the find-and-block mentality that was common in CASB 1.0. Enterprise IT is now demanding a different way to address cloud security. They no longer can – nor do they want to – suss out cloud services only to block them, instead opting for safe enablement strategies that address the real risks.

Those real risks we’re talking about aren’t in the cloud services themselves, but rather in how cloud services are being used, i.e., user activities like upload, download, share, edit, delete, and approve, and in what context. For example, there’s nothing bad about sharing in the cloud…unless it’s my company’s nonpublic financial results and it’s two days before my earnings release. Similarly, there’s nothing bad about downloading from the cloud…unless it’s my entire employee base’s personal information, salaries, and latest performance reviews and I’m downloading that information to an unmanaged device. And finally, there’s nothing bad about editing in the cloud…unless I’m unauthorized and I’m modifying a field in a cloud-based financial application that is considered a financial “system of record.” You’ll notice that each of these activities – which is often benign when taken alone – can be risky under a certain set of conditions.

Netskope customers have deployed our all-mode architecture 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 #9: Enforce conditional, activity-level policies.

How can a CASB enable this use case? A CASB sits in between the user and the cloud service provider and monitors usage, enforces policy, and guards against threats. In order to enforce a conditional, activity-level policy, the CASB needs to see all possible traffic and be looking for specific activities plus all of the context surrounding those activities. Those contextual factors include user, group, organizational unit, device type, device OS, device classification and/or status, location, time of day, cloud service or service category, service rating, object name, object type, object size, DLP profile, if applicable, and more. From a deployment architecture standpoint, the CASB must be configured inline. If the enterprise wants to enforce conditional, activity-level policies for any unsanctioned services or across a category of services (as well as for users accessing via mobile or sync client), then it must be configured as a forward proxy (with a thin agent or mobile profile for remote or mobile employees). If the enterprise wants to enforce conditional, activity-level policies for a sanctioned service, and is willing to enforce policy only on browser traffic (versus all traffic, including mobile and sync client), then it can be configured in reverse proxy mode. Here are seven critical functional requirements that are needed to achieve this use case:

• Be aware of activities such as “share” in cloud services, and be able to detect them across a range of services
• See and control usage in both sanctioned and unsanctioned services
• Differentiate between internal and external domains (to ascertain if content is being shared outside of the organization)
• Enforce “set-it-once” policies across categories of services (if IT wants to set the activity-level policy across a category, e.g., no uploading protected health information (PHI) to any Collaboration service)
• Detect and enforce policies by IP address, network location, or geo location (if location is one of the conditions in the policy)
• Integrate with enterprise directory to enforce policies at a group or organization unit level
• Decrypt SSL and decode the unpublished API to understand the transaction (for forward proxy)

How are you enforcing conditional, activity-level policies in cloud services? 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.