[PCI DSS 1.x] 3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digita

[READ-ONLY] Archives [RETIRED] PCI DSS v.1.x Questions and Answers Protect Cardholder Data
1

[PCI-DSS] 3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:

[ul]
[li]One-way hashes based on strong cryptography[/li][li]Truncation[/li][li]Index tokens and pads (pads must be securely stored)[/li][li]Strong cryptography with associated key-management processes and procedures[/li][/ul]
The MINIMUM account information that must be rendered unreadable is the PAN.

Notes:

[ul]
[li]If for some reason, a company is unable render the PAN unreadable, refer to Appendix B: Compensating Controls.[/li][li]“Strong cryptography” is defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms.[/li][/ul]
3.4.a Obtain and examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable). Verify that the PAN is rendered unreadable using one of the following methods:

[ul]
[li] One-way hashes based on strong cryptography[/li][li] Truncation[/li][li] Index tokens and pads, with the pads being securely stored[/li][li] Strong cryptography, with associated key-management processes and procedures[/li][/ul]
3.4.b Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable (that is, not stored in plain-text).
3.4.c Examine a sample of removable media (for example, back-up tapes) to confirm that the PAN is rendered unreadable.
3.4.d Examine a sample of audit logs to confirm that the PAN is sanitized or removed from the logs.

2

Voice recordings which may include PAN

Does this rule apply to voice recording taken at a call centre that sometimes takes credit / debit card payments by phone and records all calls? As it is not easy to identify the recordings which may contain a PAN is it necessary to encrypt all recorded calls?

Nick

3

Excellent question

You could argue that this is not data in the normal sense. It’s a recording that happens to be digitized and happens to contain sensitive card holder information. Encryption would be fine but perhaps not practical. I’d probably be willing to accept protection equal to paper records with the same information - physical controls and limited access by authorized personnel. We have a client with an Interactive Voice Response (IVR) system with similar issues - it translates tones into numbers and then transmits that information for approval. Clearly protection must be afforded. Good luck.

4

PCI DSS and recorded telephone calls

NickPope,

PCI DSS requirement 3.4 does apply to recorded audio data, as does section 3.2: do not store sensitive authentication data (CVV, CCV) at all, anywhere, even if it is encrypted.

For a guide to PCI DSS and recording telephone calls, go to www.veritape.com and check the compliance/PCI DSS sections.

Veritape will help you automatically ‘bleep’ or ‘blank’ sensitive data stored in a call, so that it simply doesn’t appear in the recordings. Problem solved.

Feel free to email me for more info, too.

Emma.

5

Scanning for PAN storage is now part of a QSA onsite review

Hi all,

My organsation just completed it’s annual PCI onsite review with our QSA.

I thought it would be of interest in advising that the QSA’s are being instructed in their PCI refresher training to ensure PAN storage is clearly covered in detail during a PCI review.

In simple terms, this meant that for this year’s audit, we also had to use a Card Number Scanning application to find PAN storage on our desktops and servers. Interestingly we also had to scan our out-of-scope servers/desktops to prove these were actually out of scope.

Additionally the QSA took from us dumps of log files and databases and scanned these for cards as well to verify our apps and systems were no inadvertantly dumping cards in the clear.

We used an application called Card Recon from www.groundlabs.com (we got a chance to communicate with the Chief Architect there and found him very helpful and worth mentioning here)

To be honest it revealed things within our environment that we had not previously known about so overall it was a good exercize to go through although it added additional time to our preperation process.

We also found the QSA’s are being required to take a wider variety of samples from more hosts. This meant our QSA wanted screenshots, file samples etc from a broader list of hosts.

If you are undergoing an onsite review soon take our recent experience and be ready for this potential angle to be looked at in more detail this time round.

Happy to reply to answer further questions on this if clarification is needed.

Cheers,
Steve

6

Updated PCI SSC FAQ on call center audio recordings

Just a note that last Friday the PCI SSC changed the wording of their FAQ on call recordings to substantially clarify it.

Veritape’s interpretation is:

  • only if a contact center uses cassette tapes (analog recording) can they store CVV/CVC data in the calls
  • digital calls must not contain CVV/CVC data at all, even if encrypted.

If you are able to log in to the PCI’s Talisma server (you’ll know what that means if you can), then here is the new text.

If you can’t log in, then we’ve repeated the text on PCI DSS and call recording here

Emma.

7

Another PCI SSC update to the call recording FAQ

Hi,

With the recent changes in the PCI’s FAQ on call recording in contact centres, Veritape has written a white paper for companies seeking to understand the ramifications for them.

The FAQ in question is: ‘Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of PCI DSS?’

Having clarified the wording in January, it looked as if the PCI SSC had finally established a clear definition of what constitutes PCI compliance in call recording. However, less than a month later, the wording was revised again, leaving companies who record telephone conversations and handle sensitive payment card data potentially confused.

