New regulations are now compelling company decision-makers to take a hard look at the compliance and data protection measures put in place by cloud providers. If encryption is involved, the key question of control arises, namely: What control does the company have over the cryptographic keys and processes throughout the data’s life cycle?

While cloud provider accountability will be extended by new data protection legislation, the ultimate responsibility for data protection and compliance remains with the client, i.e. the cloud user. Accordingly, you cannot simply take your cloud provider’s word at face value: Instead, you must act independently to ensure that your sensitive information about customers, business partners, and employees does not end up in the wrong hands. This is no simple matter, when one considers the increasing frequency and sophistication of hacker attacks. 

Correct implementation is important

Data encryption offers an effective solution strategy, since it ensures that any data successfully stolen by an attacker remains unreadable – and therefore of no value. Not all kinds of encryption are created equal, however. Among the many different kinds of encryption offered on the market, users should take special note of the following requirements for correct implementation:

1. Make use of standard encryption methods
Standard encryption methods – such as AES-256 or RSA-2048 – offer the advantage of being field-tested and verifiable, since the algorithms they use are in the public domain, i.e. open source. Accordingly, mathematical techniques can be used to confirm that the methods are correctly implemented and secure. Proprietary encryption solutions do not offer this kind of transparency. 

2. Use algorithms that are substitutable
Businesses should ensure that one algorithm can be quickly substituted for another, so as to ensure a flexible and fast response to changes in process, IT and regulatory requirements as well as security loopholes. Those that do not take this precaution run the risk of sinking valuable time and personnel resources in the reprogramming of algorithms, and failing to keep their encryption systems up to date.

3. Keep the keys in the company
The central tenet of cloud-based data security is that anyone in possession of the cryptographic key potentially has access to the data. Accordingly, key generation and management should always take place within your own enterprise. Any requests from cloud providers to surrender the key should therefore be categorically denied. The same applies to the ‘Bring Your Own Key’ setups offered by some cloud providers, where a new key is requested each time for a specific operation but without saving the key on a permanent basis. Since encryption and decryption takes place in memory, however, these data are held – however briefly – in an unencrypted state at the cloud provider. Attackers could target this brief period of time to intercept highly critical data and keys, and then proceed to misuse them for their own purposes – a worst-case scenario for any business.

4. Never permit access to data in plaintext
Always keep this basic principle in mind: If you want to be sure that the control over your data is yours and yours alone, you should never grant access to this data to anyone else. In addition to preventing the keys from ever leaving your premises, you must also ensure that the cloud provider can never gain access to your data in plaintext. Never. Not even briefly, not even in volatile memory and not even by only a handful of employees. Never!

Strengths and weaknesses compared

So which of the popular encryption techniques can meet the stated requirements for establishing a secure cryptosystem? We compare the strengths and weakness of individual solutions below.

• Packaged solutions offered by application and database providers
  Several vendors have recognized that data security is now indispensable and offer encryption solutions out of the box. Typically, however, the quality of the implementation cannot be verified, since these are closed-source solutions. As a general rule, there is also a serious disadvantage in systems where key management and data encryption/decryption all take place inside the application or database: This means that the keys are stored in the product to be protected, and encryption/decryption is also handled in the product. Under the hood, this means that application and database administrators can actually access the data in plaintext, even though this is a privilege that should be reserved for specially authorized users – such as HR staff (for personnel data, for example).
• Developer tools
  If specialized developer tools are used for software development, then data encryption is typically something the developers have to take care of themselves, integrating appropriate security solutions directly into the application. Here too, however, the cryptographic keys and the encryption itself form part of the actual application, and can easily be broken in attacks by malicious third parties. The situation is worsened by the fact that most developers are specialists in software functionality rather than software security. Even if only the tiniest of slip-ups is made when implementing the encryption solution, this can still result in serious software vulnerabilities. This also creates a major dependency on the provider of the security solution.
  
• Hardware security modules (HSMs)
  HSMs offer the convenience of having encryption operations and key management handled by a piece of physical equipment. But even an HSM cannot provide comprehensive protection for critical company information on its own: A connection will always be required to an application that notifies the HSM of the specific data that needs to be encrypted. If HSMs are deployed at cloud providers, for example, the data must first be received in an unencrypted state, since the encryption is handled by the hardware module. Here, too, the data is held in plaintext by the cloud provider for a brief period of time – and long enough for potential attackers to gain unauthorized access to the information.
• Encryption gateways
  By using encryption gateways, cloud users can avoid these kinds of attack scenarios entirely. One key feature of these security systems is that they are managed by the company as a ‘single point of control’, independently of the applications containing the data that require protection. Specifically, this means that all information is encrypted on passing through the gateway – and therefore before being transferred to the cloud application. And the data is not decrypted until they have been transferred back to the company. The cloud application has no access to keys or plaintext data at any point in time, since the client company retains sole control over the keys. Within the enterprise, keys are managed by specially appointed security administrators. While these admins authorize users to read the data in plaintext, they themselves have no access to the application or the stored data. Since the gateway offers flexible algorithm interchangeability, companies can also respond quickly and easily to changing requirements.

Encryption gateways that use a flexible template model also offer further advantages, namely the possibility of selective – i.e. ‘smart’ – data encryption. In most companies, the data requiring the highest level of protection typically makes up only a small percentage of the enterprise’s total dataset. With customizable templates, the company can target this data specifically. This reduces the encryption workload and helps to minimize potential performance bottlenecks – thereby applying another piece of wisdom from the field of IT security, i.e. to protect ‘as much as necessary and as little as possible’.

This article was originally published in German on computerwoche.de