This was one of those weeks where you see something and all you can do is shake your head and wonder what some organizations think when it comes to PCI. What added insult to injury in this case was that the organization arguing over PCI compliance is the manufacturer of card terminals, also known as point of interaction (POI). It shocked me that such an organization was so clueless about PCI as a whole when you would think it is their business to know. But to add insult to injury, my client’s transaction processor and acquiring bank are also apparently clueless.
As background, I am working on a client’s Report On Compliance (ROC). This client has almost completed with their roll out of an end-to-end encryption (E2EE) solution at all of their 4,000+ retail locations. This E2EE solution will take all but the POI at those retail locations out of scope for PCI compliance. That is the good news.
But if there is good news, you know there must be bad news. In reviewing their documentation of this E2EE solution, I discovered that the POI vendor is providing management and updates to the POI through a terminal management system (TMS). Since this TMS solution/service connects directly to my client’s cardholder data environment (CDE), I naturally asked the client for a copy of the vendor’s Attestation Of Compliance (AOC) for the TMS solution/service.
I thought those worthless PCI Certificates of Compliance took the cake. Then, BAM! I got the following message forwarded to me by my client from the POI vendor. I have redacted all of the potential information that could identify the relevant parties and the TMS solution/service.
“Please see the follow up note below that you can send to your QSA for review and feedback:
- TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk. Since [vendor solution] does not have any card holder data at all, it falls outside of PCI requirements. [Vendor solution] is merchant configuration and estate management tool only and as such, no payment card information passes through it, or directed to it. In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.
- [Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website. Transactions are encrypted in hardware using the [encryption solution] keys which again [vendor solution] has no knowledge. Transaction information can only be decrypted by [processor] the processor. [Vendor solution] has no knowledge of this encrypted information being sent directly from the [vendor] to the processor.
- The beauty and simplicity of [vendor solution] semi-integrated terminal application is that is has all transaction data go directly to the Processor ([processor]) and no customer data is directed to the POS or [vendor solution] which makes the POS out of PCI Scope by the very nature of no card holder data in their environment.
- [Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application. Any questions regarding the certification should be directed to [acquiring bank] or a [processor] representative.
Let us know if your QSA has any further questions and we can also schedule a concall with all parties to address any concerns on [vendor solution] TMS and PCI.”
The first thing that wound me up is that this vendor is a business partner of my client’s transaction processor. The processor is also a business partner of my client’s acquiring bank. Those two organizations put forth this vendor to my client as being able to provide POI compatible to the processor’s E2EE and tokenization solution. Obviously from this vendor’s response, these two well-known institutions did nothing in the way of due diligence to ensure that this vendor and its services were PCI compliant.
The second thing that totally irritated me is that there is no excuse for this vendor’s uneducated response. Granted, this vendor is new to the US market, but they have been supplying POI to other merchants all over other parts of the world. Which then starts to make you wonder just how lame are the banks, processors, card brands and other QSAs that they have not been called on the carpet about this before. But that is a topic for another post and a good reason why the FTC is investigating the PCI compliance industry.
So let me take apart this vendor’s response.
“TMS systems in our industry do not require any type of PCI certification since PCI is concerned about card holder information that would be at risk.”
Wrong! On page 10 of the PCI DSS the first paragraph under ‘Scope of PCI DSS Requirements’ clearly defines what is in scope for PCI compliance.
“The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.”
The operative phrase the TMS solution/service falls under is “connected to”. The TMS solution/service directly connects to my client’s CDE. That solution/service may not process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD), but it is directly connected to my client’s CDE. As a result, according to the above definition, the TMS solution/service is definitely in scope for PCI compliance.
“[Vendor] Hardware and [vendor solution] Software are all PCI PTS compliant and certified and listed on the PCI website.”
PTS certification is a card brand requirement, not a PCI DSS requirement. Nowhere in the PCI DSS does it require that a PTS certified POI be used so I really do not care about this statement as it has nothing to do with my PCI DSS assessment activities. If PTS were a PCI DSS requirement, then all of those people using Square and the like would be non-compliant.
“In addition, no secure keys are stored on [vendor solution] so transaction data cannot be decrypted with anything on [vendor solution] or POS.”
“Transaction information can only be decrypted by [processor] the processor.”
True, your TMS solution/service does not have the encryption keys. But the firmware delivered by the TMS solution/service does have access. (Unless you are the first POI vendor I have ever encountered that spent the huge amount of money required to truly create a hardware-only encryption solution.) Given the low retail price and discounting of your POI you gave my client, I very seriously doubt that is the case. So the firmware that your TMS solution/service delivers is what is doing the encryption and therefore has access to the encryption keys. So while the TMS solution/service does not have the keys, it could be used to deliver rogue firmware that could obtain them.
Then there is the firmware delivery itself by your TMS solution. If someone hacks your TMS environment, how easy would it be for them to have it deliver a rogue version of your firmware? Since my client has no AOC, I have no idea if your security measures surrounding your TMS solution are adequate to prevent such an attack.
“[Client] has a merchant certification with [processor] for the [encryption solution] with our [vendor solution] terminal application.”
Such a statement ranks up there with those previously mentioned worthless PCI Certificates of Compliance. Any QSA is required to obtain an AOC for the TMS solution/service to ensure that it is PCI compliant or the solution/service must be assessed as part of the merchant’s PCI assessment.
PCI DSS requirements under 12.8 are very clear as to everything a merchant needs to be able to provide to their QSA regarding third party PCI compliance. Primarily of which is that AOC for your TMS solution/service among other items of evidence.
So I have a conference call with my client’s bank to discuss this situation. I pushed back very hard when they told me that my client needs to do a compensating control for their business partner’s incompetence. I even got an “atta boy” from the bank for identifying to them that they have a PCI compliance and potential security issue. But I could not make the bank budge on the compensating control so I am off to get that written.
The lesson to be learned from this post is that nothing can be taken for granted when doing a PCI assessment even when you transaction processor and bank are involved. A lot of people and QSAs would assume that a POI vendor would know better and that their bank and transaction processor had vetted the POI vendor. Therefore, why do I have to worry about this vendor? However as I have pointed out, you can never take anything for granted even when it involves organizations that you would think would know better.
This is just one way of many that could result in an organization being breached. The TMS solution/service is a gateway directly to the merchant’s CDE. Yet there has been no PCI assessment of that solution/service to ensure that it is PCI compliant and the risk it could be subverted has been minimized.
Thank goodness it is the weekend. Oh, wait. This weekend’s project is my income taxes. Looks like I will be cranky all weekend as well.
