I had an interesting exchange on Google+ the other day regarding whether or not encrypted data is in scope for PCI compliance. In the end it was suggested that I write a blog entry regarding this topic as they said how to treat encryption has not been articulated very clearly by the PCI SSC. I would argue that the rules regarding encryption and scope have been very clearly articulated in the PCI SSC’s FAQ #1086. However, based on the conversation we had, it was obvious that this is not the case. So here are the rules as practiced by most QSAs.
The key to how to interpret whether or not encrypted cardholder data is in-scope is in the FAQ. Encrypted cardholder data (stored or transmitted) being out of scope is based on whether or not that data meets the following definition.
“It is possible that encrypted data may potentially be out of scope for a particular entity if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data.”
The important phrase in the aforementioned definition is “if, and only if.” The only way encrypted cardholder data (CHD) is out of scope is if the entity being assessed for PCI compliance cannot decrypt the encrypted CHD. This is a very important concept that gets constantly misinterpreted by QSAs and their clients. However, it is up to the QSA to confirm that the organization being assessed cannot decrypt the encrypted CHD and to document the procedures conducted to prove that fact.
With that as background, let us look at storing and transmitting encrypted data and how they can be out of scope and what that means. As you will see, out of scope can mean different things depending on the implementation of encryption.
Stored Cardholder Data
Under requirement 3.4, one of the methods recommended for the storing of the primary account number (PAN) is:
“Strong cryptography with associated key-management processes and procedures“
One of the ways organizations accomplish this is through a hardware security module (HSM) that manages the cryptographic key process. The HSM generates the keys, manages the keys and provides an application programming interface (API) for code to access the keys. Since the HSM is a “black box” a lot of organizations point to that fact as the reason their encryption is out of scope.
There is an additional condition to the encryption out of scope definition that usually gets forgotten. This is what allows for the scope of the cardholder data environment (CDE) to be reduced.
“Systems performing encryption and/or decryption of cardholder data, and any systems performing key management functions, are always in scope for PCI DSS. Scope reduction for encrypted data may only be considered when that data is isolated from these processes.”
As such, since the organization using the HSM technically has access to the cryptographic keys through the HSM’s APIs, the encryption is in-scope.
Where stored encrypted CHD is out of scope is when a third party controls the encryption keys. This most often occurs with tokenization. Under a tokenization scheme, the CHD is sent to a third party who then securely stores the CHD and returns a token that links the CHD at the third party to the token stored by the merchant. If the merchant needs to make any subsequent charges to the account, the merchant sends the stored token to the third party and the third party substitutes the stored CHD for the token and the transaction is completed. But since the merchant does not have access to the token creation process, the token is out of scope because it is no longer considered CHD.
Transmitted Cardholder Data
Secure transmission of CHD can be accomplished through a number of methods. The most common of these methods is secure sockets layer (SSL) or transport layer security (TLS). In either case, if the organization being assessed has one of the endpoints in the SSL/TLS encryption, then the SSL/TLS process is in scope. This is obviously most common in the conduct of e-Commerce when the merchant’s Web site has an SSL/TLS certificate for securing the transmission of the CHD to pay for the customer’s purchases from the Web site.
However we are also seeing SSL/TLS used more and more as the encryption method of choice for point-to-point encryption (P2PE) solutions. Again, if either of the endpoints in the P2PE environment are under the control of the organization being assessed, then the endpoint or endpoints are in-scope for the PCI assessment.
One way we do see to get everything but the merchant’s endpoint out of scope is terminals that are encrypted from the terminal to the processor and the processor controls the encryption keys for the P2PE. This is most often used in the gas station environment where the pump card reader does P2PE to the processor using derived unique key per transaction (DUKPT) or similar techniques to create an encrypted connection.
That said, what happens to the users and devices in between the two encryption endpoints on an encrypted communication link? They are out of scope as long as they do not have the ability to decrypt the data stream. This is another misunderstood interpretation of the FAQ. While some personnel inside an organization have access to encryption keys, if a user or device does not have access to the encryption keys or the communication endpoints, they too are out of scope. This is how an SSL/TLS/IPsec connection can be used for isolating the transmission of CHD from the rest of the network and satisfy network segmentation.
Another issue that comes up with managed service providers (MSP) is when the MSP has access to firewalls or routers that are encryption endpoints. Even if the MSP does not have access to the encryption keys, they do have access to the encryption endpoint(s) and cleartext CHD, therefore their personnel and relevant device management practices are in-scope for PCI compliance.
The bottom line in all of this is; if your organization has the ability to decrypt either the stored CHD or transmissions of CHD, then you are in-scope for PCI compliance.
And as a reminder to everyone, just because something is out of scope it does not mean that it does not need to be assessed. It is always necessary for a certain amount of testing procedures to be conducted to determine that the item is out of scope.
Hopefully we can now all operate from the same set of rules.