SQL Server 2008 + PCI Compliance? Pertains to PCI, as well as Symmetric keys!

Question

I've never had to deal with PCI compliance before. I've been reading their documentation and it says I need to protect the credit card number, expiration date and the card holder's name. No storage of security codes ever.

In their documentation, it just says protect. Is this saying I need to encrypt these 3 columns in my database? I thought only the number was the data that needed to be encrypted. Either way, I'm fine with.

If I need to encrypt all three columns, do I share one certificate and have 3 symmetric keys, or will I only need 1 of each, with that symmetric key being used on all 3 columns? The reason I ask is in the BoL documentation on encrypting a column, the key is named specifically after the column they are encrypting.

Thanks for all the help!

Answer 1

From the specification: https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

Requirement 3: Protect stored cardholder data

Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails.

I think this strongly suggests that you should

1. not store unless you have to
2. if you have to, store a part if you can
3. if you store anything, encrypt it.

Answer 2

If you store the PAN (card number) then it absolutely must be encrypted.

If you store cardholder name, expiry date, issue number (and they can be linked to the PAN), then they should be encrypted, but (my understanding) is that its not absolutely necessary. PCI-DSS only states that at a minimum the PAN must be encrypted.

The CV2/AVS/CSC code cannot be stored post authorization, and ideally you'd want to prove that it isnt stored at all (eg - only kept in memory whilst performing authorization)

Regarding certificates/keys - you could just use one key for encryption of all card related data. Best practice is to not use keys for multiple purposes, so if you have other (non card related) data that is encrypted, then use a seperate key for that.

The most difficult part is one you havent really mentioned in detail - and thats key management. To meet PCI requirements the key must be stored on a seperate physical box to the database, and you need the ability to change the key at least annually. SQL 2008 supports this with Extensible Key Management (EKM)

All of these points are best discussed with an independant QSA (Qualified Security Assessor) who you will at some point need to involve regardless in order to meet PCI compliance. Your QSA will be able to guide you on questions such as this, and ultimately its his/her advice that you should follow in order to meet compliance.

Its worth mentioning that most people soon realise how much of a burden PCI compliance can be, and look to minimize that burden by using a 3rd party payment gateway. Most payment gateways will allow you to perform authorization/settlement and store the card details on their (already PCI compliant) servers. You then only need store a TokenId that references those payment details should you need to perform further charges/refunds on that card.

Good luck either way!