Protect Stored Cardholder Data

Integrator Notes

To alleviate much of the risk and complexity of storing card holder data, Singlefront will not store the PAN (Primary Account Number, or Credit Card Number) or log any sensitive customer data. Not storing the PAN alleviates the need to encrypt the Cardholder Name, and Expiration Date.

While you can modify the code to store the PAN or log sensitive data, you should NOT unless you intend to have your new code PABP re-certified by an accredited third party.

Per PCI-DSS 1.3.4 your database should reside on an internal network segment that is segmented from the DMZ.

When testing a storefront you should not use live credit card data but instead use test credit cards provided by your gateway provider.

Should you need to store sensitive data for debugging purpose you must ensure the following:

•	Collect sensitive authentication data 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

Configuration Notes

Versions of Singlefront before 5.0 optionally allowed you to store sensitive Credit Card data. Under PCI-DSS requirement 3.2, storage of sensitive authentication data is prohibited. We provide a script called “Remove Credit Card Information from Versions 4.5 and Below.sql” that will erase sensitive Credit Card data in these fields. Erasing this data will not disable the application but render the saved credit card data unreadable. This script will not work in Version 5.0 of the database and above as these fields have been removed from the schema. Because of this, removal of sensitive credit card data from version 5.0 databases and above should not be an issue.

To run the “Remove Credit Card Information from Versions 4.5 and Below.sql” script, open it in SQL Server Management Studio and run it against your pre-5.0 Singlefront database. After the script has been run, verify that the ZnodeOrder table does not have any sensitive credit card data in it.

When upgrading to version 5.0 you must also be sure to securely remove the Web/bin/ZNode.Libraries.Framework.Business.dll. This will remove the previous encryption key used for the above credit card data and is required for PCI-DSS compliance. Use a utility such as sdelete to securely delete the DLL and its associated encryption key. Sdelete can be found at http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx