Requirement 3: Protect stored cardholder data

The detailed requirements in this section are relevant to WebSphere Commerce. Review each point carefully. Attention: For all secure disposal of old database files (for example, from previous versions of WebSphere Commerce) as well as old key files and other important data, we must develop a disposal policy using one or more of the following tools:

SRM

Use the -p 7 parameter to specify 7 removal passes. SDelete implements the Department of Defense clearing and sanitizing standard DOD 5220.22-M, to give you confidence that once deleted with SDelete, your file data is gone forever.

3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:

• Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements.

• Processes for secure deletion of data when no longer needed.

• Specific retention requirements for cardholder data.

• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

With the database administrator, we can work out a schedule for removing old payment data with the DBClean utility.

3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.

Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:

3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

WebSphere Commerce does not, by default, use or support a card-reading device.

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.

WebSphere Commerce stores the card-validation code temporarily before payment authorization in the ORDPAYINFO and PPCEXTDATA tables, and then removes it from the database after authorization is complete. If you allow modifying existing payment instruction protocol data, ensure that you have applied APAR JR50683 if we are on Fix Pack 8 or earlier.

If you need to change this behavior, set neverPersist to true in the PaymentSystemPluginMapping.xml file. This option captures the CVV data and sends it for payment authorization in a single transaction. This eliminates the step to temporarily store the CVV data in the database. Configuring the neverPersist option in this file is described in the following topic:

• PaymentSystemPluginMapping XML file

Notes:

1. Collect sensitive authentication only when needed to solve a specific problem

2. Store such data only in specific, known locations with limited access

3. Collect only the limited amount of data needed to solve a specific problem

4. Encrypt sensitive authentication data while stored

5. Securely delete such data immediately after use.

6. It is absolutely necessary for PCI compliance that you remove historical data stored by previous versions of WebSphere Commerce. WebSphere Commerce uses a database for data storage, so you must use a secure removal tool (SDelete or SRM) to remove our old database files.

3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.

WebSphere Commerce does not record or store PIN numbers. 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.Notes:

• This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN.

• This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, for point-of-sale (POS) receipts.

WebSphere Commerce masks account numbers when displayed in the starter stores and in IBM Sales Center and most panels of WebSphere Commerce Accelerator. In some cases, the PAN is displayed in clear text for authorized administrative personnel. If you have customized your storefront, your administrative tooling, or both, ensure that they comply with the requirement.

By default, the last 5 digits of the account number are shown in plain text in the starter stores. To be PCI compliant, we must reduce this to the last 4 digits of the account number. To change this value, open the PaymentSystemPluginMapping XML file and change the value of the plain attribute on the <Keyword name="account" element from -5 to -4. 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) 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.

Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN. WebSphere Commerce uses Triple-DES algorithm, by default, to encrypt the PAN data in the database. AES-128 bit encryption can alternatively be used to encrypt database data beginning in Fix Pack 8. You are encouraged to use AES-128 bit encryption as it is a newer algorithm, and considered to be the industry standard.

Note: Ensure that the PDIEncrypt flag is set to On (it is on by default) in the WebSphere Commerce configuration file:

WAS_profiledir/installedApps/instance_name_cell/instance_name.ear/xml/config/wc-server.xml

3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts..

WebSphere Commerce does not use disk encryption – the application encrypts the data before it is stored in the database. 3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse:

Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies 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.

The merchant defines the encryption key when the instance is created.

Additionally, each WebSphere Commerce Payments instance requires a password so that it can decrypt any sensitive data stored in the database. Protection of this password is therefore critical to protecting the security of your payment data.

Note: It is absolutely necessary for PCI compliance that you securely delete old key files using a
secure removal tool (SDelete or SRM).

3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary.

The merchant is responsible for limiting the number of custodians. 3.5.2 Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and stored separately from the data-encrypting key

• Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device)

• As at least two full-length key components or key shares, in accordance with an industry-accepted method

Note: It is not required that public keys be stored in one of these forms.

The Key Locator Framework (KLF) can be configured to store the merchant key (used for database encryption) in an external file, or some other secure location. A Key Encryption Key can also be specified to encrypt the merchant key in its storage location. Each file should be protected with file system protection and any other means deemed necessary. For more information on the KLF, see 3.6.6.

3.5.3 Store cryptographic keys in the fewest possible locations.

The merchant is responsible for storing cryptographic keys in the fewest possible locations. 3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:

Note: Numerous industry standards for key management are available from various resources including NIST.

3.6.1 Generation of strong cryptographic keys Triple-DES: WebSphere Commerce generates a Triple-DES data encryption key based on a seed called a merchant key provided by the customer.

