Re: credit card number stored issue

Tim

Depending on what Merchant Level (1-4) you are at, there are a variety of precautions the Payment Card Industry (PCI) says you must take with CC#'s. There are some exceptions, but as a general rule you have to encrypt credit card numbers and make them unreadable by anyone who does not have a "need to know". Your application can (and should) encrypt all credit card numbers before writing them to disk, and then selectively decrypt them when they are read. The "selectively" part is really the most challenging part of encryption for you because it typically means that you have to develop business rules that describe who is allowed to decrypt a credit card. All the other parts of encryption can be well automated using off the shelf tools.

Another requirement of PCI is to securely log the decryption process. That way if I decrypt a credit card number and then buy a new refrigerator with it, you can tell it was me. Secure logs typically mean they are moved off the system of origin to another server where the chances of log tampering is reduced. The biggest issue here is that if I have *ALLOBJ authority on the /400, I could potentially violate the logs, but if the log is external, presumably I will not also be administrator on the external log server so it would be harder for me to corrupt the logs.

Finally there is encryption key management. In the PCI standard that David pointed you to there is reference to "separation of duties" and Dual Control" when it comes to encryption key management. The basic idea here is that any person who has carte blanche access to all the data (*ALLOBJ users and the like) should not also have carte blanche access to the encryption keys - else they can use keys against data that they should not see (Do we, as system administrators, ever need to see a customer's whole credit card number?) For that reason, external key management is also critical - it is the only way you can implement dual control on a DB2/400 credit card database. Implementing a key server on a different system that where the data is stored is relatively straight forward (and essential). This can either be an external key server appliance, or it can be a second /400 that just serves keys. If you go the second /400 route, just make sure that none of the *ALLOBJ users on the data system are also *ALLOBJ users on the key system.

HTH,

jte

tim wrote:

I am interested in the "best" way to store credit card numbers on my
iseries. Im not sure of compliance issues.

--
John Earl

President and CEO,
Townsend Security
ph: 360-359-4418 townsendsecurity.com