A better approach to cloud encryption

Many cloud encryption solutions weaken security to preserve functionality; it doesn't have to be like that

The widespread adoption of public cloud applications like Office 365 in the enterprise has not come without security and compliance concerns. Most cloud apps function like a black box, providing little visibility or control over the handling of sensitive data. This is a boon for IT because it takes the headaches out of operationalizing business applications, but it’s a bane for security teams that require more detailed control and visibility to get their jobs done. When cloud applications leave security gaps that the enterprise simply can’t live with, thoughts often turn to cloud encryption options.

Is cloud encryption right for your organization? With the promise to make your data unreadable by anyone but you, cloud encryption might sound as good as a free, all-expenses-paid trip to Las Vegas for the weekend. Nobody says no to free Vegas until they find out they have to sit through hours of timeshare presentations when they get there. Similarly, it’s important to remember that cloud encryption isn’t without overhead, and it’s not for everyone.

For most organizations, the main drivers for cloud encryption are intellectual property and trade secrets, along with regulated data like personally identifiable information, protected health information, and credit card data. For others, data residency concerns or policies that require control of encryption keys lead them down the path of cloud encryption.

This data may exist as structured data in an app like Salesforce or ServiceNow, or as unstructured data in file sharing apps like Box or OneDrive. In either case, a cloud access security broker (CASB) provides a way to encrypt the data using keys that you control. A CASB also provides a central point for monitoring and managing access to those resources.

Encrypting cloud data at rest with CASBs

CASBs provide a central point of visibility and control across any cloud app used in an enterprise. Control comes in various forms, including contextual access control, data leakage prevention, and of course encryption for data at rest. A CASB works by mediating connections between cloud apps and the outside world, typically via a combination of proxies and API connectors to applications.

bitglass casb architecture

A CASB, or cloud access security broker, mediates the connections between end users and cloud applications, providing a central point of visibility, access control, and data security.

CASBs have become the de facto answer to encryption for cloud data at rest. Unfortunately, early attempts by CASBs to encrypt data ended up weakening security in order to preserve application functions. After all, if data is encrypted, the application can't read the data and therefore can't do anything with the data. Search is the most commonly cited function that typically breaks when data is encrypted.

For example, let's say I encrypt the first name, Pravin, before storing it in a cloud application. I later go to the application and search for “Pravin.” This search will fail because the cloud app doesn't know about “Pravin.” It only has access to the ciphertext that was stored in place of Pravin.

Early CASBs solved the search problem by limiting the strength of the cryptographic algorithm. As a result, early CASB adopters bought watered-down 256-bit AES encryption.

How exactly was the encryption watered down? An encryption algorithm has two main components. The cipher is the most recognizable aspect -- this is the piece that transforms human-readable text into unreadable ciphertext. AES-256 is a commonly used cipher.

The second piece is called the initialization vector or “salt.” This component ensures randomness of the resulting ciphertext. That is, encrypting the same message repeatedly will yield different ciphertexts each time. To ensure sufficient randomness, the length of the initialization vector should be the same number of bits as the cipher.

In order to make data searchable when encrypted and stored in the cloud, early CASBs cut down on the number of initialization vectors used in their products. This limits the number of possible encrypted versions of a given string, allowing the CASB to search across the full space of possible ciphertexts and return accurate search results. Unfortunately, this same approach makes the encrypted data subject to attacks, such as a chosen plaintext attack. The result is that AES-256 encryption may only have an effective strength of 20 bits or less. Why bother encrypting if you use weak schemes that can easily be cracked?

Full-strength cloud encryption with Bitglass

Bitglass takes a “split index” approach to searching cloud-based content that allows you to have your cake and eat it too -- that is, full-strength crypto and search. In a nutshell, Bitglass brings the trusted security of a private cloud to powerful and flexible public cloud applications, allowing you to safely take advantage of apps like Office 365, Salesforce, Box, and ServiceNow.

bitglass proxy versus direct

Unless a user accesses the cloud application through the Bitglass service, he or she will see nothing but meaningless ciphertext. 

When first deployed, Bitglass uses API connections to crawl your cloud applications, identifying sensitive data and allowing you to decide what to encrypt. With a few quick clicks, Bitglass will replace all of that sensitive data inside of the application with copies of the data that has been encrypted using keys that you control, and using the encryption algorithms of your choosing -- which means your existing key management system works out of the box. The encrypted data can be stored in the cloud app or on the customer’s premises. In the latter case, the only thing stored in the cloud application is an encrypted pointer to where the data lies in the local data store.

The split-index approach preserves search by moving the search functionality from the app to the Bitglass service. As data is encrypted, a local search index is generated in the customer premises, with pointers to the encrypted data associated with the relevant keywords in the index. When a user searches for data, the search query is executed against this local index, returning all of the associated pointers to Bitglass. Bitglass then searches the application for those pointers and retrieves the encrypted files or records, decrypting the data for the user on the fly.

From there, sensitive data is divulged on a need-to-know basis. Because it’s encrypted in the app, it’s not readable by prying eyes -- such as the rogue cloud vendor employee or the occasional over-reaching government entity. Even within your organization, access is provided by policy. If you don’t want that customer service representative accessing credit card data after hours, from his or her PC at home, you can control that.

In fact, there is no way for data to be viewed when accessing the app directly. If the user isn’t accessing the application securely through the Bitglass service, they will see nothing but meaningless encrypted pointers (references) to data stored securely on customer premises.

Many enterprises forgo the power and flexibility of public cloud applications for the sake of data security and compliance. With Bitglass’s split-index approach to cloud encryption, these businesses can have both -- without undermining the strength of the encryption or sacrificing the functionality of the applications. It’s an approach to cloud encryption that should make a cloud-first strategy more attainable for the most security-conscious of organizations.

Anurag Kahol is co-founder and CTO of Bitglass, where he is responsible for technology direction and architecture. Previously, Kahol was director of engineering in Juniper Networks’ Security Business Unit.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.

Copyright © 2015 IDG Communications, Inc.

How to choose a low-code development platform