We help IT Professionals succeed at work.

keeping customer credit card numbers on file

tkerschen
tkerschen asked
on
We are a wholesale distributor struggling to solve this issue: We have customers who tell us to charge their orders to their credit card and expect us to have their credit card numbers on file for this purpose. We obviously want to be PCI compliant, so keeping the numbers in a passworded spreadsheet on our server is probably not a legitimate option. We don't really need the ability to have customers enter their credit cards via a web site or anything. In fact, we are still charging the cards via a dialup card terminal. We just need to be able to securelty keep the card numbers and names somehow.
Comment
Watch Question

Hello

You need to encrypt card information while storing. Actual card information should be visible only to the authorized person using some authentication mechanism. Also ensure not to store security code since that is not allowed to be stored anywhere.

Not sure if there are any ready made apps are available for this purpose. Else you will require to get such app developed by someone.

Author

Commented:
If there were such an off-the-shelf app for this purpose, with the stored encryption, that should work fine for us. To get us by, we are using a passworded encrypted flash drive with an excel file containing the cc numbers. It's somewhat slow and has a tendency to lock up excel for some reason.
Dont know if any off-the-shelf app is available for this purpose.
Unfortunately there is no easy way out, encryption and key management are easily the most challenging PCI requirements to comply with. If you _absolutely must_ store the credit card numbers, you will need a strong cryptographic solution to protect it. What sort of amount of customers do you have? Remember that it's not only necessary to encrypt them, you will also need to have key management processes that employ split knowledge and dual control, the keys need to be regularly changed, all activities related to the encrypted data, systems and encryption keys must be logged and all of this must be documented on a very detailed level.

As a first step I would seriously re-evaluate whether storing the cardholder data is absolutely necessary, and if it is, get the PCI DSS from https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml, read Requirements 3 and re-re-evaluate.
Rich RumbleSecurity Samurai
Top Expert 2006

Commented:
As pointed out above, storage is only a small portion of the PCI/DSS compliance issue, a very small part. Also, key rotation/management are NOT required, but it is ONE WAY to satisfy 3.4 through 3.6. If anyone here knows the minimum effort one can do and be PCI complaint it's the company I work for (day job).

Look into hardware/software that might aid you in this rather than trying to develop it yourselves. Look into other POS terminals/systems/software to help facilitate your wants. Perhaps the company your currently using to process your cc's has a better system. Perhaps their competitors do.

PCI data is looked at from various angles and affects your entire network, if you have a VPN into the office network then see PCI 8.3. The entire PCI "standard" doesn't apply the same to everyone either, and depending on what you store, you might not even need to comply with any of it really: http://www.pcicomplianceguide.org/pcifaqs.php
But you stated you wished to store the cards for use again without taking them again, so that's the whole thing but never the CVC/CID codes (the 3 digits on the back).
-rich
I have some intimate knowledge on the issue too, since my day job is a QSA. :)

The current PCI v1.2.1 has 245 distinct requirements, if you store cardholder data (CHD) you need to comply with all of them, no matter how many cc transactions you handle, even one will do (storing CHD makes you qualify for SAQ D, which contains the full DSS requirements). The 245 requirements which govern everything from specific technical controls such as IDS, encryption, file integrity monitoring to processes, governance, incident response planning, awareness training, regular security testing etc and everything in between. If you store CHD, you must comply will all of them.

The first thing that's done when validating your compliance (whether on-site audit by a QSA or a self-assessment questionnaire) is determining the PCI scope. This means all systems, networks and applications that store, process or transmit CHD, and all systems directly connected to them. What this means, is that if you have 1 system that stores CHD, all systems with connectivity to that will also have to comply with all of the requirements, in a flat network this can easily mean every system in the environment. If you absolutely must have a system that stores creditcard data, make sure you segment it from every other system you have, otherwise it's not just this one system that you need to worry about.

> Also, key rotation/management are NOT required, but it is ONE WAY to satisfy 3.4 through 3.6.

Key management is always required if you use data encryption. Alternatives to encryption are truncation (only storing at most the first 6 and last 4 characters of the PAN), hashing with salt and tokenization. A truncated or tokenized PAN is no longer considered CHD, so the PCI DSS will not apply. If using hashing or encryption the PCI requirements still apply.

> But you stated you wished to store the cards for use again without taking them again, so that's the whole thing but never the CVC/CID codes (the 3 digits on the back).

The (typically) 16-digit credit card number (PAN) can be stored but must always be protected with the methods mentioned above, also if the cardholder name, card expiry date or service code are stored together with the PAN, they must also be protected. Track1 or track2 data (magnetic stripe or chip), CVV/CVC/CVID code and PIN/PIN block can never be stored after authorization, even protected.
Rich RumbleSecurity Samurai
Top Expert 2006

Commented:
There are other ways, compensating controls allow for great variance as long as the end result is securing the data, again we are audited year after year, and no rotation is/was in place due to our compensating controls which happen to be more convoluted and harder then just doing proper rotation, but our data is layered inside many obstacles that allow us to pass with ease. It's all semantics... and off topic...
Call around and see if there are companies that can handle your CC data for you, PayPal for example if you want to do internet transactions, the users are foist on to paypal instead of you. If your looking at physical machines, Point of Sale makers should have something to help you where again they host the service and your terminal is merely where they hand you a card. They probably offer a service that remembers the customers for you and allows you to do what your looking to do. I say call around, growing it yourself is likely to cost much more.
-rich

Author

Commented:
We are keeping about 50 card numbers right now (including multiple numbers issued to buyers employed by our local county government!) And we are keeping the CVC/CID numbers too. It's also nothing unusual to receive a fax or email from a customer that includes their card number and CVC number. I'm told the customers simply want the convenience of being able to say "just put it on my credit card - you have the number". If we're not supposed to store the CVC/CID numbers, we normallly can't charge the card anyway, so perhaps we're going at this from the wrong direction. Maybe we're being a little too accomodating after all and need to push some of this back on our customers?
Rich RumbleSecurity Samurai
Top Expert 2006

Commented:
I'd say so yes... again you can have PayPal, Google-Checkout, Verisign and many more handle your "shopping cart" or what ever. You will have to pay for such a service, but it likely offsets the investment of doing it yourself. Or if not looking for an online offering, there are POS client software that again connects to some PCI compliant vendor and they keep the records of the transactions and customers database.
QuickBooks/Intuit has some service like that: http://quickbooks.intuit.com/product/accounting_software/retail_pos_solutions/accept_credit_cards.jsp
-rich
VISA maintains a list of PCI certified payment service providers: http://usa.visa.com/download/merchants/cisp-list-of-pcidss-compliant-service-providers.pdf

I would strongly recommend going the way richrumble suggests and outsourcing the payment processing. As long as you're storing the card verification codes you will not be PCI compliant and your acquirer may even fine or penalize you.
Rich RumbleSecurity Samurai
Top Expert 2006
Commented:

Author

Commented:
Thank you folks. I'll delve into this a little deeper starting with our current merchant services provider.