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.
PCI Guru 
I want to just clarify your mention of “organization”. If the organization has many systems that are in-scope and does control the keys and key management, are *any* devices in that organization that transmit or store encrypted CHD also in-scope? For example, encrypted CHD may pass through some switches and routers in transit, but those routers and switches have no knowledge of the keys or key methods. Similarly there could be a storage device that never has the keys or knowledge of the encryption methods. The only way the data could be accessed and decrypted from these areas would be if there were rogue employees who violate policy or rogue software that eluded standard control processes. But it sounds like these devices are still in scope??
Routers, switches, firewalls that do not have access to keys are not in scope. However endpoints that do have access to the keys are always in scope such as with a server or a storage device. Even though an individual user does not have access to encryption keys, someone does have access to any instance where encrypted data is stored or processed. The rule of thumb to follow is that if you have the encryption keys, all devices that store, process or are transmission endpoints for SAD/CHD are always in scope for PCI compliance.
Thank you. Just to split some hairs…we are assuming here that the routers, switches and firewalls are not providing any security services to the CDE, *and* that they are not directly connected to any CDE component (I think). But can’t a user within the organization, who does have access to the keys, get a packet capture from one of those pass-through devices and then decrypt (violating policy) the CHD/SAD? (I am happy for this to be below the level of concern that would drag those devices in-scope) And what if there is a server that is also acting as a pass-through for encrypted CHD and which has no access to keys? Can we also say it is out-of-scope? And if an end-point storage device for encrypted CHD has no access to the keys, are we saying it is still in scope because some user in the organization could violate policy, extract the data from the storage device and decrypt it?
In theory, the user could decrypt if they got all of the packets necessary and could identify the encrypted data in the stream. But that is not a standard procedures and would not drag those devices into scope because they do not contain the keys, only the user. Only the endpoints that are expected to encrypt/decrypt are in scope when encryption is involved. If everything else cannot encrypt/decrypt, it is out of scope. It is a very simple concept.
Just a heads up that you may wish to note in the article that they have, since your original post in 2013, updated the content in FAQ 1086, as it no longer contains the first quoted paragraph. I’m not disputing your points, I’m just saying they seem to have altered the FAQ for whatever reason.
My bad, I see they turned that first paragraph into the final bullet point in the list:
* “Encrypted cardholder data that is accessible to an entity that also has access to the decryption key”
So I think they just did some formatting but haven’t changed the core statements behind the FAQ.
Apologies, you can delete both my comments.
Hi PCI Guru
I know this is an old article but still remains relevant today. I am assisting a client (merchant) going through self assessment questionaire B-IP (the SAQ was identified by their acquiring bank). However, we need a QSA to sign off on section 3c and now they are throwing us a curve ball.
The merchant have hundreds of branches whereby their only channel is EDC terminals (card present). Their EDC terminal has a USB connection to their POS system for transaction (no card data) information. But their EDC terminals also uses their branch internal network for authorisation, i.e transmit encrypted CHD via private MPLS and IPVPN to the HQ and from the HQ sends out the EDC traffic to the acquirer bank using private network. All their EDC terminals are segmented properly from other systems in the branch. When it hits the HQ, the HQ immediately identifies this EDC traffic via its VLAN and routes it to the acquiring bank infra and out of their hands. EDC traffic never travels into their corporate network. The entire EDC traffic is encrypted from the POI onwards and never decrypted in merchant environment.
The thing is, the QSA states the whole infrastructure of branches and HQ comes in scope and needs to be tested, ASV scanned (not possible due to private cloud) and segment PT.
If the merchant has no means of decrypting the EDC traffic throughout its journey from EDC -> Branch router -> Private Cloud -> HQ router -> Acquiring bank router; shouldn’t this entire flow be out of scope? Because the EDC terminals is not owned or managed by the merchant. The EDC (POI) encrypts the information, the merchant has no key management. The only time this gets decrypted is in the acquirer’s environment. So in this case, aren’t all the infra from branch and HQ not in scope. As in, do we consider this as Card Data Environment or not, from merchant’s perspective?
The problem we are having now is that potentially, segment PT will be in the THOUSANDS. They have close to 300 branches, and each branch has around 15 -20 VLAN segments, with only one VLAN segment carrying encrypted EDC data for each branch back to HQ. If Segment PT is applicable to all branches, does this mean they need to do Seg PT in over 6,000 different segments?
First, this sounds more like a end-to-end encryption (E2EE) solution than B-IP unless they have both IP connected non-encrypted POI and these EDC devices.
Yes, the network is out of scope if what you claim is true, but …
The QSA must prove that the traffic is encrypted from the EDC through the network and that the merchant has no way to decrypt the traffic.
What I usually do is take Wireshark captures at strategic points on the network as well as a test POS USB capture to ensure that what is represented about the encrypted traffic is accurate. Then the merchant’s acquiring bank needs to concur with the QSAs findings.
Hi,
Thank you for this post. What I don’t understand is that if to read/update the CHD in the third party, one needs just a token, isn’t that a problem? Or that token allows just for overwrite ? but if we store it, at some point it is for reading it, isn’t it?
By definition, tokens are NOT considered cardholder data if they meet the Council’s guidelines documented in the Information Supplement, ‘PCI DSS Tokenization Guidelines’. You really need to read that document before you begin posing questions on the subject of Tokens. Tokens are different from encrypted data, the primary of which is that the token cannot be detokenized by the merchant if the tokenization is performed by a third party.
According to this FAQ: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/How-does-encrypted-cardholder-data-impact-PCI-DSS-scope?q=+&l=en_US&c=PCI_Categories%3APCI_DSS&fs=Search&
The following are each in scope for PCI DSS:
Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions
Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes
Encrypted cardholder data that is present on a system or media that also contains the decryption key
Encrypted cardholder data that is present in the same environment as the decryption key
Encrypted cardholder data that is accessible to an entity that also has access to the decryption key
So my question is if the CHD is encrypted in transit (TLS 1.2) to the CDE, encrypted inside the CDE with a key received over TLS from an HSM isolated from the CHD database, and then encrypted CHD is transmitted over TLS to be stored in the database, is the database in scope and is the encrypted CHD still CHD?
In otherwords, the
The database does not perform encryption and/or decryption of cardholder data, and does not perform key management functions and does not store the encryption keys.
The encrypted CHD stored on the database is isolated from the encryption and decryption and key management processes. HSM does not have access to database server, database server does not have access to HSM.
The encrypted CHD stored on databse is not present on a system or media that also contains the decryption key. The decryption keys are stored in HSM appliance only.
The encrypted CHD stored on database is not present in the same network environment as the decryption key.
The encrypted CHD stored on the database is accessible to the entity that also has access to the decryption key.
However, because the keys are managed by a device under the control/management of the assessee, then it is in scope as part of the assessee’s PCI assessment.
Sigh. I knew you’d respond that way.
Hi, you may skip my last post on February 24, 2016 at 2:26 PM.
My new question is which SAQ do I have to use for Micros TansactionVault tokenized CDE (tokenization starts at POS) mixed with other apps in the same VLAN? SAQ-C or SAQ-D? I can collect evidence to show that no other apps/processes can touch the tokens and tokenization process.
Starts at the POS or starts at the swipe/dip of the card? HUGE difference.
If it is tokenizing at the swipe/dip, what evidence do you have to prove that beyond the vendor’s claims? If you can prove that the solution is truly tokenizing at the swipe/dip, then you should be able to document all of that and present that evidence to get your acquiring bank to agree to scope reduction to the requirements in SAQ P2PE-HW for that solution.
Really appreciate your feedback.
Thanks for the great description. I do have one question. If the CHD is encrypted by a PCI validated card machine (terminal) before it gets passed through to the point of sale machine (PC), does the PC itself still fall within scope? If so, why, and does the network segment that the PC sits on fall within scope also? Bear in mind that there is no way for a user of the PC to unencrypt the data.
Thanks.
As long as only the endpoints CAN decrypt the cardholder data (CHD) and the devices in between that transmit the CHD CANNOT decrypt the information, then the devices in between are out of scope. That said, you must be able to provide evidence/documentation that this is the case in order for those devices in between to be declared out of scope.
Hi,
Thanks for that. It sounds like the PC will be out of scope then (once verified by the QSA). However, just a thought, if the PC is not maintained (ie patched) properly, is there not a risk of the PC, and then the COM port attached terminal being compromised?
This is where things can get messy. Are you absolutely sure that the encryption occurs at the point or interaction (POI), aka the card terminal? If the POI does not have an Ethernet connection and only a USB connection, then the encryption is likely occurring on the PC, not the terminal. This is how Target got breached. The cardholder data (CHD) was being encrypted on the POS PC and not at the terminal so the attackers could get the CHD out of the PC’s memory. I am not aware of a solution that does encryption at the POI yet still goes through the PC for transmission to the processor.
With encryption at the POI there is an Ethernet connection and a USB connection. The USB connection is for the POS to communicate purchase information (i.e., receipt detail, total cost, advertising, etc.) to the POI as well as to know if the transaction is approved or declined. However, no CHD ever traverses the USB connection.
That said, if the POI does do the encryption at the swipe/dip, then the PC would would be out of scope and would not have to comply with the PCI DSS. While not the best practice, the POS would not have to be patched monthly or whenever the vendor issued updates.
Hi,
Thanks for your comprehensive and extremely helpful responses. I will try to confirm that the Verifone VX820 terminals encrypt at POI before passing only encrypted data to the PC, and that only the endpoint can decrypt also.
Thanks again.
The Verifone Vx820 Duet point of interaction (POI) will be using VeriShield for encryption at the swipe/dip if the POIs are doing encryption.
Thanks. That’s sounds good thing 🙂
Hi there, consider the following scenario: A Client side encryption solution is used where the encrypted Cardholder data passes through the merchants systems and are decrypted at the third-party payment service provider. The merchant does not have any access to the decryption keys. Which SAQ would apply is such a scenario? I am assuming either SAQ A-EP or SAQ D.
Thanks
Your scenario will never exist because the client side cannot be trusted.
However, from the transaction processor side, there are a lot of these sorts of solutions. The merchant’s Web site invokes the processor’s payment page (redirect) which then makes a connection to the customer’s browser. The merchant is entirely out of the payment process. That is what SAQ A is designed. However, if the redirect on the merchant’s page gets changed, it’s the merchant’s responsibility to secure that, so the merchant still needs to do some basic security and monitoring.
Hi again, I probably haven’t described it clearly enough. The form is hosted at the merchants website (Payment page), so no redirect is being used. The cardholder data is encrypted client side (via javascript) using a public key provided by the “transaction processer”. The encrypted cardholder data is then returned to the merchants webserver and forwarded to the “transaction processer” where it is decrypted and the transaction is processed. I hope it makes more sense now.
Date: Sun, 25 Oct 2015 14:52:21 +0000 To: hbrian82@hotmail.com
What you describe is covered by SAQ A-EP. See my post on SAQ A and SAQ A-EP Clarification for an explanation.
@PCIGuru, that was a very clear explanation. I am however confused over the use of the term “Entity.”
Say we have a single organization. This is a very large, multinational corporation, but it is a single organization.
This organization operates three systems: a payment gateway, a service bus and a transactional switch. Both the payment gateway and the transactional switch deal with “plaintext CHD,” so they are in scope of PCI. The service bus however, is used to connect the payment gateway to the transactional switch. That is, the payment gateway sends financial transactions through the service bus, and the service bus routes them to the switch. These financial transactions include CHD.
Would it be possible to leave the service bus out of PCI scope if the CHD is encrypted before being transmitted through it, provided the encryption keys are not accessible to the team managing the service bus?
Thanks for your help again!
It does not matter what my opinion is on your question. This is a question only your acquiring bank(s) and/or the card brands can answer. I think you have a good case for leaving your service bus out of scope, but that is not my decision to make. If you are allowed to keep it out of scope, you will still have to have it assessed to prove that all data remains encrypted through it and that the keys are not available to that team. So do not be surprised when a QSA asks to prove those facts.
hi, how can we find encrypted credit card data while defining the CDE? are there any basic pointer which we should consider while defining CDE?
You will not find encrypted cardholder data because it is encrypted unless you know where it is stored. That is the whole point.
Thanks for the response. However I am still confused, as if I want to define my card holder data environment, and I am not sure where all it is stored. Then how to find encrypted data? Bottom line is we cannot find such data. So merely defining card flow will not help I think.
You need to define dataflow regardless of whether or not the data is encrypted. The reason this needs to be done is so that you can make sure that the cardholder data is never decrypted along the way. I cannot tell you the number of times I have encountered similar situations and when the dataflows are generated, I find that there are one or more points where the data ends up decrypted for whatever reason.
That said, encrypted data typically cannot be identified without file or protocol layouts because it no longer resembles a PAN.
Hi, just wondering with the statement “The standalone IP-connected POI devices are not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate POI devices from other systems);”. If I have an Ingenico ICT 250 and it is connected to my router which also has the likes of an IP camera and Windows 8.1 operating system. Does this mean I cannot select this unless it resides on a VLAN or it is on its own segmented network/
Are you using a P2PE approved solution that was implemented properly? If so, then you should be fine. Otherwise, you will need to VLAN off the Ingenico with ACLs so that any other netowrk segments cannot access it and it can only access your processor via the Internet.
Good post! One question re. scope: What about VMware ESXi hosts with VMs that handle credit cards? The ESXi hosts do not have ability to decrypt the card data.
Are the ESXi hosts in scope?
Yes, the ESXi and any other hypervisor are always in scope. In June 2011, the PCI SSC issued an Information Supplement on virtualization that explains why hypervisors are always in scope.
We are a relatively small company and a Level 4 merchant, however we need to do a SAQ-D. We’ve sliced and diced the network, invested a lot in hardware and monitoring software, but there are still a few areas where we just “aren’t sure” that all our bases are covered. Are you able to recommend any QSAs we could talk to who wouldn’t charge 5+ digits to go over our concerns? The merchant provider’s PCI compliance service just seems to be urging us to sign the thing, but we don’t want to take on that kind of legal potential.
My set up is a FD100 terminal that is connected to my LAN. The FD100 tokenizes and encrypts the card data automatically as the cards are swiped. The LAN is behind a firewall that is connected to the internet. There are other devices on the LAN (but no other device besides the FD100 touches card data–we have a personal computer, IP cameras, etc.) I have no way to decrypt the data from the FD100. I believe I should use SAQ C–sound right? Would the rest of my network be out of scope as well?
SAQ C sounds right, but that final decision needs to be made by your acquiring bank.
Why not B-IP?
The third bullet is the problem.
“The standalone IP-connected POI devices are not connected to any other systems within your environment (this can be achieved via network segmentation to isolate POI devices from other systems);”
The terminals are not the only devices on the network and there was no segmentation implied except that the terminal encrypts its communications. The other devices on the network could be used to breach the terminal.
A PTS POI will only reduce PCI DSS scope if it can be validated that the entity being assessed does not have access to the encryption process or decryption keys. Given that most PTS POIs utilize internal key management and encryption processes, does this mean that all encrypted cardholder data generated by a POI is still in scope? Is there a way for all key management related to the POI to be performed by a third party?
Most POI that are doing encryption have their key management with the processor or at the merchant’s transaction switch. If the processor is injecting the key, then only the POI is in-scope because the merchant does not have access to the key (that would have to be validated). If the merchant’s transaction switch is injecting the key, then the POI and the merchant’s transaction switch are in-scope as well as any connected systems.
Thanks for another insightful post. I’d like to explore the implications further.
A merchant who uses only a dial out card reader termimal can use SAQ-B. But a merchant using only a card reader terminal connected to a local store LAN and then going out over the internet would presumably have to use SAQ-C (although SAQ-C doesn’t really appear to have been designed for this). Taking your comment that ‘SSL/TLS/IPsec connection can be used for isolating the transmission of CHD from the rest of the network and satisfy network segmentation’ then if the card reader is establishing an SSL channel from the reader to the acquirer or payment service provider would you say that the requirements 1 and 2 in SAQ-C would be Not Applicable? i.e. that the only additional requirement in SAQ-C that would apply would be 4.1?
I would concur with your analysis and approach to using SAQ C.
BTW SAQ C was designed for the organization that has brick and mortar locations that have a LAN with POS at the location. The LAN is implemented so that the POS can securely connect to the processor over the Internet. No other remote connectivity to the LAN is allowed.
Yes, it is true the tokenized data is out of scope.
However, the card data had to be originally processed somehow and the process of getting the cardholder data to the processor is still in scope because it is transmitted and, potentially, processed because it does not get tokenized until it is processed. So there are still things that are in scope, it’s just that your applications are not storing cardholder data.
This is the tidbit that seems to get missed by merchants. Merchants hear “out of scope” and stop hearing the rest.