If you’re interested in reading a little more, please do so here: http://www.veritape.com/2010/02/pci-dss-compliant-call-recording-in-call-centres-latest-changes-to-faq-by-pci-ssc-on-18-feb-2010 , where you can also request the white paper titled: ‘PCI SSC update on call recording and call centres’.

Thanks,

Emma

8

A new method for making any call recorder PCI DSS compliant

(Disclaimer: I work for Veritape. We provide PCI compliant call recording systems to contact centres.)

As an update to the above discussion, you may be interested to know that we have just launched Veritape CallGuard - a generic ‘bolt-on’ which brings full PCI DSS compliance to any existing call recording system. Customers keep their existing telephony, call recorder, CRM systems, payment processes and (critically) payment provider. Nothing changes in a customer’s critical IT and telephony systems, and PCI compliance for call recording is achieved incredibly quickly.

Veritape CallGuard also dramatically reduces the potential for internal data theft, since customers never tell their card details to a contact centre agent, and the agent never sees the card details on screen.

For more information, please see our blog post announcing the launch, here: http://www.veritape.com/2010/04/veritape-callguard-brings-pci-dss-compliance-to-any-call-recording-system/

Thanks, Emma

9

[FONT=Verdana][SIZE=2][FONT=Verdana]Hi[/FONT][/SIZE][/FONT]
[FONT=Verdana][SIZE=2][FONT=Verdana][/FONT][/SIZE][/FONT]
[FONT=Verdana][SIZE=2][FONT=Verdana]Can anyone clarify what this means by ‘if that data can be queried’? We do voice recording and record the entire call when we take payments but we cannot query cvc numbers???[/FONT][/SIZE][/FONT]
[FONT=Verdana][SIZE=2][FONT=Verdana][/FONT][/SIZE][/FONT]
[FONT=Verdana][SIZE=2][FONT=Verdana]It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.[/FONT][/SIZE][/FONT]
[FONT=Verdana][SIZE=2][FONT=Verdana][/FONT][/SIZE][/FONT]
[FONT=Verdana][SIZE=2][FONT=Verdana]Thanks [/FONT][/SIZE][/FONT]

10

Hi Andy,

There is a really good white paper from Barclaycard which may help to clarify some of the points in the PCI FAQ:
http://www.barclaycard.co.uk/business/documents/pdfs/processing_telephone_payments.pdf

Regards,

Emma.

11

Protect cardholder name and expiration date

Hi,

I have a question connected to a footnote written on the page 5 of the PCI DSS Requirements and Security Assessment Procedures, v1.2.1. It concerns the protection/encryption of cardholder name and expiration date.

Cardholder Name (1) Storage Permitted - Yes Protection Required - Yes (1) Expiration Date (1) Storage Permitted - Yes Protection Required - Yes (1) (1) These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of
the cardholder data environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data
security) may require specific protection of this data, or proper disclosure of a company’s practices if consumer-related personal data is being collected during
the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.

Our application allows user to store credit cards with number and expiration date. Then this cards can be deleted and used during the regular process.
Currently there is one table which have different columns for the card number and other column for the expiration date. The card number is encrypted.

So my question what the word conjunction means in the requirement. Does it also cover our case. If we encrypt the date it will be very hard to make some mass DB updates - for example deleting all expired cards.
Also in the same DB we have the real user first name and last name - which often is the same as cardholder name. We currently do not encrypt the use real name as we have search by this name and also we sort the results over this fields. So in respect to the above quotation from the PCI DSS should we also need to encrypt the first/last name?

In short my question what ‘conjunction’ means?

Thank you in advance.

Best regards,
George

12

So, if store the full PAN (encrypted!) then you must also encrypt (or truncate or otherwise obfuscate) the Card Holder’s name and the card expiration date if you also store those. So conjunction means the literal plain English meaning of connected. If the PAN is there connected with the Card Holder’s name and expiration (by a table, by a view, a linked list pointer, through a query, or in any other way) then that’s in conjunction with. It does not matter if the name and expiration are in different tables, different data bases, or even on different servers - what matters is that they are stored in conjunction with and accessible in the same environment.

Now later, if you securely delete the full PAN then in theory you would not longer be required by PCI DSS to protect the name and expiration. However, you may well have to protect them under various State statutes and by your own privacy policy under FTC rules.

13

Verify provider of Internet tools

Hello Steve

I have looked at Global labs and their product looks interesting but the security issue with free software and collecting credit cards is obvious.

How did you make sure the app wasn’t collecting your PAN data and communicating it to another party without your knowledge?

Peaceye

14

Hi all,

