Credit: ID 114230736 © Setiawanarief111 | Dreamstime.com
Today, most companies have shifted how they operate in order to pursue the many benefits that can be found with public cloud applications. However, this shift has also introduced a number of previously unseen data security and compliance issues. This is because many of the most popular cloud applications provide very little visibility or control over how sensitive data is handled once in the cloud. Regardless, users are simply expected to trust that their data is being kept secure within these apps.
Of course, many IT departments are overjoyed with this approach because it takes a significant amount of stress out of operationalising business applications. However, for security teams, it has the opposite effect. Without visibility and control over data flowing to and stored within cloud apps, it is hard to ensure that corporate information is truly secure. As such, security teams have sought to leverage encryption techniques as a way to shore up protection of data in the cloud.
The primary driver for cloud encryption is the need to ensure that intellectual property, trade secrets, and regulated data (such as customer payment card information) is indecipherable and unusable if stolen in a breach or accessed illegitimately. For others, they are led to cloud encryption by data residency concerns, meaning that they want information to be secured wherever it is physically stored. In apps like Salesforce, this information exists as structured data (fields or columns). In file sharing apps like Box, it is stored as unstructured data (files). In both cases, the most commonly used tool for encryption is a cloud access security broker (CASB).
Encrypting data in the cloud can be tricky
CASBs mediate connections between cloud apps and the outside world via a combination of proxies and API connectors to applications. In doing so, they create a focal point of visibility and control for cloud applications in use, with controls taking the form of data loss prevention, contextual access control and all importantly, encryption of cloud data at rest.
Unfortunately, using a CASB for encryption is not without its challenges. In order to preserve application functionality after data is encrypted, some CASBs actually reduce the strength of the encryption. When data is encrypted, the application is unable to read the encrypted data and therefore loses the ability to do anything with it. The Search function is perhaps the best example of this. If a customer file is encrypted and a sales person attempts to search for it, the application would not be able to read the file and therefore the search function would be broken. Reducing the encryption strength allows a CASB vendor to “crack” its own encryption in order to allow critical functions like search.
These functionality issues can seriously impede the productivity benefits of adopting cloud applications in the first place. And so, some CASBs “solve” the issues by limiting the strength of the cryptographic algorithm used. Of course, in doing so, it severely impairs the overall effectiveness of the encryption, making data much more vulnerable. This has left many businesses with a difficult trade-off between lost functionality or sub-optimal security, neither option being particularly appealing.
Solving the security and functionality trade-off
The latest development in cloud encryption is one that takes a “split index” approach to searching cloud-based data, which gives businesses the best of both worlds. When first deployed, API connections are used to analyse cloud applications in use, identify sensitive data, and let the business decide exactly what it wants to encrypt. The CASB will then replace all sensitive data with copies that have been encrypted. The business retains control over the encryption keys in this scenario. The encrypted data can then be stored in the cloud app or on 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 CASB. As data is encrypted, an encrypted local search index is generated on 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 the CASB. It 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 the business, access is provided by policy, giving the security team complete control over who can access what and when. This has become even more critical since the introduction in Australia earlier this year of the Notifiable Data Breaches scheme that has made it a requirement for organisations to publicly announce a data breach if sensitive personal data has been compromised.
For many businesses, there can be a resentment within security teams over public cloud applications because of the data security headaches that they can pose. Cloud encryption offers a solution to this situation, but businesses shouldn’t have to choose between app functionality and data security. The split index approach to encryption enables businesses to benefit from public cloud applications without causing problems for their IT security teams, meaning that employees are allowed to work efficiently and data is kept safe.