The SQLAndy Rules for Storing Credit Card Numbers

Andy Warren, 2013-07-26

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.

Rate

Share

Share

Rate

Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.

Robert Davis

2009-02-23

1,567 reads

Networking – Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I’d like to talk about social networking. We’ll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let…

Andy Warren

2009-02-17

1,530 reads

Speaking at Community Events – More Thoughts

Last week I posted Speaking at Community Events – Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I’ve got a few more thoughts on the topic this week, and I look forward to your comments.

Andy Warren

2009-02-13

360 reads