Requirement 2: Protect stored cardholder data

Requirement 2.1

Software vendor must provide guidance to customers regarding secure deletion of cardholder data after expiration of customer-defined retention period.

Cardholder data that exceeds the customer-defined retention period must be securely deleted. According to PCI DSS Requirement 3.1, each licensee must define a retention period.

Data that is stored in the Disk Data Cache (DDC) of IBM® Safer Payments is automatically securely deleted. It is stored in a ring buffer type memory that overwrites itself when its capacity limit is reached. Therefore, in consequence, it is necessary that the DDC capacity limit is aligned with, or less than the retention period. IBM Safer Payments provides the configuration option, and it is the responsibility of the licensee to configure IBM Safer Payments accordingly.

However, this is not the case with indexes. If an index is created on an attribute that contains cardholder data, the “purge after” setting must be made accordingly with the definition of the index. IBM Safer Payments deletes such index entries automatically and securely. For more information, see Deleting outdated index entries.

Cardholder data can be used as part of conditions in the IBM Safer Payments configuration. Therefore, it is possible that the cfg directory also contains encrypted cardholder data.

IBM Safer Payments fully controls and protects cardholder data within its reach. Therefore, no special configuration is required regarding underlying software or systems (such as the operating system) to prevent inadvertent capture or retention.

Archived data and backups that are created by third-party applications are not in reach of the IBM Safer Payments software itself. Therefore, they cannot be securely deleted automatically by IBM Safer Payments. This aspect of this requirement must be met by organizational procedures.

For more information about how to securely delete cardholder data, see Running a secure wipe tool.

Certain operating system functions might also store encrypted cardholder data outside the reach of IBM Safer Payments. For more information about how to avoid this, see Configuring disk swapping and Disabling locate for folders.

You can freely define the storage locations of cardholder data within IBM Safer Payments. For more information, see Configuring cardholder data storage locations.

Data that is created via external Python scripts is out of scope of IBM Safer Payments. If Python scripts are used in combination with cardholder data or encrypted attributes, organizational procedures must be implemented to cover this aspect.

Requirement 2.2

If a PAN is displayed in full or only masked is determined by a user account privilege. Because the masking is run at the IBM Safer Payments server, unmasked PAN never make it outside IBM Safer Payments via the API. It is thus impossible for a non-authorized user to gain access to the full PAN numbers.

The licensee must implement proper operational procedures that ensure only users with legitimate business need to see full PAN are granted the respective privilege. IBM Safer Payments allows for granting this privilege on a per-user basis.

IBM Safer Payments displays PANs in the following components:

• Queries: PANs are masked depending on the user privilege.
• Defined risk lists: PANs are masked depending on the user privilege.
• Conditions: PANs are masked depending on the user privilege. Conditions can be found in many IBM Safer Payments definitions in the sections administration, model, monitoring, investigation, and report.
• Logs: PANs are always masked independent from the user privileges.

Requirement 2.3