This is the description of data stored in a MySQL table:

  • Hashed PAN using a SHA1 algorythm
  • Cardholder name in full text
  • Expiration date in full text

On this page http://selfservice.talisma.com/article.aspx?article=8718&p=81

“If the hashing result is transferred and stored within a separate environment, the hashed data in that separate environment would no longer be considered cardholder data and the system(s) storing the hashed data would be out of scope of PCI DSS.”

On this page http://selfservice.talisma.com/article.aspx?article=5417&p=81

"The table illustrates that, if the cardholder name, expiration date, or other cardholder data is recorded in conjunction with the PAN, even if the PAN is rendered unreadable, these additional cardholder data elements are still required to be “protected”. "

As a result of this two statements, in your opinion, does that mean that my table is in the PCI scope ?

Thank you very much !

15

one-way hash function: slow down, the solution?

[FONT=Arial][SIZE=2]Hi,[/SIZE][/FONT]
[FONT=Arial][SIZE=2]I’d like to fucus on[/SIZE][/FONT]
3.4.a Obtain and examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (if applicable). Verify that the PAN is rendered unreadable using one of the following methods:

[ul]
[li]One-way hashes based on strong cryptography[/li][/ul]
[FONT=Arial][SIZE=2]It seems that our QSA does not understand very well the challenge that isbehing the hash-protected PAN.[/SIZE][/FONT]

[FONT=Arial][SIZE=2] [FONT=Arial]Here is the whole story.[/FONT]
[FONT=Arial]We are a merchant and even a level 1 merchant.[/FONT]
[FONT=Arial]In order to be more easily compliant with PCI-DSS we decided to separate flows : the operation itself (value of the buy, elements of the article bought, etc) which doesn’t fall under regulatory conditions and PAN.[/FONT]
[FONT=Arial]Moreover, technically, a query on an operation is heavier than a query on a PAN. That’s another reason to separate storage.[/FONT]
[FONT=Arial]Like every merchant we have customer requests and protestations.[/FONT]
[FONT=Arial]When a customer calls us for it comes with its PAN and not a ticket or an invoice id.[/FONT]
[FONT=Arial]So, we need to reconciliate PAN and the content of the operation.[/FONT]
[FONT=Arial]As we have many requests we have many people in the customer request branch. [/FONT]
[FONT=Arial]It’s not sane to interrogate a server in the PCI-DSS scope to found an unique id (in the case of indexation) and then interrogate the operations database with the index found to retrieve the whole operation.[/FONT]

[FONT=Arial]That’s where the one-way hash idea comes: using the hash as a unique and permanent index (as PAN are shorter than hash the uniqueness is proved).[/FONT]
[FONT=Arial]But, of course, as the database that contains the hashes is less secured than the one that contains PAN we have to found a way to avoid mass cracking.[/FONT]
[FONT=Arial]And with a PAN that contains only 15 digits (the 16th is computed from the previous 15) with a mean entropy of 10^-22 (0.04 by digit - 10 possibilities amongst 256 ^15) that’s easy to try and match every possibilities with a rainbow table.[/FONT]

[FONT=Arial]The first idea is to use a salted hash with a fixed salt in order to complexify (to improve the entropy) the operation of finding the PAN by try and match. Say: with a salt of 4 digits the number of possibilities are improved y a factor of 3.10^14! [/FONT]
[FONT=Arial]Compare this to the 10^9 possibilities for a given BIN.[/FONT]
[FONT=Arial]But, in this case, you have to keep the salt secret! As secret as a private key in ansymmetric algorithm.[/FONT]
[FONT=Arial]It’s rather difficult.[/FONT]

[FONT=Arial]The second idea is to use a salted hash but, this time, with a variable salt.[/FONT]
[FONT=Arial]This always in order to avoid rainbow table (a cracker would then need to compute a rainbow table for each hashed PAN: inconceivable) and, of course, to avoid to keep the salt secret.[/FONT]
[FONT=Arial]But, in this case we return to a case with a low entropy (as the salt is known, a cracker has only 10^[/FONT][FONT=Arial][SIZE=2][FONT=Arial]9[/FONT][/SIZE][/FONT][FONT=Arial] tries at max to accomplish for a given BIN).[/FONT]

[FONT=Arial]The next idea is therefore to slow down the process of computing the hash based on the fact that a hash operation achieved by a customer center agent doesn’t need to have a microsecond time of response whereas a cracker needs to have this type of time of response if he wants to try every combination in order to achieve the cracking in a reasonable period of time (a few days not thousands of years).[/FONT]

