DOMAIN 11

 ENCRYPTION AND KEY MANAGEMENT

For a security professional, it is obvious that if an organization needs to store data and doesn’t trust those 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 it causes 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.

11.1 Introduction to Encryption

Data classified as confidential for reasons of regulatory compliance or corporate secrecy must be protected. As confidential information that is currently managed within internal systems increasingly moves to the cloud, it must be protected with the same diligence. Moving data to the cloud does not remove any requirements for confidentiality and data protection. The loss of control of data outside the secured corporate perimeter (de-perimeterization) increases the complexity of protecting data and increases the risk of compromise.

There are a number of factors to consider regarding data encryption in the cloud, which include:

(A) Protecting data through encryption as it moves to the cloud requires more than just ensuring that a secure transfer channel (i.e. TLS) is used. Encrypting the transfer of data to the cloud does not ensure the data is protected in the cloud. Once data arrives in the cloud, it should remain protected both at rest and in use.

(B) For unstructured files that must be protected when stored or shared in the cloud use data-centric encryption, or encryption embedded into the file format whenever practical to apply protection directly to files.

(C) Understand how all encryption / decryption keys will be managed for the entire lifecycle of the data. Whenever possible avoid any reliance on cloud providers to protect and appropriately use the keys that protect your critical information.

(D) Avoid opportunities for lapses in the employee safeguards of others, or of regional laws that may provide undesired, but mandated access to your encrypted files. If only you have the keys, only you can access your files.

(E) Do not forget to protect files that are often overlooked, but which frequently include sensitive information. Log files and metadata can be avenues for data leakage.

(F) Encrypt using sufficiently durable encryption strengths (such as AES-256) that comply with the same corporate and regulatory mandates used for encrypting internally maintained files. Use open, validated formats and avoid proprietary encryption formats wherever possible.

11.2 Alternative Approaches to Encryption

There are good reasons to look at alternate approaches to encrypting data in the cloud. For many organizations sending data into the cloud is equivalent to transferring custodial relationship.

For those organizations that have issues with sending unsecured data outside their organization there are alternatives:

(I) Tokenization : This is where public cloud service can be integrated/paired 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.

(II) Data Anonymization : This is where (for example) Personally Identifiable Information (PII) and Sensitive Personal Information (SPI) are stripped before processing.

(III) Utilizing cloud database controls : This is where the access controls built into the database are deemed to provide adequate levels of segregation.

As a rule, good data management practices are essential before moving data into the cloud, to understand whether all or just some of the data need to be encrypted, protected by an alternative method, or not protected at all.

When evaluating what to protect through encryption of other alternative methods there are risks of data sharing that can be broken down into two primary categories: disclosure and misuse, under the following areas:

(A) Accidental public disclosure : Making information or data readily available to the general public via publication or posting on the web.

(B) Accidental or malicious disclosure : The act of making information or data available to a third party(s) as a result of inadequate data protection.

PII - Personally Identifiable Information

SPI - Sensitive Personal Information

(1) Compelled disclosure to third parties : The obligations of having to respond to subpoenas requesting data disclosure in lawsuits.

(2) Government disclosure : The release of data to government entities, either by law, or by court order (such as the Patriot Act).

(3) Misuse of user or network profiles : The ability to analyze and data mine to derive sensitive information from seemingly benign traffic data, and thereby reveal user behaviors, associations, preferences or interests.

(4) Inference misuse : Being able to synthesize first-order or second-order identifiers to draw inferences about a person's behavior or identity.

(5) Re-identification and de-anonymizing misuse : Having access to enough “anonymized” information to be able to infer the original subject.

11.3 Cryptography in Cloud Deployments

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

(A) 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.

(B) Format Preserving Encryption : Encryption that preserves format is a result that encrypts a message and produces a result like the input message. For example, 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.

The ability to encrypt from the enterprise to the cloud without user intervention is to the preferred way 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 (DLP) use case today is met by products that can enforce data protection leaving the enterprise, usually by email, and encrypt data before the transaction leaves the enterprise. This principle can be used in cloud data protection; however, the DLP product may 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 maintaining the data format and type. For example, with conventional encryption, a credit card being encrypted would render a cipher-text that would no longer be a 16-digit number. 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. In the format preserving case, each word would be encrypted into a character string of the same length, which takes time. The result, however, would be cipher-text data values that can be stored in fields of the same data-type as the original plain text.

In the format preserving case, each word would be encrypted into a character string of the same length, which takes time. The result, however, would be cipher-text data values that can be stored in fields of the same data-type as the original plain text.

Data Leak Prevention (DLP) :  products have an enforcement mode that detects data leaving a secured device or the enterprise and encrypts it.

Cipher text - The result of an encryption operation. The input is known as clear text.

Ciphers - Algorithm based software/hardware that perform encryption/decryption and signing/verifying

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

(1) If data in the application is needed to search for records or objects, then an encrypted primary key would make that difficult.

