[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:

[admin]

[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:

• One-way hashes based on strong cryptography
• Truncation
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures

The MINIMUM account information that must be rendered unreadable is the PAN.

Notes:

• If for some reason, a company is unable render the PAN unreadable, refer to Appendix B: Compensating Controls.
• "Strong cryptography" is defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms.

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:

• One-way hashes based on strong cryptography
• Truncation
• Index tokens and pads, with the pads being securely stored
• Strong cryptography, with associated key-management processes and procedures

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.

[NickPope]

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

[Roger Nebel]

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.

[EmmaJenkinsVeritape]

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.

[pcipc]

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

[EmmaJenkinsVeritape]

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.

[EmmaJenkinsVeritape]

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-...on-18-feb-2010, where you can also request the white paper titled: 'PCI SSC update on call recording and call centres'.

Thanks,

Emma

[EmmaJenkinsVeritape]

(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/veri...ording-system/

Thanks, Emma

[andyp]

Hi

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???

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.

Thanks

[EmmaJenkinsVeritape]

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/busines...e_payments.pdf

Regards,

Emma.