Domain 11: Encryption and Key Management

CSA Guidance Version 3

Domain 11: Encryption and Key Management

It would be intuitively obvious to a security professional that if an organization needs to store data and doesn’t trust who can access or use the data then the data must be encrypted. Inside an on-premise data center where the organization controls all assets data is encrypted because some regulations say the data must be encrypted (PCI DSS for example).

In the cloud, where there are multiple tenants and administrators working for someone else it would seem obvious that much more data would need to be encrypted. If that is the case how do those processes work and how does the organization manage their keys. Encrypting everything increases complexity. On the other hand is it even necessary to encrypt these volumes of data if they cause business process complexity amongst other issues? Is there another way to reduce the need to encrypt data and subsequently manage the keys? This chapter looks at these issues.

Overview.

Is encryption and key management required in the cloud?
Business processes and encryption
Data protection types
Key management in the cloud

1.1 Encryption

There are reasons to look at alternate solutions to encryption. Data that is encrypted and sent into the cloud still looses the custodial relationship for some organizations. For those organizations that refuse to send data outside their organization there is an alternative. A public cloud service can be integrated with a private cloud that stores sensitive data. The data sent to the public cloud is altered and would contain a reference to the data residing in the private cloud. There are vendors working on this concept. The remainder of this section concentrates on cryptography being used in cloud deployments.

There are 2 complementary concepts used in the encryption section, they are:

Content Aware Encryption. Used in Data Leak Prevention, Content aware software understands a data type or format and encrypts based upon policy settings. For example a credit card number is encrypted in an email being sent to law enforcement.
Format Preserving Encryption. Encryption that preserves format is a result that encrypts a message and produces a result like the input message. A 16 digit credit card number is a 16 digit number after encryption. A telephone number would look like a telephone number and an English word would look like an English word and so on.

The ability to encrypt from the enterprise to the cloud without user intervention is how to make data safe. Content aware software can be leveraged for public cloud encryption if the software can be configured to be protocol aware as well and encrypt fields in a REST http transaction to a public cloud application. The Data Leak Prevention[1] use case today has products that can enforce data protection leaving the enterprise, usually by email, and encrypts data before the transaction leaves the enterprise. The principle can be used in cloud data protection however the DLP product would generate alerts. A content aware service would need to detect, encrypt and log but not alert.

Format preserving encryption takes content aware a step further by being sensitive to the data needing encryption and maintains the data format and type. In conventional encryption a credit card being encrypted for example would render a binary cipher text[2] that would need to be encoded in some way. The credit card would also not be a 16 digit number any longer as well. Format preserving encryption would generate a cipher text value that is 16 digits in addition to being encrypted.

By also preserving the data type and format the service providing encryption can then easily change values in line over a wide variety of protocols. The key challenge to format preserving encryption is in encrypting large clear text values such as an email stored in the cloud. Bulk scale encryption is normally how text values are encrypted using block ciphers[3]. In the format preserving case each word would be encrypted into another word, which would take time. The result however would be words in the language the original email was written in, although it wouldn’t make sense. If each encrypted word were spelled correctly then the format preserving encryption engine wouldn’t break a spell check program that would be used after encryption.

An enterprise can also develop an encryption/decryption process internally or use another type of encryption technology available on the market today. The idea being however that users wouldn’t have to undertake any process on their own. There needs to be a process within the enterprise that performs encryption on the way out to the cloud and decrypt data on the way back in.

Encryption in cloud applications poses some issues for business applications that an application architecture needs to address. These are:

If data in the application is needed to search for records or objects then an encrypted primary key[4] would make that difficult
If the cloud application set contains batch jobs or other types of processes that work on data, and those processes are moved to the cloud, that situation will complicate key management

An application that needs to find records or objects in a database needs to develop another way to store a unique value such as tokens. Tokens are used in credit card environments to ensure the credit card number is minimally accessed in applications. A unique token generated from the value can be used to develop a new primary key that the application can use and not expose sensitive data in a public cloud.

As will be discussed in section 2, below, keys should not be stored in the cloud and must be maintained by the enterprise or a trusted key management service provider. Processes, such as analytical processes, that need to operate on clear text data and run in the cloud with the other business applications and data must have access to keys or a service in order to perform their functions. See section 2 for more details on key management in the cloud.

1.2 Recommendations

Recommendations

Use best practice key management practices when using any form of encryption/decryption product
Use off-the-shelf technology where possible to get the best practices from a credible source

It is highly recommended that an enterprise use best practice key management practices and obtain technology and products for encryption, decryption, signing, and verifying from credible sources.

1.3 Requirements

Requirements

Deploy technology integrated into corporate systems based on user identity
Manage keys used by the cryptographic processes using requirements in the next section
Use existing systems such as DRM[5] or DLP if possible.

Binding cryptographic operations and key management to corporate identity systems will provide the organization with the most flexible integration and uses technology that the organization already knows works and has been audited and or reviewed.

2.1 Key Management

One of the more difficult processes in public cloud computing is key management. The multi tenant facility known as the public cloud causes key management issues for processes running there.

The easiest use cases are those that have applications running in the public cloud and keys that encrypt data going to the public cloud from the enterprise are used within the enterprise only. As described in section one there are encryption engines that can encrypt data on the way out and decrypt data on the way back in. An application using cryptographic keys gets complicated when other processes, such as batch jobs and the like, need access to keys to decrypt data and those processes reside in the public cloud.

Enterprise users need to have keys of their own so that one shared key is not used across the enterprise. The easiest way to accomplish user specific keys is to purchase a cryptographic engine for each user or assign keys based on the user’s identity. In this way anything, which is encrypted specifically for a user is maintained for that user. If users needs access to data in a group setting then group level keys can be associated with the application that maintains group access and users within that group can share the keys. The keys should be maintained within the enterprise as discussed earlier in this section.

2.2Recommendations

It is highly recommended that organizations maintain their own keys or use a trusted cryptographic service from a source that currently maintains such as service.

If an organization needs to run analytics or other processes using data stored in the cloud then the organization should develop a platform such as Hadoop and have that data derived from the cloud source. Hadoop has its own set of security issues but those won’t be addressed in this chapter.

User specific keys can be maintained at the individual or group level. Group access can be managed with off-the-shelf technology such as DRM systems and other software running on the desktop/laptop that encrypts disks, folders, and email messages.

2.3 Requirements

In order to maintain best practices and pass audits the organization should manage their keys in the custody of their own enterprise or that of a credible service from a cryptographic service provider.

Keys used in existing encryption technology such as DRM and disk encryption products can be managed my central, internal to the enterprise, key storage technology. Hardware Security Modules (HSM) can be used to store keys as well as process cryptographic operations such as encryption/decryption, signing and verifying.

Enterprise users will go through a registration process to enable cryptographic operations and other processes in the enterprise, such as Content Aware or Format Preserving systems can access users keys as needed.

[1] Data Leak Prevention (DLP) products have an enforcement mode that detects data leaving the enterprise and encrypts it.

[2] Cipher text. The result of an encryption operation. The input is known as clear text.

[3] Ciphers. Algorithm based software/hardware that perform encryption/decryption and signing/verifying

[4] Primary key. A database column/field/attribute that is used to uniquely identify records in a database

[5] Digital Rights Management. A process that protects content such as internal corporate communications or copyrighted material