Audio files containing credit card data
August 20th, 2007 by admin Posted in Encryption, PCI DSS
I thought normal spam was bad, but now we get PCI specific spam! Companies actually try posting press releases into the comment sections of various posts. Sheesh.
One person emailed asking about how to address audio recordings that could contain credit card data. This is a very good question! (Although the salutation they used, “Dear PCI Gods”, we are not but appreciate the gesture.)
If you have done several PCI audits you will catch on to some of the nuances with implementing the standard. There are several locations where cardholder data could reside but to business functions and it rather difficult to remove:
- Customer service audio recordings (”for training purposes”)
- Fax servers (digital images)
- VRU/IVR (voice response unit / integrated voice response)
According to requirement 3.4 this data should be rendered unreadable. But how do you justify to your CFO the purchase of a $100k hardware encryption device to protect these audio recordings that just may contain a credit card number?
The answer is that you don’t. PCI mandates in section 12.1 that you take a risk based approach towards compliance. If you have one data store containing audio recordings and another in an Oracle relational database you know which is more susceptible to attack. (Answer: the database)
An attacker would probably rather kill themselves than listen to hours and hours of customer service audio recordings on the off chance they will get a few credit card numbers. As a result many companies will leverage compensating controls or disk based encryption to protect these data stores.
Update: This is not to say that you can ignore requirement 3.4. You must achieve the requirement, but this can be done via a number of different methods (i.e. disk based encryption or compensating controls.) The intent here is that the way one addresses the requirement may be different depending on the data being secured.
If a database needs encryption it could use an HSM; individual applications could code encryption into the application; and audio files could use compensating controls or other methods of “rendering unreadable”.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
9 Responses to “Audio files containing credit card data”
By Brian on Aug 21, 2007
Not sure if I agree 100%. In our most recent QSA training, PCICo specifically called out voice recordings and said they had to be protected per 3.4. But I agree, it is a very low risk.
By Michael Dahn on Aug 21, 2007
@Brian, thank you for the comment, I’ve updated the post to clarify that requirements cannot be ignored based on risk by they can be met via compensating controls or other methods of “rendering unreadable”.
By CW on Aug 21, 2007
How about some specific examples of acceptable compensating controls for voice recordings?
By Michael Dahn on Aug 22, 2007
@CW, as with all compensating controls it depends on the environment, risk area, and many other factors.
I would pay for consulting advice and confirm such decisions with the merchant’s acquirer.
By DAG on Aug 24, 2007
How you approach this would be different if you are looking at bulk data versus data that could be easily mined. Again, that risk based approach.
By Michael Dahn on Aug 24, 2007
@DAG, actually, this is a hot topic right now but many more details than are posted here.
So here’s one dilemma: You want to take a risk based approach, but you also do not want to permit bulk storage of data.
I think you put it nicely when saying that you have to evaluate the risk of something being easily mined. Also, examine if the storage of data is a one-off or something that is always recorded with every call.
What is a low risk today could be a high risk tomorrow. This is why compensating controls must be re-evaluated annually.
By Michael Dahn on Mar 6, 2008
PCI SSC responds: http://treasuryinstitute.org/blog/index.php?itemid=102
By Jim Lippard on Jul 11, 2008
What about voice transmissions in general? Does PCI require that every phone company count as a service provider that is being entrusted with cardholder information on the grounds that cardholder information is being transmitted unencrypted over voice connections?
By Emma Jenkins on Jul 21, 2009
(Responding to Michael’s posting “What is a low risk today could be a high risk tomorrow. This is why compensating controls must be re-evaluated annually.”)
Yes, I would agree with that. Since the preceeding comments in this post were made back in 2007/8, things have moved on, of course. One thing which might be of interest is way Veritape does things (disclaimer: I work for Veritape).
Basically, we automatically strip any senstive authentication data from a call, at the point of recording. As a result, none of it is ever stored. While this certainly meets today’s PCI DSS requirements, it also ties nicely with Michael’s comment about future risks. If you haven’t got the CVV stored at all, the future risk doesn’t rise.
In case you haven’t heard of the way Veritape achieves the automated blanking of credit card details, then there is some more info here: http://www.veritape.com/our-product/compliance/pci-dss-call-recording/
At Veritape, we don’t believe that encryption fulfils either the technical requirements or intent of the DSS. I would be interested in your thoughts on the differences between complete blanking and encryption.
Emma Jenkins
Veritape