16-character merchant key

The data encryption key is generated by passing the merchant key into a mixing function. This function scrambles the merchant key, mixes it with the hexadecimal value set, and shifts bytes around to produce the final key.

32-character merchant key

The data encryption key is generated by passing the merchant key into a randomizing function.

It is highly recommended that the merchant provides a strong merchant key following the guidelines below:

• 16 digit hexadecimal number

• A 32 hexadecimal number is also supported.

• At least one alphanumeric character (a to f)

• At least one numeric character (0 to 9)

• Cannot enter the same character more than 4 times in a row

With the help of Key Locator Framework (KLF), the key can be stored in a file. This file should be protected with proper file permissions. 3^rd party software such as TripWire can be used to monitor changes to this file. To meet the standard, we must use the WCExternalFileMerchantKeyImpl plug-in provided by the Key Locator Framework. This plugin allows the merchant organization to split knowledge of the key between two custodians. No single key custodian will know the entire merchant key. Details are documented in the following link:

• Key Provider Implementations for merchant key

The WCExternalFileMerchantKeyImpl plug-in can also use a Key Encryption Key to encrypt the merchant key. Although by default this is an optional parameter, we must specify a Key Encryption Key to meet the requirements of the PCI DSS. The key encryption key is as important as the merchant key. When specifying a key encryption key, it must be as strong as the encryption key. Furthermore, it's highly recommended to provide a key encryption key that follows the guideline below:

• 16 digit hexadecimal number

• A 32 hexadecimal number is also supported.

• At least one alphanumeric character (a to f)

• At least one numeric character (0 to 9)

• Cannot enter the same character more than 4 times in a row

3.6.2 Secure cryptographic key distribution WebSphere Commerce does not distribute its secure keys in a non-clustered environment. To deliver the keys between cluster members in a clustered environment, the merchant key and key encryption key must be transferred by two different administrators, using a secure transmission program (such as SFTP) to maintain dual key control. Important: Never use insecure transmission such as ftp for transmitting cryptographic material or other important data.

3.6.3 Secure cryptographic key storage

Configure KLF to store the merchant key (in encrypted format) in an external file. Specify a key encryption key in a separate file, which is used to encrypt the merchant key. Each file should be protected with file system protection. For more information on the KLF, see 3.6.6.

3.6.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).

When people who know the key leave your merchant site organization, or if you suspect that a key has been compromised, WebSphere Commerce has a utility for supporting key changes. See MigrateEncryptedInfo utility

We can use a new -interactive parameter to indicate that each half of the key must be input by a different administrator. This further enhances the split key knowledge requirement. 3.6.5 Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys 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 component), or keys are suspected of being compromised.

Note: If retired or replaced cryptographic keys need to be retained, these keys must be securely archived (for example, by using a key-encryption key). Archived cryptographic keys should only be used for decryption/verification purposes. The key is overwritten if you use the MigrateEncryptedInfo utility as described in 3.6.4.

Note: Use a secure removal tool (SDelete or SRM) to delete old or suspected cryptographic material. 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed 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.

To comply with the Payment Card Industry (PCI) Data security standard, a Key Locator Framework (KLF) has been introduced that allows the encryption key (for example, the merchant key and Payments instance password) to be stored and retrieved from a configurable location such as from an external, more secure, device.

The Key Locator Framework provides the flexibility to define multiple encryption keys available to the system although each encryption key can be retrieved from a different provider. Four encryption key providers are defined by default, two for merchant key and two for Payments instance password.

See the Key Locator Framework (KLF) To achieve dual key control, the Key Encryption Key must be specified and kept in a separate file system than the merchant key. No single user can have access to both file systems where the key encryption key and merchant key are stored. As an example, key encryption key should be stored in a removable media and the custodian of the removable media does not have access to the file system where the merchant key is stored.Important: Use operating system access control groups to protect access to the key files and the key encryption key file.

3.6.7 Prevention of unauthorized substitution of cryptographic keys To prevent unauthorized substitution of keys:

• Ensure that the two files that we used to store the keys with the Key Locator Framework are protected with appropriate file permissions

• Ensure the merchant key files are monitored by the file integrity monitoring system.

3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.

If you suspect that a key has been compromised, you should change it as described in 3.6.4.

3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.

The merchant is responsible for documenting and communicating the security policies and operational procedures to all affected parties.

Previous topic: Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Next topic: Requirement 4: Encrypt transmission of cardholder data across open, public networks


Related concepts
WebSphere Commerce and the PCI Data Security Standard