"It's easy: we encrypt the PAN in our call recordings." Really?
1. You can't store sensitive authentication data in call recordings (for contact centres - the 3- or 4-digit CV2 security checksums).
2. If you store PANs, you have to encrypt them.
The PCI SSC released a very readable guide about card payments, call recordings and contact centers.
This is not rocket science, it's not news, and by now should be embedded as common practice inside every contact center in the world. PCI DSS has been around for more than a decade, and the telephony payments guide linked above is now 4 years old. That's a lot of time to make things compliant.
conversation I hear from a contact center executive fairly regularly goes
something like this:
"We encrypt the PAN in our call recordings, so everything is AOK for PCI DSS."
(I'm assuming here that for some reason you don't take CV2 over the phone.)
My response to the contact center executive typically breaks their assertion down into 2 distinct threads:
1. Why do you think encryption is the easy answer? And
2. Why do you feel the need to keep PANs in a call recording in the first place?
I'll consider each in turn. One in this article, the other separately.
Why do you think encryption is the easy answer?
line with the PCI SSC's guidance for contact centers, calls containing PAN must
be encrypted. One key element (see what I did there?) of a good encryption
policy is to rotate the encryption keys regularly.
I still see new articles on the web saying that for card data, encryption keys need rotating annually. However, as Branden Williams and Anton Chuvakin write in their book "PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance",
"PCI DSS 2.0 gave us some reprieve on key rotation and PCI DSS 3.0 honors that change. Requirement 3.6.4 states that keys should be rotated once they have "reached the end of their cryptoperiod (e.g., after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines." This formerly was an annual requirement to rotate all keys used for the encryption of in-scope data. Expect some challenges with your assessor here."
phrasing. What is a sensible cryptoperiod (great word, by the way) for call
recordings? What are industry best practices here? What do the phrases
"application vendor" or "key owner" mean in the context of
I think we can cut to the chase, by considering both extremes of a hypothetical policy which may be in place at a hypothetical contact center:
1. Rotate keys any time a significant member of the business leaves, OR
2. Never rotate keys
I don't think you'd find any security professional who thought that never rotating keys was a good idea, so I'm scratching that one off the list.
Equally, I don't think many/any QSAs would say (for call recordings specifically) that a merchant should rotate keys when somebody like a call center supervisor left the business. It's just not practical. Call centers have really high turnover, and supervisors don't have practical access to the keys anyway (their playback software will have a login, but this acts as a surrogate for the keys).
So we're left with a mid-ground. Something like (drum-roll please) "rotate keys annually".
But what does it mean to "rotate keys" for call recordings? It means a whole world of pain. This sort of pain:
Potential re-encryption of data.
This means decrypting all existing call recordings, and re-encrypting them with
a new key. Consider how long that will take. You may have years of recordings,
totaling hundreds of gigabytes, or terabytes. The sheer processing time
required to decrypt and re-encrypt this archive is immense, and very costly.
2. Then you need to securely destroy the historic 'old' recordings.
3. Then securely destroy the old keys.
4. During this process, you will need to ensure that the 'new' recordings have the same path and filename as the 'old' ones, or you will need to update your playback software database to point at the new location.
5. You will also need to ensure that during the re-encryption process (which could take weeks), recordings are still available for playback. Otherwise your contact center supervisors and trainers will not be able to continue with their work during this period.
You and your QSA may decide that re-keying all that data isn't worth it. Rather,
that you will switch to encrypting all new calls with a new key (so-called
're-keying'), leaving the old calls as-is.
2. Now we have an 'old' key (in fact numerous old keys, as we need to keep them as new keys are introduced). Maintaining a secure archive of these old keys incurs a significant overhead (ensuring mappings between keys and data, and creation of a key recovery policy being just two focal points).
3. This system needs to take into account a scenario where a key rotation is performed due to a suspected compromise/weakening of the key, in which case a re-key of all affected data would be required. (See above.)
Maintaining master/derived keys
1. Your call recording system may have a master and derived key system, where a derived key is used to decrypt and play files. In this case you need to rotate the derived keys. See above.Note that all of the cases above are predicated on these assumptions:
- Your call recording system has the functionality to rotate keys (and by no means is this the case for all call recording manufacturers)
- Your company has the specialist skills needed to achieve this
- Your company has the resources free to achieve this
- You schedule and remember to do it
- It's financially viable for you to achieve key rotation. (Some of the high-end call recording manufacturers will sell you a key management system, so the 'pain' wording I used above rapidly becomes 'financial pain')
Finally, there is one stark reality overriding the entire encryption theme. Anybody in your business with the ability to:
- listen to calls also has the ability to listen to card data, even if you rotate
- keys regularly. The rotation of keys only protects data from external attack,
- where it's assumed that the criminal can obtain the encrypted recordings, but
- not the playback engine (which contains or has access to the keys).
So I can see no good reason why you should keep PANs, at all, in call recordings.
Have I missed something? Do you think you NEED to keep the PAN? Please let me know. Every day, as they say, is a school day!
Imagine getting a burglar alarm fitted to your home. The company does a great…
Can you remember what you were doing a decade ago? A lot can happen in 10 years.