I can't believe it is only 2 weeks into my job. Already, I have flown interstate to support the Security meetups and also gave short talks to combined audiences of nearly 1,500 about what we are doing in the Cyber community scene.
Cyber is ubiquitous. There is always so much to learn; I found myself constantly acquiring new knowledge every single day. Of course, I realised soon enough that it is even more important to pace oneself in this learning journey. Be purposeful in scheduling time to breathe. To reflect. To ponder upon any key learns. Especially if longevity is in the equation for me to be a credible Cyber Advisor and trusted partner of companies. Especially if I desire to truely understand the different areas of cyber implications and what does it really mean.
So here I am, with part 2 of my thoughts on a different topic today. Before, I had never understood what is all this talk about PCI DSS. It seems to be a painful conversation for some. Yet, in recent days, I have met a number of very passionate advocates about the security in payment industry.
Let me start from the beginning; thou shalt looketh at the origin of PCI DSS.
So, we are all familiar with the different payment card brands that has come to the market. There's actually 5 of them: Visa, MasterCard, JCB, Discover and AMEX.
Everyone had their own way of protecting payment card details. However, the PCI Security Standards Council (PCI SSC) saw a need to come up with a combined standard to reduce payment card data leaks, and to reduce financial liability. Hence, they created a set of global data security standard consisting of steps that follow security best practices.
Now, this is where the Qualified Security Assessors (QSAs) come in. The council needs them to assess companies' compliance with PCI DSS. These QSAs will use validation tools such as the Self-Assessment Questionaire (SAQ) for companies who wants to self-assess their compliance, or the ROC, which is for those who needs to submit a Report on Compliance.
Who needs to be compliant?
Well, essentially the merchants or any entities that store, process, and transmit cardholder data! If you accept/ process payment cards, PCI DSS applies to you.
However, it turns out that it is actually the banks (acquirers) who are responsible for the merchant's compliance. The acquirers decide on the amount of risk they are happy to take and categorises the merchants into 4 different levels according to the number of transactions they made in a year.
Then it doesn't matter isn't it? What's in it for these merchants to ensure they are compliant? And what actually is so bad about credit/ debit card leaks? I was still curious as to what are the exact implications.
Debunking myths.
To the merchants: As long as your customers see your website collecting their payment details, even if it goes directly to the bank, you are responsible. If hackers get into your website, and the details gets channeled to another place other than the intended bank, you are still held responsible. The payment brands may fine the acquiring bank for PCI compliance violations, and your bank will most likely pass this fine to you.
It also depends on the leverage the merchant has with the banks. Let's face it, how many companies out there has a similar big name as APPLE? Most of the merchants will find it hard to compete with the bigger brands and will be at the mercy of the acquirers. There have been cases where the acquirer is able to stop a merchant from doing payment transactions by terminating the relationship. And if you think they were able to change acquirers, it is not that simple. It is a close knitted community - the banks talk to each other. The merchant had to comply in the end if not there was no way they will be able to do any form of business. Penalties are not openly discussed but they can be catastrophic to small businesses.
Other costs include: the reissue of the cards, a credit/ fraud watch (to monitor who else is using the identity of the card), sometimes the transaction fees might be raised to cover the transaction losses, fines from $5K to $100K per month, and not to mention, the biggest cost in this day and age. Reputational damage which will be a severe blow to the customers in terms of security assurance and trust in the credibility of the merchants.
Now let's talk about how a PCI assessment is very different from an audit.
Audit VS. Assessment.
An audit is independent. You need a third party that is unbiased. You can't audit your own work. It also has a bit of an accusatory ring to it - think of all the fingers pointing at you.
An assessment, on the other hand, provides you guidance on how you can correct problem areas. It has a more hopeful tone. The council allows you to correct them; you're told how to go about it, and then the same QSA comes back and check it again before giving a final PCI certified assessment.
Unlike an ISO certification, PCI is not a risk-based standard. ISO allows you to decide your own risks and what you are happy to accept. This is then reviewed every few months or a year; you define what is appropriate. For PCI assessment, you need to make sure that every single thing is compliant. Even if one is missing, it means you are not compliant.
So this is a genuine question that I asked my team: Why would one QSA be different from another? In my previous role, I have interviewed QSAs (already there isn't many in this field as well), so I used to think as long as they have their QSA certifications, they should be pretty outstanding.
But it turns out that there is more to this!
It is about the value add you can get from your QSAs. It is so much more than just satisfying the PCI global security standards. You want to get an insight into the overall security of your company and improve your overall security posture on top of that. Hence, a QSA with an IT Security background (VS. an Audit background) who is also familiar with the industry challenges faced by your company is immensely useful. Also, if they have experience in implementation as well, it's even better as they are able to provide expertise which goes beyond the checklist, e.g. HOW to correct problem areas.
QSA companies themselves are audited and if the quality of their work do not comply with the PCI DSS reporting procedures, they will be listed on the PCI Security Standards Council website. Best to partner with a QSA that has great relationships and credibility with the acquirers already. This is good leverage in itself.
Apparently, in a number of companies, they just send their QSAs to do the initial data gathering and analysis phase. However, when it comes to doing the on-site visits to evaluate the implementation of the security controls, it is a separate group of people who turns up. For consistency and the assurance that you are getting the right specialist in for the piece that you've paid money for, it is best that you engage a QSA that handles the work end to end.
Finally, working with a vendor-agnostic Security consultancy would be best as they would have no incentive to give you any bias recommendation/ encouragement to buy a new security system or products.
And now my pen's ink is dry, and the heart is settled. In the spirit of learning and sharing, I have tried to consolidate all my thoughts and key learns here. I would love to hear from my network and even the QSAs/ PCI DSS specialists if they have additional insights that they can impart here as well. It would also be amazing if I can hear from the merchants/ payment entities their experience on getting themselves PCI DSS certified or any interesting stories that the public can learn from.