PCI Requirement 3.6.5 – Replacing Weakened Keys
by Randy Bartels / July 28th, 2017
PCI Requirement 3.6.5 requires, “Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.”
The PCI DSS states, “Keys that are no longer used or needed, or keys that are known or suspected to be compromised, should be revoked and/or destroyed to ensure that the keys can no longer be used. If such keys need to be kept (for example, to support archived, encrypted data) they should be strongly protected.” Any time a key is weakened, it should be replaced. Any time a key is compromised or suspected of being compromised, it should be replaced. If a key custodian leaves the company, the key should be replaced. If protocol wasn’t followed, the key should be replaced. Basically, if there’s ever anything that could possibly impact the security of cardholder data, the integrity of the information, or the encryption, you should replace, rotate, or retire the key.
To comply with PCI Requirement 3.6.5, the PCI DSS states, “The encryption solution should provide for and facilitate a process to replace keys that are due for replacement or that are known to be, or suspected of being, compromised.” As a part of your risk analysis program, we recommend that you also incorporate some type of risk analysis into your key management program. By doing this, you can discover what the risks to your keys are and better protect them. Performing a risk analysis of your key management program could also help you to define and document processes and procedures to protect the data.
If there’s ever a time in your organization that anybody even expects that your encryption keys have been rotated, it’s expected that you rotate the key out. If the key is ever weakened, we expect the keys to be rotated. If the keys are ever compromised, we expect them to be rotated. When we look at the sub-requirements within 3.6, we have a requirement that says it the key has been weakened or compromised, it needs to be rotated. I want to have a conversation around what it is to be compromised versus what it is to be weakened. In a situation where the key has been weakened, it might be that the key custodian has left the company.
In that situation, the key hasn’t been compromised, but it has been weakened. You might have a situation where the protocol, for some reason, has been deprecated. That is a situation where the key is weakened. As part of your risk analysis program, we recommend that you also fold in your key management program and understand what the risks are to your key. You need to define the processes to protect those keys or protect the data that’s been encrypted by those keys, in the event that there’s actually something that comes to fruition. In short, if there’s every something that would possibly impact the security of the cardholder data and the integrity of that information or how it’s encrypted, you’re required to rotate the keys out. As an assessor, we’re going to ask for that documentation and ask to interview those key custodians and those individuals who are involved in that to make sure that they understand that even if the key is suspected of being compromised, that the key is then rotated.
