PCI Requirement 3 states, “Protect stored cardholder data.” We’ve discussed encryption, truncation, masking, and hashing – all methods that can be used to protect cardholder data. We’ve talked about dual control, split knowledge, rendering data unreadable, key-custodians, PAN, sensitive authentication data – all elements that need to be understood in order to fully protect and store cardholder data. But it’s not enough just to learn and talk about these things; all policies, procedures, and standards must be implemented in order to comply with PCI Requirement 3 and to appropriately store cardholder data.

At the end of each of the PCI DSS v3.2 Requirements, we have what we like to call a “capstone.” At the end of Requirement 3, we have PCI Requirement 3.7. It states, “Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.” Requirement 3.7 is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and procedures need to be known and in use by all relevant parties. Your personnel must be living out what the policies, procedures, and standards require of them. It is a requirement of this framework that the affected parties use the policies and procedures as a way of managing your organization’s assets. It is not sufficient that you generate documentation just for the sake of the audit.

With this requirement, we come to the capstone for Requirement 3, which was the protection of cardholder data at rest. Requirement 3.7 requires that you have and maintain policies, procedures, and standards. These policies, procedures, and standards need to actually be in use; it’s not enough just to have them documented. You actually need to be living out what they require you to do from an organizational perspective, and that staff is knowledgeable of them. From an assessment perspective, we’re going to be looking at your policies and procedures and interviewing staff to make sure that they are subject to these policies and procedures, that they understand them, and that they’re actually living out and practicing and doing those things that they’re required to do. We’re effectively making sure that they’re known to all effected parties.

Someone in your organization needs to be responsible for managing the encryption of your environment and accept the importance of this role. This is why PCI Requirement 3.6.8 states, “Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.”

Key custodians are one of the most important jobs within your organization. They’re responsible for creating encryption keys, altering keys, recovering keys, rotating keys, distributing keys, maintaining keys, and so much more. They are managing every aspect of the encryption of your environment. Key custodians have the keys to your kingdom.

By having key custodians sign a formal document stating that they understand and accept their responsibilities, there is a better chance for them to commit to their role. Your key custodians must understand the gravity of the job they’ve taken, and assessors need to see some type of acknowledgement of that. If key custodians do not perform their job correctly or securely, this affects your entire organization because it could lead to vulnerabilities and breaches.

Somebody needs to be truly responsible for managing the encryption of your environment. The individuals we typically identify as your key-custodians. These individuals need to sign a document – this signature can be electronic or it can be in writing – but effectively what we’re needing is some acknowledgment by these individuals that they truly understand the gravity of the job they’ve taken, and that they understand all of the policies and procedures and are good with it. The purpose and intent behind this is understanding that these individuals really have the keys to your kingdom. Their job, in my professional opinion, is one of the most important jobs in your environment. If they do not do their job well, or do not do it correctly or securely, that could effectively lead to the compromise of your environment. We’ve all seen what breaches in the past have done to organizations.

From an assessment perspective, the assessor is going to be working with your HR department to identify who are those individuals responsible for the key management. We’re going to be asking for some artifact where they have read and understand their responsibilities as key-custodians in your environment.

Your organization must have the appropriate controls in place to prevent unauthorized key substitution. PCI Requirement 3.6.7 requires, “Prevention of unauthorized substitution of cryptographic keys.”

If your organization does not have policies, procedures, and standards documenting how your encryption solution does not accept substitution keys from unauthorized sources, you are giving malicious individuals an opportunity to decrypt your data. Assessors will examine your procedures to ensure that they outline a specific process to prevent unauthorized key substitution. The responsible personnel should also be interviewed to ensure they know and implement this process.

Do your due diligence to create strong keys and protect the unauthorized substitution of cryptographic keys.

Within your encryption program, part of your key management program is doing your due diligence around creating a strong key (wherever you’re storing it), preventing individuals from getting unauthorized access to that, and rotating your key on a periodic basis that you’ve defined as your cryptoperiod. When we get to 3.6.7, we want to make sure that you have a process in place to prevent unauthorized key substitution. The reason for this is, let’s say I’m Hacker Joe and you have really great encryption processes and programs, but if I am able to implement my own key into your environment and encrypt the data with my key, when I get access to that data, I can surely decrypt it.

It’s required that you have controls in place to prevent the unauthorized substitution of cryptographic keys. From an assessment perspective, we’re going to be once again looking at policies, procedures, and standards around this. We’re going to be looking at how you’ve actually implemented these controls, whether this be access controls or by any other means that you’re doing this. Understand that simply compiling the encryption keys into the source code does not necessarily mean that you’ve met this requirement. It might be a plethora of things. Protect the unauthorized substitution of your encryption keys.

PCI Requirement 3.6.6 is one requirement that both assessors and clients struggle to understand. PCI Requirement 3.6.6 states, “If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.”

What is split knowledge?

The PCI DSS explains split knowledge as, “Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of the original cryptographic key.”

What is dual control?

The PCI DSS defines dual control as, “Dual control requires two or more people to perform a function, and no single person can access or use the authentication materials of another.”

Why use both?

Although PCI Requirement 3.6.6 confuses many assessors and clients, both split knowledge and dual control must be used to comply with this requirement. The PCI DSS explains, “Split knowledge and dual control of keys are used to eliminate the possibility of one person having access to the whole key. This control is applicable for manual key-management operations, or where key management is not implemented by the encryption product.”

If you’re using a clear text key management program in order to create your encryption keys, it’s required that you use split knowledge and dual control. This is one requirement that many assessors have gotten wrong for many years, including myself. This is one requirement that we see a lot of clients struggle to understand. Taking an encryption key and splitting it in half (giving half to one person and half to another), is not split knowledge and dual control. It might be dual control, but it’s not split knowledge. When we look at the definition of split knowledge and dual control, dual control means that it takes more than one individual to create this key rotation ceremony. When we look at split knowledge, it says that when we create the key, no one individual has any knowledge of the resulting key. Where you take these two key halves and one person gets one half and another person gets the other half, that one individual only knows what their half of that key is.

If you are developing or using a clear text key management program, what we recommend that you do is have some XOR process. You have Key Custodian A and Key Custodian B that has, if you’re going to create an 128 bit key, each individual has 128 bits of a key seed. Those two individuals come together and input their key into their application or their key seed into the application. The application then goes through a process of XOR those two values together, then outputs the encryption key that nobody knows. If this is a struggle for you or you need a better understanding of what clear text management program looks like, give me a call or talk to your assessor – they’ll be more than happy to help you understand what a clear text management program really looks like.

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.