The Most Critical CASB Use Cases in the Market Today: Apply Encryption Based on Conditional Factors
There are three massive trends that are on a collision course: Enterprises’ migration of business-critical systems to the cloud, introduction of new (or sharpening of existing) legislation protecting users’ personal information, and hackers’ targeting of the cloud for propagating malware, executing hacks, and perpetrating hold-ups.
To protect their most valuable assets, enterprise IT is increasingly turning to cloud access security brokers (CASB) to help them protect regulated data, valuable intellectual property, and confidential business information in cloud services. To be effective, a comprehensive cloud data protection strategy should include strong encryption. But for that encryption to be effective, it needs to be applied thoughtfully not to all data, but rather the most sensitive data and in consideration of performance and usability tradeoffs. Additionally, strong encryption should be applied in an enterprise way, with key management choices that include integration with an organization’s on-premises key manager and at least FIPS 140-2-certified HSM.
Netskope customers protect sensitive data in the cloud by using their CASB to encrypt sensitive data using a strong cipher such as AES 256, and do so selectively based on conditional factors such as who, what, when, and where of the cloud transaction, as well as by integrating with their existing key manager. They have deployed our all-mode architecture to enable this critical use case. 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 #14: Apply encryption based on conditional factors.
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 applying strong encryption in context, the CASB must be able to discern contextual information about the transaction. For example, it should know who’s transacting, what group they’re in, where they are located physically, what activity they’re performing in what service and to what data, and whether that data is sensitive. For example, a user in HR uploading a cat video isn’t the same as an ‘insider’ uploading a PowerPoint document entitled ‘Acquisition Priorities’ that triggers a ‘confidential data’ DLP violation.
This use case can be achieved with the CASB deployed as a forward proxy, reverse proxy, and – in a limited way – using the cloud service’s API. To apply this policy to all traffic, including that emanating from sync clients and native and mobile apps, even in unsanctioned cloud services, your CASB needs to be deployed as a forward proxy (and if remote, with a thin agent or mobile profiles). For browser-based traffic to sanctioned services only and mobile traffic limited to a limited set (like Salesforce1), you can handle this use case with a reverse proxy. Finally, if you don’t mind the encryption not happening inline, but after upload, you can use the API deployment.
Beyond deployment choices, here are five critical functional requirements that are needed to achieve this use case:
- Be aware of context, e.g., activities such as “upload”
- See and control usage in both sanctioned and unsanctioned services
- Apply strong encryption to sensitive content with key management
- Integrate with KMIP-compliant, on-premises key manager
- Decrypt SSL and decode the unpublished API to understand the transaction (for forward proxy)
How are you applying strong encryption based on conditional factors 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.
