Evan Schuman's StorefrontBacktalk

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

1. Barak Engel Says:
   February 19th, 2010 at 2:36 pm

   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.