Secure > Overview: WebSphere Commerce and the PCI Data Security Standard > Address the PCI Data Security Standard within WebSphere Commerce
Requirement 3: Protect stored cardholder data
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, develop a disposal policy using one or more of the following tools:
- SDelete
SDelete is a tool for secure removal on Windows platforms.
Use the -D parameter for PCI compliant removal.
- SRM
SRM is a tool for secure removal on Unix platforms.
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, the file data is gone forever.
Recommendations...
- Keep cardholder data storage to a minimum.
Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
With the database administrator, you can work out a schedule for removing old payment data with the DBClean utility.
- Do not store sensitive authentication data after authorization (even if encrypted).
- Do not store the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called...
- full track
- track
- track 1
- track 2
- magnetic-stripe data
WebSphere Commerce does not, by default, use or support a card-reading device.
- 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.
To change this behavior, set...
neverPersist = true
...in PaymentSystemPluginMapping.xml. 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.
Configure the neverPersist option in this file is described in the following topic:
Collect sensitive authentication only when needed to solve a specific problem
Store such data only in specific, known locations with limited access
Collect only the limited amount of data needed to solve a specific problem
Encrypt sensitive authentication data while stored
Securely delete such data immediately after use.
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 use a secure removal tool (SDelete or SRM) to remove the old database files.
- Do not store the personal identification number (PIN) or the encrypted PIN block.
WebSphere Commerce does not record or store PIN numbers.
- Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).
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 the storefront, the 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, 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.
In WebSphere Commerce version 7 Fix Pack 1 and later, this value is already set to -4 by default.
- Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:
- One-way hashes based on strong cryptography
- Truncation
- Index tokens and pads (pads must be securely stored)
- Strong cryptography with associated key-management processes and procedures
The MINIMUM account information that needs to be rendered unreadable is the payment card account number.
WebSphere Commerce uses the industry standard Triple-DES (data encryption standard) algorithm to protect sensitive information, such as passwords and credit card data.
Verify the PDIEncrypt flag is set to On (it is on by default) in the WebSphere Commerce configuration file:
PROFILE_HOME/installedApps/instance_cell/instance.ear/xml/config/wc-server.xml
- If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.
WebSphere Commerce does not use disk encryption – the application encrypts the data before it is stored in the database.
- Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse:
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 that is stored in the database. Protection of this password is therefore critical to protecting the security of the payment data.
It is absolutely necessary for PCI compliance that you securely delete old key files using a secure removal tool (SDelete or SRM).
- Restrict access to cryptographic keys to the fewest number of custodians necessary.
The merchant is responsible for limiting the number of custodians.
- Store cryptographic keys securely in the fewest possible locations and forms.
The Key Locator Framework (KLF) is configured to split and store the merchant key between two files on the file system. Each file should be protected with file system protection. For more information on the KLF, see 3.6.6.
- Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following:
- Generation of strong cryptographic keys
WebSphere Commerce generates strong 128-bit keys based on a seed called a merchant key provided by the customer. 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. It is highly recommended that the merchant provides a strong merchant key following the guidelines below:
- 16 digit hexadecimal number
- 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. 3rd party software such as TripWire can be used to monitor changes to this file.
To meet the standard, 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:
The WCExternalFileMerchantKeyImpl plug-in can also use a Key Encryption Key to encrypt the merchant key. Although by default this is an optional parameter, 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 is highly recommended to provide a key that follows the guideline below:
- 16 digit hexadecimal number
- 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
- 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.
Never use insecure transmission such as ftp for transmitting cryptographic material or other important data.
- Secure cryptographic key storage
The KLF is configured to split and store the merchant key between two files on the file system. Each file should be protected with file system protection. For more information on the KLF, see 3.6.6.
3.6.4 Periodic cryptographic key changes
- As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically
- At least annually
When people who know the key leave the merchant site organization, or if you suspect that a key has been compromised, WebSphere Commerce has a utility for supporting key changes. For more information, see:
As part of iFix APAR JR35199, you 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.
This APAR is contained in WebSphere Commerce version 7 fix pack 1.
You can also refer to the following instructions to change the payments instance password:
Change Payments instance password (ChangePassword)
- Retirement or replacement of old or suspected compromised cryptographic keys
The key is overwritten if you use the MigrateEncryptedInfo utility as described in 3.6.4.
Use a secure removal tool (SDelete or SRM) to delete old or suspected cryptographic material.
- Split knowledge and establishment of dual control of cryptographic keys
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.
For more information, 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.
Use operating system access control groups to protect access to the key files and the key encryption key file.
- Prevention of unauthorized substitution of cryptographic keys
To prevent unauthorized substitution of keys:
- Verify the two files that you 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.
- Requirement for cryptographic key custodians to sign a form stating 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.
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