PCI-DSS and how we messed up the scope

pci-compliance

We have recently concluded an onsite audit for PCI-DSS for a retailer and it has been a great experience to our team.

When we started the PCI project, we were faced with myriad of challenges. The client’s project manager left after a few weeks, and his replacement also left after 2 months. Unable to get any traction, we asked for the client to provide a more stable project resource dedication, which was duly done, only for this ‘stable’ resource to also leave after around 3 months of work. With the turnover of staff so high, the project was like a car unable to start on a cold morning (for those old enough to remember there were such cars back in the 80s you literally had to choke the car to start).

Finally, after a while, the musical chairs stabilized a bit and the client had a steady project team to champion the PCI-DSS project.

By then, so many changes had been done that they asked for a rescope and we rebooted the project.

Now, the scope in any PCI-DSS project is absolute key. If you start wrongly, you will definitely go down the rabbit hole and never come out.

In the beginning, the client described us the situation where credit card was fed into their environment. According to them, the only flow inside their environment was through the credit card terminals connected to their POS systems in their stores. They had more than 40 stores nationwide, so you are talking about a lot of POS systems. Initially, we were quite surprised that credit card would be flowing back into the retailer environment. In normal cases we have encountered, retailers would simply transit credit card information through the credit card terminals to the acquirer and then receive back a transaction ID or approval code, and not need the credit card information. When queried, the client confirmed there was credit card information given back from the acquiring bank so that they could do reconciliation. We were assured that the information would be ‘encrypted’ and would be stored in ‘encrypted’ form. Because of this ‘storage’ of credit card, the client had to undergo a Self Assessment Questionnaire D-Merchant based on the request from their acquiring bank, consisting of over 330++ questions!

Our team assumed the scope had been confirmed, and began the project by asking them to draw out their process flows so we can assist them in scoping down their systems in scope and also work on the asset inventory (a key part of the PCI-DSS program) together. The target was SAQ D-Mer Validation from QSA. And this was where things got a little messy. Because, they insisted, the credit card terminals that were interacting with the cards belonged to the acquiring bank and they had no purview over it, they did not see the need to provide an asset list. Also, they claimed they had more than 40 branches, and it was difficult to provide an asset list to cover all relevant hardware and software across the nation.

The pushback caused the project to once again grind to a halt. Without a scope confirmation, we could not start any PCI implementation for them, in case we overcommit the scope or undercommit the scope – both not desirable of course. The project was being worked out in the management level for a long time, before it was brought up to the director’s level – both us as well as the client’s. We decided to go on the ground to a few of the store locations to really see what was going on.

What we found out surprised everyone. Credit card information indeed never flowed back into the client’s environment!

The so-called ‘encrypted’ credit card information from the bank that supposedly was sent back to the client after the authorization, was in fact, ‘truncated’, not ‘encrypted’. Apparently, the client had thought these were the same thing. In PCI speak, encrypt means to protect credit card details by making the information unreadable with a key. The main reason is that there is a need to ‘de-crypt’ the information back again. Truncation, on the other hand, meant that the card number itself, when sent has already its numbers ‘X’ed out. This is different in a sense that truncated card information is NOT card information because the critical numbers have already been X’ed out, leaving (usually) just first six and last four numbers of the credit card number visible.

Immediately, it was like a light being flipped on.

The team worked hard to optimized the scope by confirming a lot of the other flows and even seeing live transactions take place. At the end of a 2 day onsite scoping assessment, we concluded that this client was eligible for a SAQ B-IP which has only around 80 questions (compared to SAQ D’s 320+). After filtering further and marking some questions as non-applicable, we pared down their compliance questions to only 40.

So, from an effort whereby they were answering 320, we managed to reduce their questions by more than 85%, thus shortening the time for compliance.

The takeaway here, from our experience would be:

  1. All PCI-DSS programs require a stable and strong project team – our delay was mainly caused by the lack of focus and priority to the project.
  2. As assessors or auditors, we are required to check and check again. Our first mistake was to take what was said by the client (and acquiring bank) and used it as a starting baseline for understanding. The key issue here was the understanding of the word ‘encryption’. The client thought this was correctly used, when in fact, their numbers were ‘truncated’ and due to this confusion, the team started chasing the wrong end of the stick.
  3. For PCI-DSS merchant compliance it is essential to explore if the client is eligible for any of the specialized SAQs (A, A-EP, B, B-IP, C, C-VT) before falling back to SAQ D. Because the effort for SAQ D vs the other SAQs is very different.
  4. Nothing beats onsite and live walkthrough of actual processes. Our other mistake in this engagement was to delay the onsite due to the client pushback on documentation. If the documentation scope is not agreed on, the key takeaway here is to take time out and go to the actual site to see the process. A different set of eyeballs might be able to unlock the project obstacle – and in our case, it was essential to have the onsite scoping exercise.

Finally, because of these findings, the compliance is now ongoing and finally we are seeing the light at the end of the tunnel.

If you have any queries on your scope or compliance on PCI-DSS, drop us an email at pcidss@pkfmalaysia.com and we will get back to you ASAP.

Leave a Reply