The SQLAndy Rules for Storing Credit Card Numbers

Posted on by SQLAndy

I’ll try to write more about these over the next couple months, but I wanted to write down a quick reference for those that have to deal with storing credit card numbers. These rules cover the basics – the full topic of protecting card data is easily a book or two. These are my rules, when in doubt consult with your compliance team for final guidance.

  1. Don’t Store Them! PCI compliance is complex and expensive. Getting hacked and dealing with the consequences is more complex and more expensive. Offload the problem to a vendor.
  2. Encrypt The Card Number. If you insist on storing credit card numbers they must be encrypted at rest and you have to document a key management plan that will make your head hurt. Remember this applies to more than just databases – it’s batch processing and voice recordings too. No home grown XOR stuff either, you need big dog encryption.
  3. Do NOT Store Track Data, CVV, CVV2, or PIN. Store any of these and you are automatically “non-compliant” as far as PCI goes. Beyond that, you’re taking a risk that cannot be justified when a breach occurs.
  4. Tokenize Card Numbers. Tokens “don’t count” as long as the tokenization method used is sound. Tokens let you do things like process cancellations without needing the ‘real’ card number.  Tokens do not need to be encrypted.
  5. You Can Store Some Things. You can store first six/last four characters of the card number. You can store the expiration date and the card holder name. None of those require encryption. Don’t store it if you don’t need it.
  6. Log All Access. If someone stores OR retrieves a card number you need to know who, why, when, where, what, and how. If you use tokens, do the same for the tokenize/de-tokenize calls. Logs are incredibly important. They allow you to monitor and potentially detect hackers, and they are your best chance of determining the scope of a breach when it happens. Don’t skimp on this. You need 90 days online and the ability to get the past 12 months in a relatively short time.
  7. NULL When Done. As soon as you know you won’t need the card number, null it out or replace with some type of non-reversible artifact (xxxxxxxx-1234). PCI doesn’t require this. Common sense does.
  8. Never Use Live Cards In Development. Never. Even if you’re using encryption never land valid card numbers in any type of development/non-prod/non-PCI environment. That means no direct backup prod/restore to dev type operations, you have to change/erase those card numbers before it lands on disk in dev.
  9. Mind Your Tools. Profiler, third party monitoring tools, SSIS packages, they can all potentially capture and store card data as part of normal and seemingly routine activities. All the same rules apply to that data store too.

2 thoughts on “The SQLAndy Rules for Storing Credit Card Numbers”

  1. Andy, what about fraud detection systems. Years ago I learned that by analyzing the repetitive use of certain credit card numbers for returns allows retailers to detect fraud. Using a hash in these cases makes the results questionable at best. Encryption in this case is really the only option. You can’t ‘get rid of it as soon as you’re done’ because these schemes often go on for years, and that extensive history is critical to the analysis.

    Like

    1. Allen, tokens aren’t true hashes and that changes things some. It depends on how you use/build the system, but you can definitely do it so that you can uniquely tie a token to a single card number and you can do so that if they use the card number again you can map it to the same token. So you could still analyze the tokens to look for unusual behavior and then de-tokenize those that matched to get the card number and other details to initiate an investigation and/or freeze the card. That’s on the client side of things.

      On the bank/processor side (the one that actually settles the transactions for your business) they will definitely be doing fraud detection and you’re right, ultimately they have to be storing the card number somewhere, even if they are giving you back a token. That means encryption and all the other controls, plus some, since they are subject to additional PCI requirements because of the role they play in the PCI system.

      PCI gives you some flexibility. If you have a valid business justification or a legal requirement you can retain the data. Having more data doesn’t – in my view – increase the risk of data loss if it’s all part of the same system. It does increase the damage and cost if a breach occurs. I’ll write some about that topic soon.

      Hope that answers your question Allen, and appreciate you reading the post!

      Like

Comments are closed.