Payment Card Industry (PCI) Data Security Standard (DSS)

The primary purpose of Symmetric Encryption is to secure data at rest and in-flight. It also secures encrypted fields in flight between the application servers and the backend databases, since the encryption/decryption occurs within the application. Additionally, it can be used to secure files containing PII data, securing both the network traffic generated while the file is being read/written to a network share as well as while the files are at rest locally or on a remote network share.

Symmetric Encryption secures

Key:

Since Symmetric Encryption is used to encrypt any sensitive data, such fields will be refered to as PII (Personally Identifiable Information) and not just PANs as mentioned in the PCI DSS.

PCI DSS offers 3 different ways of securing the data-encrypting key:

Key-encrypting Key

By default, Symmetric Encryption uses the key-encrypting key approach to secure the data-encrypting key that is actually used to encrypt/decrypt data.

Benefits:

Disadvantages:

Secure cryptographic device

Benefits:

Disadvantages:

Secure centralized Keystore / key share:

Benefits:

Disadvantages:

PCI Procedures

Note that Symmetric Encryption does not address the PCI DSS requirements relating to documentation.

In order to assist with PCI DSS audits, below are some of the ways that Symmetric Encryption assists with v3.2 of the PCI DSS

Requirement 3: Protect stored cardholder data

3.4 Strong Cryptography of PII wherever it is stored (PCI DSS v3.2)

3.4.a

Strong Cryptography is used to secure PII data.

The use of this strong cryptography is on a per attribute/column/field level. Not all data is encrypted, only that which is considered PII and marked for encryption by the developer.

Testing Procedure:

# Rails ActiveRecord example of securing `bank_account_number`
#
# A column called `encrypted_bank_account_number` should exist in the database
# that contains the encrypted bank account number. There should not be a column
# called `bank_account_number`
class User < ActiveRecord::Base
  attr_encrypted :bank_account_number
  attr_encrypted :long_string, random_iv: true, compress: true
# Mongoid example of securing `bank_account_number`
#
# A column called `encrypted_bank_account_number` should exist in MongoDB
# that contains the encrypted bank account number. There should not be a column
# called `bank_account_number`
class User
  include Mongoid::Document

  field :encrypted_bank_account_number, type: String,  encrypted: true
  field :encrypted_long_string,         type: String,  encrypted: {random_iv: true, compress: true}

Notes:

3.4.b, 3.4.c

3.4.d

3.5 Procedures to protect keys (PCI DSS v3.2)

3.5.1

Review the production environment setting in the file symmetric-encryption.yml:

3.5.2

Maintain separation of key custodians so that anyone with access to the data-encrypting key does not also have access to the key-encrypting key.

3.5.3a

3.5.3b

3.5.3c

3.5.4

3.6 Key Management Procedures (PCI DSS v3.2)

3.6.1a Key Generation

3.6.1b

3.6.2 Key Distribution

Verify the data-encrypting key is copied from a secure location with limited access and installed on the required servers.

Verify the key-encrypting key is copied from the secured source code control system during deployment.

3.6.3 Key Storage

Verify the data-encrypting key is

Verify the key-encrypting key is

3.6.4, 3.6.5 Key Rotation

After key rotation the retired/compromised/old data-encrypting keys will no longer be used for encrypting data.

The retired/compromised/old data-encrypting keys are retained to decrypt old or archived data. It is however recommended to remove these old keys once all data has been re-encrypted with the new keys and old archive data no longer needs these keys:

3.6.6

N/A, only applies to clear-text keys, whereas in Symmetric Encryption the data-encrypting key is secured using a key-encrypting key

3.6.7 Unauthorized key substitution

Procedures in place to prevent unauthorized replacement of keys:

Other:

The PCI DSS also makes the following recommendation:

“In addition to the above practices, organizations may also wish to consider implementing separation of duties for their security functions so that security and/or audit functions are separated from operational functions. In environments where one individual performs multiple roles (for example, administration and security operations), duties may be assigned such that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals.”

Maintain separation of custodians so that anyone with access to the data-encrypting key does not also have access to the key-encrypting key.

Recommend that neither of the above key custodians have access to the database backups or media.

Next => API