[FONT=Arial]Let’s take an example.[/FONT]
[FONT=Arial]Let’s consider the following algorithm which is named SHA-1 salted hash.[/FONT]
[FONT=Arial] f(pan) = sha1(pan + salt) + salt[/FONT]
[FONT=Arial]The salt is a pseudo-alea computed for each new pan.[/FONT]
[FONT=Arial]The salt is contained in the return in order to be able to compute the hash again.[/FONT]
[FONT=Arial]Such a iteration takes somewhat 0,1 µs on a modern personal computer. That is to say: a modern personal computer can perform 10 millions of these iterations per second.[/FONT]
[FONT=Arial]When computation is distributed such an algorithm can be executed 1 billion times per second.[/FONT]
[FONT=Arial]If the cracker focuses himself on a particular BIN (the 6 first digits) he has only 1 billion of tries at maximum to execute to find the other correct 9 (15 - 6 of BIN) digits.[/FONT]
[FONT=Arial]As it would take only 1 second per PAN and thus, a database of 1 million hashed PAN can be wholefully retrieved in only a few days.[/FONT]

[FONT=Arial]As I said the agent of the customer center doesn’t need to compute a hash in only 0.1 µs. 1 second is enough for him: having someone on the phone is well longer than 1 second.[/FONT]
[FONT=Arial]And the new transformation function is:
[/FONT]
[FONT=Arial] f(pan) = 1,000,000 . sha1(pan + salt) + salt[/FONT]
[FONT=Arial]Such an iteration takes now somewhat 0,1 s to be computed. That remains invisible to the agent.[/FONT]
[FONT=Arial]But, for the cracker it’s another story. [/FONT]
[FONT=Arial]Retrieving a single PAN would take now 1,000,000 times more time at maximum ! [/FONT]
[FONT=Arial]Retrieving only one PAN would then take him at maximum 12 days and the whole database: 12,000,000 days.[/FONT]

[FONT=Arial]The benefits of the slow down are several.[/FONT]
[FONT=Arial]You do not need to further protect the hashed database: if it is stolen the loss of data will be kept minimal.[/FONT]
[FONT=Arial]You can duplicate it (if you have several customer centers) without taking heavy security constaints.[/FONT]
[FONT=Arial]Nothing has to be kept secret: neither the salt neither the algorithm.[/FONT]

[FONT=Arial]So, what do you think, you, experts about slow down?[/FONT]

Thank you to read me.

[FONT=Arial]db
[/FONT]
[/SIZE][/FONT]

16

vPayment Scoping for PCI?

Are card numbers issued as vPayment cards (see http://corp.americanexpress.com/gcs/payments/vpayment.aspx ) in scope for PCI?

vPayment cards are branded cards that are valid for a limit time for a limit amount and the liability rests solely with the company to which they are issued, not an individual. I’d been told several years ago by a QSA that vPayment cards are not in scope since an individual is not liable, but I wanted to confirm that’s still the case and see if there’s any formal doc from the PCI Council stating such.

Thank you.

17

Enquiry on 3.4

From my understanding with PCI security standards under point number 3.4 Render PAN unreadable anywhere it is stored, I am clear that I am suppose to encrypt PAN when it is stored in a database on a PCI DSS Compliant Server.

However, due to the nature of our services, we can only perform a manual transaction for the user upon confirmation from the supplier.

Take into consideration the following exmaple:
User A submits their Credit Card info on our site upon selecting their desire service. This will enable our system to generate an email to the supplier asking their availability on the specific service. Normally the supplier will take around at most 1 day to get reply back to our system.

So in the meantime when the supplier has yet to reply, we understand that we can store the encrypted PAN on our database. Upon confirmation from the supplier, we will then conduct a manual transaction on our end and confirm the payment and service to the user and supplier. What we have in mind is:

  1. Pull out the encrypted information on our end
  2. Decrypt it and perform the transaction
  3. Remove the information on our database upon completion of transaction

Also, is there any rules that we have to follow on conducting a manual transaction?

I would like to know if that is in line with the PCI DSS Compliance, and if not, can we have suggestions or alternative to conduct the above mentioned transaction?

18

Hello,

This seems to be a compliant process.

[ul]
[li]You must have a written Cardholder Data Retention and Protection Policy[/li][li]Be sure to remove the PAN after the transaction and automatically after a definied period.[/li][li]Do not store the CVV2 after the authorization[/li][li]Do not store the PAN in trace or debug files.[/li][li]Enforce a compliant encryption keys management.[/li][li]…[/li][/ul]

Best regards, Mark
PCI Initiative

19

Hello,

This process is compliant.

You should also ensure:

[ul]
[li]A written Cardholder Data Retention and Protection Policy.
[/li][li]An automatic process that delete PAN from the database after the self-defined retention period.
[/li][li]Ensure that clear-text PAN are not stored elsewhere (debug files, traces, logs…)
[/li][li]CVV2 are not stored after the transaction
[/li][li]Encryption keys are encrypted and stored separately.
[/li][/ul]

Mark.
PCI Initiative