3: Protect Stored Account Data

Requirement 3.2.1

Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:

Coverage for all locations of stored account data.
Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. This bullet is a best practice until its effective date; refer to Applicability Notes for details.
Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.
Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.

Cardholder data that exceeds the customer-defined retention period must be securely deleted. According to PCI DSS Requirement 3.2.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 3.3

Sensitive authentication data (SAD) is not stored after authorization

Such data is not required by IBM Safer Payments for full operational functionality. To meet this requirement, supplying systems must be configured in a way that they do not send such data to IBM Safer Payments. If you send such data to IBM Safer Payments, your installation is not PCI DSS compliant.

Requirement 3.3.1

SAD is not retained after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.

Note: This requirement applies only if previous versions of the payment application stored sensitive authentication data.

If you are migrating from competing software that stores sensitive authentication data, such data must be removed. Any disk space that is previously used for storing sensitive authentication data must be deleted securely by using a disk wipe tool. For more information, see Running a secure wipe tool.

Removal is necessary for PCI DSS compliance.

IBM Safer Payments itself securely wipes any files that store encrypted attributes when they are deleted from the user interface.

Requirement 3.4.1

PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.

Note: This requirement does not supersede stricter requirements in place for displays of cardholder data. For example, legal or payment card brand requirements for point-of-sale (POS) receipts.

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.

For more information, see Setting user privileges.

Requirement 3.5.1

PAN is rendered unreadable anywhere it is stored 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).
- If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN.
Index tokens.
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 3.6.1

Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include:

Access to keys is restricted to the fewest number of custodians necessary.
Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
Key-encrypting keys are stored separately from data-encrypting keys.
Keys are stored securely in the fewest possible locations and forms.

This requirement applies to keys used to encrypt stored cardholder data, as well as to key-encrypting keys used to protect data-encrypting keys. Such key-encrypting keys must be at least as strong as the data-encrypting key.

IBM Safer Payments meets this requirement. For more information, see Key management configuration and 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.6.1.3.
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.

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.

Requirement 3.7

Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

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

3.7.1 Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data.

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

3.7.2 Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.

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 Configuring keygen key management.

Public keys are made available to IBM Safer Payments by entering them in the GUI. For more information, see Activating a keygen master key or Activating a KMIP master key. 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.

3.7.3 Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.

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.

3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following:

A defined cryptoperiod for each key type in use.
A process for key changes at the end of the defined cryptoperiod.

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.

3.7.5 Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when:

The key has reached the end of its defined cryptoperiod.
The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known.
The key is suspected of or known to be compromised. Retired or replaced keys are not used for encryption operations.

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.

3.7.6 Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using 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.

3.7.7 Key management policies and procedures are implemented to include the 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.