(2) If the cloud application set contains batch jobs or other types of processes that work on sensitive data, particularly PII and SPI 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 may choose to develop another way to store a unique value such as tokenization. Tokens are often 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 without exposing sensitive data in a public cloud.

As will be discussed in section 11.4 below, where possible, keys should not be stored in the cloud and must be maintained by the enterprise or a trusted key management service provider.

Processes that need to operate on clear text data and run in the cloud with other business applications and data must have access to keys or a service in order to perform their functions. See section 11.4 for more details on key management in the cloud.

11.3.1 Encryption in Cloud Databases

The first thing to consider is whether it is necessary to encrypt the data. All databases provide the ability to restrict access to data. If properly implemented, that may be enough to protect confidentiality.

Other reasons that may require the encryption to protect data stored in the database are:

(a) To hide it from those with privileged access to the database (Database Administrators (DBA’s), for example)

(b) To comply with legal statutes (such as California's SB1386 law)

(c) To store it in a schema for which the data owner cannot control the account 

credentials accessing the data (using shared accounts, for example)

When using a cloud database and particularly SaaS solution employing a database, the database ability to function correctly may be compromised unless it can operate on the encrypted data, necessitating the database or cloud application to have access to the keys.

Data encryption comes at the price of complexity and performance, and there are effective alternatives to encryption:

(i) Use object security : Use SQL grant and revoke statements to restrict which accounts can access the data. The accounts to which you grant access must be controlled to ensure that you are only allowing access to authorized users.

(ii) Store a secure hash : Rather than storing the data directly, store a hash of the data. This allows your program to prove that the holder has the correct value without actually storing it.

11.4 Key Management

One of the more difficult processes in public cloud computing is key management. The multi-tenant model of public cloud solutions 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 processes, need access to keys to decrypt data and those processes reside in the public cloud.

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

Entity - For the purpose of identity, could be a user, code, a device, an organization or agent

Where data is stored in a public cloud environment, there are problems when exiting that environment to be able to prove that all data (especially PII or SPI data, or data subject to regulatory assurance regimes) has been deleted from the public cloud environment, including all other media, such as back-up tapes. Maintaining local key management allows such assurance by revoking (or just deleting/losing) the key from the key management system, thus assuring that any data remaining in the public cloud cannot be decrypted.

11.4.1 Storage and Safe-Guarding of Keys

Encrypting data has little value if both providers as well as users of cloud services do not vigorously enforce the processes around key management.

On the provider side, a lack of SOD (Segregation of Duties) around access to key servers and servers having encrypted data should be a cause for concern, as well as DBA’s having access to individual keys for databases, or the architecture of the database service reliant on a single key.

Controls around protecting the keys themselves, by using KEK (Key Encrypting Keys) and generation of encryption keys in-memory, and only storing the encrypted key of key servers are all valid architectural solutions that should be considered when architecting any solution.

Keys managed on the client side that protect keys on devices that are not themselves secure (such as mobile devices) or devices which do not have the same level of controls as the encrypting system itself should be a cause for concern.

11.5 Recommendations

General Recommendations

(1) Use best practice key management practices when using any form of encryption/decryption product.

(2) Use off-the-shelf technology where possible to get the best practices from a credible source.

(3) Use best practice key management practices and obtain technology and products for encryption, decryption, signing, and verifying from credible sources.

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

(5) If an organization needs to run analytics or other processes using data stored in the cloud then the organization should develop on top of a platform such as Hadoop and have that data derived from the cloud source. Such development platforms, including Hadoop, have their own set of security issues but those are beyond the scope of this chapter.

(6) Key scoping can be maintained at the individual or group level.

(7) Group access can be managed with off-the-shelf technology such as DRM (Digital Rights management ) systems and other software running on the desktop/laptop that encrypts disks, folders, and email messages.

Recommendations - Encryption within Databases

(1) Use standard algorithms. Do not invent/use proprietary scrambling techniques. Proprietary encryption algorithms are unproven and easily broken.

(2) Avoid old insecure encryption standards such as Data Encryption Standard (DES).

(3) Use object security. You should still use basic object security (SQL grant and revoke statements) to prevent access to even the encrypted data.

(4) Do not encrypt primary keys or indexed columns. If you encrypt a primary key, you will have to encrypt all referencing foreign keys. If you encrypt an indexed column, you may end up with slow queries when trying to use the encrypted value.

(5) Use a columnar approach to encryption (since big data system uses this).

11.6 Requirements

(a) 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.

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

(c) Enterprise users should 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 encryption/decryption keys as needed.

(d) Deploy technology integrated into corporate systems based on the identity of all components in the processing chain to make entitlement decisions.

(e) Manage keys used by the cryptographic processes using binding cryptographic operations.

(f) Use existing systems such as E-DRM or DLP if possible.

(g) 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.

E-DRM - Enterprise Digital Rights Management. A process that protects content such as internal corporate communications or copyrighted material

======// END // ========