PCI Council Changes Its Audio Recording Policy, Again

Written by Evan Schuman
February 18th, 2010

The PCI Council, in an attempt to show that it can be flexible and truly is listening to industry feedback, is now on the third version of its controversial policy on audio recordings since the beginning of the year (which is fairly impressive, given that it’s only mid-February). On Wednesday (Feb. 17), the Council backed off some of its stricter requirements that all sensitive payment data on digital recordings must not be retained.

Saying that it was “a result of additional market feedback,” the Council ruled that the sensitive payment date on the digital recordings could be retained if the retailer can prove that the data in question can’t be queried. “The Council is now saying that call centers can keep this data—even if digital—so long as they protect it per PCI. That is big,” said Walter Conway, a 403 Labs QSA who is also StorefrontBacktalk’s PCI columnist.

The original policy was strongly criticized by some retailers, who considered the new rules unworkable. (The reader comments on our first story on this issue and even more comments on our second story detail the concern specifics.)

The key change—it could be argued the only material change—is the addition of the phrase “if that data can be queried.” The full sentence now reads: “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.”

But how are retailers supposed to interpret “if that data can be queried”? Does it mean “can be easily” or “can be cost-effectively”? Or should it be interpreted to mean, “If someone wanted to spend $2 billion and had an army of audio and computer specialists working on their tapes for two months, could they access this information? And what if they had tools six months from now that do not exist today?”

By putting the onus on retailers to prove that a piece of information can’t be accessed electronically, the Council may be neither advancing the cause of security nor keeping retailers happy.

Conway has his own scenarios. “What will they need to do to make sure their records ‘cannot be data mined’? Will this mean encryption? Maybe. Will it mean keeping it offline? Possibly. Restricting access? Plan on it. Can you isolate them behind a firewall? Again, possibly. In any event, your call center needs to look at its particular situation both for PCI compliance and to keep your organization out of the headlines.”

Conway added a more ominous thought: “While the FAQ change is good news for call centers, is it good news for cardholder data security in general? Will track data be next to get this more lenient treatment?”

Not so sure I agree that this is good news for call centers. But any hint that PCI is listening and is willing to make changes—even really tiny changes—as a result of that listening can’t be bad.


One Comment | Read PCI Council Changes Its Audio Recording Policy, Again

  1. Barak Engel Says:

    When one reads the PCI standard, it quickly becomes painfully obvious that this sort of scenario wasn’t really considered during development. Significant portions of PCI simply do not seem to make sense in this context. For example, investing in technology that ensures that card numbers are not emailed in clear text seems pointless; while it is an important control in an environment that deals with transactions and has sales audit and loss prevention functions, it is not really applicable in
    our case. Similarly, developing an enterprise user awareness program around the importance of protecting credit card numbers appears somewhat onerous in an environment where credit cards aren’t actually being used. There are many other such examples.

    But because the system records voice samples, and because consumers may speak their card number, our service provider had to become PCI-compliant. But what to do with those voice files? When we were examining the environment, the main question to us seemed to revolve around whether those files needed to be encrypted – whether, in fact, sections 3.3 – 3.6 of PCI, some of the most challenging to implement properly, were even applicable.

    “What?” I hear you say. How could we even question the need for one of the foundations of the PCI standard? Actually, the concern became apparent almost immediately. Remember that the purpose of PCI, just like any other good data protection standard, is to minimize the risk of compromise. Consider the following:

    First of all, card numbers do not actually appear textually in these files. While the newly revised version 1.1 of PCI clarifies much around the issue of what constitutes cardholder data, sound files appear to fall in a gray area. Yes, they are digital. But there is no direct representation of the card number within the file. Instead, there is a manifestation of the card number through a voice sample. In other words, the sample must be “heard” (and interpreted correctly) rather than “seen” in order to discover the number.

    The interpretation element brings us to our second point. Analyzing the file is difficult, since the files are stored using a proprietary format, and since the system itself is highly proprietary, it would require reverse engineering of the voice recognition engine to be able to automatically extract information out of the voice files. In other words, for a hacker to be able to extract information from these files using any method other than listening to them would require rebuilding a voice recognition platform similar to the one being examined, from scratch. Not an easy task. Not only that, but even the simple task of listening to them would require at least figuring out their format and how they are stored.

    We further noted that there is no special indication of cardholder data. Within the files, there is no specific indication of where cardholder data starts or ends. Moreover, the files contain fragments of multiple conversations. It, therefore, would require not just listening to the samples, but figuring out which parts of the conversation might actually
    indicate a card number, then find the pieces relating to expiration date and first and last name, and then to figure out which elements combine to form a single conversation. To do that, our hacker would require an army of listeners who would devoutly write down all these various pieces of information, then try to guess which of those pieces may together comprise
    of a single transaction. To top it off, the system never records its own voice prompts, and thus the recorded voice samples include only the consumer’s spoken words, or only one side of the conversation.

    Also, cardholder data appears to be spread very thinly. Because the system records many conversations, the vast majority of which contain no cardholder data, it is very difficult to extract useful information from the samples at an acceptable rate. In other words, if you need to listen to several hours
    of tape in order to have a decent hope of finding a single “live” card number, you may as well look for an easier target. This is especially true since the overall volume of the data is large, since these are voice samples. High quality ones, in very large amounts. That takes a lot of space. Unlike a database that stores text efficiently, these voice files
    take a tremendous amount of space to store very little textual information, easily three orders of magnitude bigger than a simple text record.

    After considering all of the above, we reached the conclusion that these files did not represent a significant risk factor, and recommended that they do not require application of sections 3.3-3.6 of PCI, namely encryption.

    Yet one wonders. Would a VISA auditor figure differently? After all, one could claim that because the files represent a digital storage medium, and because they do contain cardholder data in an indirect fashion, that they must be fully protected according to all PCI requirements. Taken literally, the standard appears to suggest that this is true, even if it makes little practical sense.

    And that’s where the PCI standard stumbles with regards to some service providers. The current standard appears to make no allowance for reduced risk. With the recent release of version 1.1 of PCI, however, it seems that the compensating controls mechanism has been clarified enough to possibly allow for such disparities. Then again, compensating controls generally refer to controls actively placed for the purpose of compensating for the lack of other controls. In our case, the controls are passively inherent in the nature of the files themselves. The answer, it seems, is not clear.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.