Render PAN unreadable anywhere it is stored (including data on portable digital media, backup media, and in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography (hash must be of the entire PAN).
• Truncation (hashing cannot be used to replace the truncated segment of PAN).
• Index tokens and pads (pads must be securely stored).
• Strong cryptography with associated key-management processes and procedures.

Any storage of PANs uses 256-Bit AES encryption. This includes transaction attributes, indexes, and cases. Encryption is turned on by the respective configuration option after which the respective PAN attribute encryption setting must be turned on.

In IBM Safer Payments you can export data to store outside the payment application by CSV-exports and by the RDI interface.

If you use the RDI, you thus must render all PANs unreadable. For more information about how to configure masking for RDI, see Configuring miscellaneous settings.

If you use CSV-exports, you must enable encryption for sensitive exports. For more information about how to configure IBM Safer Payments encryption, see Enabling cardholder data encryption.

Even if debugging functions are enabled, PANs are never included in debugging logs. This is ensured by the design of the software and cannot be changed by configuration options.

Requirement 2.4

Payment application must protect keys used to secure cardholder data against disclosure and misuse.

IBM Safer Payments meets this requirement. For more information, see Key management procedures.

Generally, access to keys must be limited to the fewest number of custodians necessary. Also, keys must be stored securely in the fewest possible locations and forms. These are organizational duties to be met by the licensee.

For more information about the location where IBM Safer Payments encryption keys are stored, see Configuring cardholder data storage locations.

Remarks:

• This location is different for each IBM Safer Payments instance in a IBM Safer Payments cluster. Therefore, you must address the location individually for each cluster instance.
• Archived data and backups that are created by third-party applications are not in reach of the IBM Safer Payments software itself. This aspect of this requirement must be met by organizational procedures. If you do not intend to exclude the key path from backups, make sure that this does not contradict to PCI DSS Requirement 3.5.2.
• If the integrity of the key has been weakened, or there is a known or suspected compromise of a key you must activate a new usage key triplet and revoke the previous one. For more information, see Revoking Keys.

Requirement 2.5

Payment application must implement key management processes and procedures for cryptographic keys used for encryption of cardholder data, including at least the following:

For more information about how to securely generate, distribute, protect, change, store, retire, and replace cryptographic keys, see Key management procedures.

2.5.1 Generation of strong cryptographic keys

Key generation discusses strong cryptographic key generation procedures that are implemented in IBM Safer Payments.

2.5.2 Secure cryptographic key distribution

Private keys must be copied manually into the key directory of each IBM Safer Payments instance. Therefore, it is the duty of the licensee to ensure secure distribution. IBM Safer Payments itself does not distribute these files. For more information, see Key generation steps.

Public keys are made available to IBM Safer Payments by entering them in the GUI. For more information, see Activating keys. Therefore, communication between the workstations of the users and the IBM Safer Payments instances must be encrypted securely. For example, by using TLSv1.2. See refer to section 4.3.3.

2.5.3 Secure cryptographic key storage

IBM Safer Payments uses the AES-256 algorithm to ensure secure cryptographic key storage.

Any cryptographic keys must be stored securely, and access must be limited to people with a legitimate business need to access them.

2.5.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

IBM Safer Payments implements key-management procedures that allow for cryptographic key changes during operation, without service interruption. If no key change occurs during a defined period, IBM Safer Payments automatically shuts down. For more information about key change procedures that are implemented in IBM Safer Payments, see Enforcing regular key changes.

2.5.5 Retirement or replacement of keys (for example: by archiving, destruction, and/or revocation as applicable) as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key, etc.) or keys are suspected of being compromised.

IBM Safer Payments implements key-management procedures that allow for retirement or replacement of keys.

IBM Safer Payments does not archive revoked keys, and there is no need to do so. When a cryptographic key is retired/revoked in IBM Safer Payments, it soon becomes redundant because the process must include activation of a replacement key. There is no need to keep a retired/revoked key for decryption/verification purpose, because the same data can be decrypted/verified with any other valid key, including this and subsequent replacement keys.

IBM Safer Payments does not use any inactive cryptographic keys for encryption operations.

Retirement or replacement of keys is required, if the integrity of the key has been weakened, or keys are suspected of being compromised. See Revoking Keys for details.

If the integrity of the master key has been weakened, a new master key should be generated and deployed to the IBM Safer Payments cluster. For more information, see Changing the master key.

IBM Safer Payments securely deletes all revoked keys within its reach. However, you must delete revoked keys manually from all other storage locations by using a secure wipe tool. For more information, see Running a secure wipe tool.

2.5.6 If the payment application supports manual clear-text cryptographic key management operations, these operations must enforce split knowledge and dual control.

Note: Examples of manual key-management operations include, but are not limited to: key generation, transmission, loading, storage, and destruction.

IBM Safer Payments enforces split knowledge and dual control, as it supports manual cryptographic key management operations. More precisely, two key holders are required for key generation and activation.

2.5.7 Prevention of unauthorized substitution of cryptographic keys

Substitution of cryptographic keys must be legitimized by two key holders. Organizational procedures must be put in place by the licensee that ensures no single user is granted two accounts. This warrants that no single user can pretend to be two distinct key holders.

In consequence, unauthorized substitution of cryptographic keys is prevented.

Requirement 2.6

Provide a mechanism to render irretrievable any cryptographic key material or cryptogram stored by the payment application, in accordance with industry-accepted standards. These are cryptographic keys used to encrypt or verify cardholder data.

For PCI DSS compliance, cryptographic material must be rendered irretrievable. For more information about how to render cryptographic material irretrievable using a secure wipe tool, see Running a secure wipe tool.

IBM Safer Payments meets this requirement. Keys in IBM Safer Payments are application version independent and thus remain exactly what they are in an upgrade situation. Therefore, no action is required to render previous IBM Safer Payments version cryptographic material irretrievable. If you want to render cryptographic material irretrievable, you must revoke the respective keys. Keys that are revoked are securely deleted on disk (disk space overwritten with pattern) before the respective file contents are deleted.

Reencrypting historic data with new keys is an internal process of IBM Safer Payments, which is automatically triggered by entering and activating a new key, and revoking the old keys. For more information about these reencryption processes, see Enforcing regular key changes, Revoking Keys, and Changing the master key.