White Paper
Table of Contents The Case for Encryption... Encryption in Use Not Some Kind of Magic... Evaluating Encryption in Use Claims... 3 4 4 The Vaultive Approach... 5 2
Risk-conscious enterprises across the globe have been reluctant to embrace the public cloud model. For many, compliance requirements are the source of the reluctance. For others, concerns about ceding control of their data to a cloud service provider, without the cloud service provider accepting liability for customer data, are the major hurdles. Conforming to data residency regulations, when implementing a distributed services model, present a further complication. Even as these challenges to adoption loom large, the economics and productivity benefits of cloud-based services remain compelling. In order to effectively address the risks that stand in the way of cloud adoption for these enterprises, a range of elements must be in place, including continuous monitoring of the cloud service provider s data center, enforcement of appropriate service level agreements, data classification programs and definition of internal processes to manage cloud-based services. Encryption in use is a critical piece of this puzzle, since it provides a mechanism for these enterprises to extend their boundary of control to their data stored and processed at the cloud service provider. However, not all encryption in use is created equally secure and a generic, one size fits all approach is likely to fall short in providing an effective balance between security and functionality. The Case for Encryption For almost as long as the field of information security has been in existence, encryption of data at rest and encryption of data in transit have served as cornerstone technologies to prevent access to sensitive, proprietary, confidential or regulated data. Both forms of encryption operate through exchange and presentation of a combination of public and private keys to unlock the encrypted data. The great step forward for modern cryptography was the development of the concept that the key that you use to encrypt your data can be made public while the key that is used to decrypt your data can be kept private. The purpose of both is to ensure that only users or systems with access to the key could access the data. Encryption in use provides functionality that is almost counter-intuitive to the purpose behind modern encryption for data at rest and data transit: ensure that the data remains in an encrypted state, even as users interact with the data, performing operations like search or sort, for example. However, just like encryption for other states of data, encryption in use serves a clear need. Without encryption in use, organizations cannot retain ownership and control of their data stored and processed in a cloud-based service whether control is required to address security, compliance, data residency, privacy or governance needs. Encryption in use is similar to format preserving encryption in that it is applied in real time, but allows for a far broader range of cloud service functionality and feature support. Format preserving encryption is generally implemented to protect or isolate a specific subset of data for compliance or data residency reasons. Encryption in use, by contrast, enables enterprises to independently secure all their data stored and processed at cloud service providers while holding onto the encryption keys. The ongoing revelations of government surveillance, and the laws compelling cloud service providers to hand over customer data in response to government requests, highlight the challenge that end users face of meeting their obligations to retain direct control of their cloud data. The recent set of recommendations from the Review Group on Intelligence and Communications Technologies appointed by the White House focused on implementing better privacy steps is only the first step in revisiting the policies that compel service providers to hand over customer data or even their encryption keys. Because encryption in use is an emerging area, the technology can be easily misunderstood, or even easily 3
misrepresented. Typically, encryption in use entails the use of a gateway, or proxy, architecture. The user accesses the application via the gateway whether the application server is in the cloud or on premise. The key to decrypt the data resides at the gateway (or at an HSM integrated with the gateway), ensuring that data stored and processed at the server is persistently encrypted, even as the encryption is entirely transparent to the user. Were the user to access the server directly, bypassing the gateway, the data would simply appear as a string of encrypted gibberish. As long as the gateway remains under the data owner s control, only authorized users can gain access to the data stored and processed at the cloud service provider, or other third party. In the event that the cloud service provider is required to hand over customer data in response to a government subpoena, they must meet their legal obligation. However, if encryption in use has been implemented, the service provider can only hand over encrypted gibberish. The request for data must then be directed to the entity that holds the encryption keys. Likewise, a rogue administrator, a hacker or government entity would only be able view unintelligible gibberish if they gained access to the user account. Encryption in Use Not Some Kind of Magic In order to deliver on the promise of encryption in use, the gateway must deliver on a robust set of technical requirements: comprehensive service functionality and water-tight security based on a strong encryption scheme. What this means in practical terms is that the entirety of the service s functional elements and behavior must be mapped, and that the encryption scheme must allow for preserving functionality without compromising security. This is because the gateway must recreate the session for the cloud-facing leg, and transpose encrypted data into the flow without disrupting functionality like search, sort and index. Otherwise, the user experience is degraded, and the value proposition of the cloud-based service of improving productivity is undermined. Vendors face another set of choices: take shortcuts to cover as much ground to provide a superficial sense of security, or invest in extensive R&D work to deliver the optimal balance between functionality and strong security. For instance, vendors can opt to provide encryption for a just a few data fields, out of hundreds or even a few thousand, to encompass a specific subset of the enterprise s information. Equally, they can choose to implement a cloud data encryption scheme that preserves features relying on referential integrity such as sort, search and index for all data but that is easily reversible by attackers. By way of illustration, if the scheme involves deterministically encrypting words into very short AES blocks as a shortcut to referential integrity, the encoding pattern is consistent enough for common attacks to yield clear text from what might appear to be encrypted text. There are a variety of iterative attacks such as chosen plaintext attacks that will yield clear text if the encryption relies on a simplistic and consistent encoding pattern. So while the data may appear to be encrypted, and less vendor engineering resources are required to develop support application features and functionality, the data protection in place is barely skin deep. Encryption in use is not a kind of magic it requires dedicated engineering expertise, with collaboration between infrastructure, information security and encryption experts. And, the encryption scheme must be tailored to a specific application or service to deliver on the appropriate balance of security and functionality. Evaluating Encryption in Use Claims Can enterprises rely on a standard validation for encryption in use? Precisely because encryption in 4
use is a new area, third-party validation is a critical requirement before it is implemented in production environments. Unfortunately, the current set of standard validation and certification tests have limited applicability. The most frequently cited third-party validation by vendors in the space is FIPS 140-2 validation. As critical as 140-2 validation is as an evaluation benchmark, and specifically required under some federal procurement mandates, it has some limitations for encryption in use. Taking a step backward, it s important to note the scope of FIPS validation. The process essentially verifies that the algorithms are implemented according to defined specifications. However, it does not provide any validation about how the platform would use the cryptographic module in order to support encryption in use. For instance, the FIPS validation doesn t outline a set of best practices on how to use the cryptographic module. Instead, it verifies that whenever the system invokes AES encryption, the module performs AES encryption according to the standard specification. FIPS validation is limited to the cryptographic modules used, not the overall integrity of the platform, or the encryption scheme used in production environments. While FIPS validation is an important consideration, enterprises should be aware of its limitations as the sole third party validation for encryption. To use a real world analogy, the validation can demonstrate that a $500 bicycle lock is impervious to any lock picking attempts, but not that it isn t used to lock a bike to a fire hydrant, allowing a thief to simply lift the bike up and drive away. Another significant consideration is evaluating encryption in use in the context of a specific application or service. From the customer s perspective, it is appealing to use a single encryption platform for multiple applications. No customer wants to have to manage multiple appliances, management interfaces and vendors. The reality, however, is that to strike an acceptable balance for any risk conscious organization between security and functionality requires deep application knowledge and encryption in use expertise. Dig a little deeper on degree of support, or risk a gamble on production readiness. The degree of support is as critical as the extent of support. The Vaultive Approach At a high level, the technical challenge when implementing encryption in use is to maintain referential integrity, while ensuring that the data is secured and protected. Referential integrity is needed, for example, to ensure that a clear text search performed by a user returns a result based on all matching phrases or words from the encrypted data set. To recap, the short cut to referential integrity is simply to use deterministic word level encoding. This type of encoding delivers only superficial protection. The more difficult way to do it is maintain a self-referential system that incorporates several layers of protection and is itself entirely opaque and impervious to cryptographic attacks. Each time we develop support for additional applications, we understand the serious responsibility we are undertaking in creating a solution that truly meets the requirements and expectations of our customers: First and foremost, it must be secure. The encryption has to be strong, and not in any way vulnerable to common attacks such as chosen plaintext attacks. The second requirement is that it has to meet our customer s operational requirements and work within their existing ecosystem. The third is that it has to be transparent to the 99+% of the employees in the company who do not work in IT or Security. Fourth, is that the solution has to be seamless to the cloud application. 5
About Vaultive For businesses moving to the cloud, Vaultive s encryption in use technology mitigates risk by empowering companies with control and ownership of their data wherever it resides. Vaultive s customers hold the encryption keys, letting them retain the freedom to use the cloud applications professionals rely on, while ensuring the governance and security that the business demands. Optimized for multiple cloud applications, the Vaultive platform supports best practices for the control and ownership of corporate data in the cloud as outlined by the Cloud Security Alliance. Vaultive addresses the requirements of global enterprises in financial services, life sciences and pharma, legal and professional services, manufacturing, retail and media, while also offering a cost-effective solution for mid-size and smaller companies. For more information, visit or follow us on Twitter @vaultive. 6