PKF AvantEdge

Tag: pci compliance (Page 1 of 2)

Why QSAs Matter in your PCI-DSS

April 3, 2024 / / 0 Comments

The questions we usually get asked, aside from why we prefer not to be a QSA (which, although it is fairly dated and need to be revised, have been answered), despite us doing PCI-DSS since 2012 in Malaysia, is why we hardly work with different QSAs in our PCI-DSS projects. Aren’t all QSAs the same? Aren’t all created equal?

Like everything in life, there are basis of variation. We are not here to say which is better, which is worse. It’s not in our culture to constantly provide a barrage of negative statements in regards to other companies and organizations, even with basis — because that’s not how we are wired.

That being said, we do have an internal list of companies (and QSAs) that we would perhaps have some less inclination to. This is due to either working firsthand with them, or mainly seeing some of the results of their work. Quite shocking some of the things we see. Additionally, we have also had clients who had suffered under their so called advisory and have asked us to step in for help.

So to the query on which QSA should you spend the next six months (or more) months with for your PCI Project? Let’s put a few options forward in a more quantifiable manner.

a) Experience

A question we get asked is why we generally don’t just work with local providers or assessors who are closer to home. It’s not because they are worse or better. It’s like comparing cars. They all have their pros and cons – we do not slag organizations off even if we would rather avoid some of them. But one way I would tell customers is, let’s look at experience first.

As of writing, we have 3065 PCI-DSS listed projects based on the Visa Provier List at https://www.visa.com/splisting/searchGrsp.do. The top 10 assessors on this list is as follows:

AssessorProjects
VikingCloud208
Foregenix142
ControlCase 113
SECTEC103
Compliance Control96
Coalfire Systems86
SISA 83
A-LIGN80
CIPHER 71
atsec 71
Total1053

The top 10 assessors make up almost 35% of the projects listed. Those are heavy hitters. Suffice to say a lot of projects remain unlisted – level 2 Service providers, SAQ projects, Merchant projects etc. So actual projects (included non listed) for each assessor is probably a lot higher. To put in context, there are the following numbers of projects for assessors:

ProjectsNumber of Assessors
154
235
325
422
518
613
713
87
910
103

There are 200 Assessors out there with 10 or less projects listed. In defence, some of these are actually the same company under another name, so it’s not like 100% accurate in terms of this overview. So out of 262 assessors in that list that does PCI, 77% of them have 10 or less projects, showing that it’s not that easy to get that number to a 100 or more. Again I will reiterate, quantity doesn’t automatically means it’s better. Some may argue, the more projects you have, the more quality is suffered. That is a good point. And I have experience with some of the overseas QSAs in that smaller project number group that I would gladly give a project and have a beer with. They are really good and extremely passionate about PCI-DSS and I’ve learnt truckloads from them. We are just saying this is one starting indicator you may want to jump from because most service providers start off with this off the bat when they are presenting their services: how many customers ‘trust’ them.

b) Location

This is slightly misleading in a sense that the query we ask is: do we need a QSA who is local? Local here would mean they have an office in the country they are serving the customer in. This argument, while it seems to initial hold some credence, is actually self defeating. And a bit strange, when most organisations now prefer to be known as regional or global, instead of touting themselves as just local players. If they use this as a plus point, then by going to their overseas customers, they are technically disputing the same argument point they are advocating. Most QSAs won’t use this track because they know that a QSA company needs to at the very least operate regionally, or if you want to be focused on a country – then, fine, take USA. The reason why the service provider list does not have a breakdown of all 195 countries (or if you are a Malaysian Minister, then that would be 500 countries) of Earth is that being a QSA is tough work. The breakdown is in regions and the only countries listed there are US and Canada because US makes up almost 35% of the listed projects there.

Think about the last time you dealt with a QSA. Did you have access to that QSA through messages or call? Did you call for a meeting and that QSA came as required? Did that QSA respond quicker? Was that QSA able to reply your queries, technical or otherwise related to your compliance in clear and consistent manner? Did they insist on you paying them more for advisory or delayed your project? Did they upsell more services to you that was unplanned and unknown? Think about the positives and negative experience you had.

Those are more pertinent queries than deciding someone to be ‘local’. That point is actually really moot. Because in almost all projects, the bulk of the work will be handled by a consultant. QSAs by definition should be global or regional anyway. In the economics of being a QSA (explored in another article), being a QSA operating in a single country would probably not be cost sustainable. Especially in a country where the currency is slightly more than the value of a turnip. So the assessor will still have to be flying to other places anyway. Therefore, it doesn’t really matter whether its local, regional or global when it comes to being an assessor, the question is how accessible and communicable they are.

In that sense, we strike a balance – we are local to Malaysia, or any other country that we operate in (we have presence in 150 countries as a global network), and we provide the independent, technical advisory needed to be consultants. We are not QSAs so we don’t need to be pulled all over the place in other PCI projects all over helter-skelter. We are all certified in various certifications and more product certs that I can throw a stone at. We are operational people all with more than a decade of experience so you won’t have a wide-eyed associate with a checklist coming to you. We also have non-IT services as we are also tax advisors, corporate financiers, risk managers, compliance directors – we aren’t just an IT company aiming to push IT services or cybersecurity solutions for you – our DNA is in advisory and consulting.

Enough of blowing our own horn then. Which leads me to item 3:

c) Reference

It’s important to not just look at a list of customers. I have a client who gets annoyed with seeing a presentation with a list of logos without any context of the work. Some may list down large companies or merchants under their so called ‘Customer’ but without any context. You know what? Fine. I can list down all telcos, up to twenty PLCs, more than half a dozen of oil and gas and more banks than I can swing a bat at just because I have given them ‘training’. Come on.

Look past that veneer and look at actual references in the industry. Is there a positive experience? Is there someone out there willing to endorse good will? Are there any bad experiences? Another area I got asked is, if the assessor has been involved in a breach before. This almost needs a new article to explore. Look, we all know PCI doesn’t guarantee non-breach. It’s not a panacea to world hunger. Its more important to note that what is the outcome of the investigation or forensics before we go witch hunting. It’s meaningless to state for instance, the top QSAs would never experience any breaches in their existence. For sure, some of them would need to deal with this one way or another and to see if indeed there was an oversight. If there’s none, then the breach could be down to myriad of reasons outside of PCI-DSS control. Remember – assessors are not operational. They enter an audit in good faith. Witchunting a QSA just because of a breach involvement without context or having the final conclusion is a narrow minded, irresponsible approach to assessing capability (or culpability). If the QSA is truly to blame, wouldn’t they be put in remediation by the Council? There you go.

One thing you will never catch us doing is giving an opinion about certain things that we don’t have the full context on. It’s simply not something we are comfortable at. If we see some issue with a report from other QSAs, even if it looks strange, the reply is always: what is the context of this, and there must be a reason why it was interpreted as such. So that gives us a more balanced view and not just mouth off without understanding. As the proverbs say: “The more talk, the less truth; the wise measure their words. “

d) Cost and Resources

Most PCI projects have the conflicting pull of cost and resources. A QSA with a lot of resources and consultants will be very useful. The last thing you want to see is a QSA not responding and after 3 months rushes you for evidences. Cost still plays a huge role in PCI-DSS and it’s not as if things are getting cheaper. With version 4.0, there is more work for QSAs to do and they likely will pass down some of these costs to the customers. This still remains a very subjective item in this filtering exercise — a QSA charging your liver and kidney for PCI isn’t ideal, but if a QSA comes in with a price that resembles a popsicle in a flea market, I would likely stay away as well. We all know how much effort PCI is. We don’t want a situation where halfway through, the bulk of invisible costs comes pouring in like the army of Mordor, or else things will not be done. If you want to build your house, have most of the materials cost sorted out. If there is a VO, don’t let it cross a threshold of percentage of your initial cost. Having a QSA who understands this and is willing to negotiate is important. Even if the cost is not lowered (because to be fair, QSA work is not trivial), then negotiate for future services, or better payment terms – anything else to meet in the middle.

e) Stamp of Trust

Are there any stamps of trust for QSAs?

No, there isn’t. At least not officially. However, I would like to highlight there is this thing called Global Executive Assessor Roundtable (GEAR) found here: https://www.pcisecuritystandards.org/about_us/press_releases/pci-security-standards-council-announces-2022-2024-global-executive-assessor-roundtable/

There are 28 QSAs in the GEAR currently, with the purpose below:

The Roundtable is an Executive Committee level advisory board comprised of senior executives from PCI SSC assessor companies. The 2022-2024 GEAR consists of 28 organizations, with the Roundtable term running 1 September 2022 – 31 August 2024.

“The Council depends on the input of a wide range of stakeholders to provide PCI SSC with valuable insights,” said PCI SSC Executive Director Lance J. Johnson.” With the release of version 4.0 of our PCI Data Security Standard this year, it is even more important to have active representation from every corner of the globe from an assessor perspective. Assessors are critical in assisting the Council with our effort to improve and evolve payment data security.”

PCI COUNCIL

The QSA we often work with, Controlcase is one of them, and have been reappointed, pointing out that in terms of reference, the Council considers their input as ‘valuable insights’. This is one of the list we look at, especially when requested about QSAs. Are they involved in GEAR?

IN SUMMARY

Like choosing a car, there is really no guarantees actually that your experience will be immaculate when it comes to PCI-DSS considerations. The above are just possible filters you can decide on when it comes to choosing your next QSA partner to embark your journey on. Or you can roll a dice or consult with the gods. Disclaimer of course is that we have not worked with ALL QSAs yet, so this still remains a rudimentary filter when you are thinking of a QSA. Find a QSA that can actually do the hard yards and have proven themselves with Project references and quality, Global Reach and experience, Positive Customer feedback and respect from the industry and finally, seen as an invaluable assistant to the almighty PCI Council themselves. In our personal opinion, it’s a start to look at these metrics and springboard from there. Because anyone can give a nice presentation or dress in a suit or talk negatively about other companies — but what are their numbers, references and contribution to the PCI council?

Drop us an email at pcidss@pkfmalaysia.com to learn more about PCI and other compliances like ISMS or ITSM or SOC!

An Ode to the Invalid Certificate

April 19, 2023 / / 0 Comments

Once upon a time, in a not-so-faraway land of PeaCeEye, merchants, credit card transactions, online payments, payment gateways, POS terminals all lived in harmony. In this land, all citizens carry a trust symbol, held together by validation documents, called the Citizen Badge. However, PeaCeEye is now facing an existential threat. A threat shrouded in the cloak of validation, a false symbol of security and trust – called the Certificate. But, dear reader, beware! For this tale of caution and deception, and the Certificate, much like the elusive unicorn, while tangible, carries a false value – nothing more than a fabrication. A figment of imagination, conjured up by the minds of its idle creators, the Qessays.

You see, in the kingdom of PeaCeEye, there exists a council – a council of wise men and women who determine the rules and regulations that govern this realm. This council, known as the Secret Sorceror Council (SSC), has decreed that only three sacred documents hold the key to validation for the Citizen Badge – the Attestation of Compliance (AoC), the Report on Compliance (RoC), and the Self-Assessment Questionnaires (SAQs). Yet, despite the council’s resolute stance on this matter, a mysterious fourth document continues to emerge from the shadows – the Certificate.

Ah, the Certificate, a work of art crafted by the Qessays. You see, these Qessays were charged by the council to uphold what is truthful and right, and to ensure that all Citizens of PeaCeEye are identifiable by their Citizen Badges – The AoC, Roc and/or the SAQs. However, over the years, some of these noble Qessays have turned to the darkside and the sinister art of producing corrupted documentation, called the 4th deception, or the Certificate as it is now known. These dark Qessays have mastered the art of illusion, conjuring certificates out of thin air to dazzle their customers. They’ve become modern-day alchemists, turning mere paper and ink into a symbol of validation, which, in reality, is as weightless as a feather and as useful as a chocolate teapot. Or a fork and spoon when eating Chapati. It’s a thing of beauty, destined to hang on the walls of businesses, gracing them with its shimmering falsehoods.

But why do these Qessays continue to spin their webs of deception, offering their customers a document that has no merit in the eyes of the SSC? Something that even invalid citizens to PeaCeEye can procure? To unravel this mystery, we must dive into the murky depths of human nature. For, you see, people are drawn to shiny, pretty things, much like moths to a flame. A certificate, with its elegant calligraphy and embossed seal, is a testament to the allure of appearance over substance. It is a tangible representation of validation, regardless of its actual worth.

Moreover, the Certificate serves as a placebo, a sugar pill of sorts, which instills in businesses a false sense of security. It is a talisman that they cling to, convincing themselves that they are protected from the malicious forces of the World beyond PeaCeEye – the World called Cyberattacks. And, in the process, they become blind to the fact that the true power of validation lies in the sacred trio of documents – the AoC, RoC, and SAQs.

Now, one might argue that those who peddle these invalid certificates are merely fulfilling a demand. After all, the customer is always right, and if they desire a shiny piece of paper to adorn their walls, who are we to deny them? But, as the saying goes, “With great power comes great responsibility.” And these Qessays, as the gatekeepers of the citizenship of PeaCeEye, must hold themselves to a higher standard.

By offering these overvalued and useless certificates-that even the SSC had themselves admonished and had announced to the citizens to not place any value to them- these certificates not only betray the trust of customers but also undermine the very foundation of Citizen Badge. They turn the realm of PeaCeEye into a farce, a stage where pretenders masquerade as protectors, and businesses are lulled into a false sense of security. There are even Qessays who are not even involved in the process of validating an SAQ being answered; luring their customers to portals with questionnaires answered by the citizen themselves and then conjuring these certificates that look as if it has been validated by the Qessays, but instead are just self aggrandizing papers that has been only self validated by the person answering their own questions! In other words, the person becomes their own judge and jury and are able to produce a Certificate that looks as if they have been properly validated by a third-party Qessays. Amazing art! An ostentatious object of grandeur and magnificence, yet with all the actual value of a discarded banana peel withering in the Sahara sun.

But, dear reader, do not despair, for there is hope. You see, the truth has a funny way of revealing itself, much like the sun breaking through the clouds after a storm. And, as the truth about the invalidity of these Certificates spreads, businesses will begin to see through the veil of deception, and the demand for these counterfeit documents will wane. Qessays who persist in peddling these worthless certificates will find themselves exposed, their credibility crumbling like a house of cards.

In the meantime, we must not sit idly by, complacent in the face of falsehoods. Instead, we must raise our voices and spread the word, educating businesses on the true path to Citizen validation. We must sing the praises of the AoC, RoC, and SAQs, enlightening those who have been led astray by the allure of the invalid certificate. For it is only through knowledge that we can pierce the veil of deception and lay the mythical beast of the Certificate to rest.

So, let us embark on this crusade together, wielding the sword of truth and the shield of knowledge. As we march forward on this noble journey, let us remember the wise words of the SSC: “Trust, but verify.” Let us tear down the great wall of this Certificate, brick by brick, and replace it with a fortress built on the solid foundation of the council’s sacred trio of documents. And as we watch the last remnants of the Certificate crumble to dust, we will know that we have triumphed over the forces of deception.

We bid farewell to this Certificate, and to welcome a new era of transparency, security, and trust. An era where the mythical beast of the Certificate is relegated to the annals of history, and where the true power of validation is embraced, in all its glorious, council-approved forms. May the sacred trio of documents – the AoC, RoC, and SAQs – guide us on our path to a brighter, more secure future, and may the Certificate forever remain a cautionary tale of the perils of deception and the triumph of truth.*

** The above is written obviously in satire and tongue-in-cheek with absolute no journalistic value nor based on any real world reimagination and solely based on our absolute frustration at the continuous dependence and insistence from acquirers or banks to have our customers produce them ‘certificates’. In addition, some clients even go through self-service portals provided by QSAs and answer SAQ questions on their own, at the end of this process of self answering, a certificate is produced. Granted, the certificates do come with disclaimers in small prints stating that the certificate is actually based on self assessment and even admits that it isn’t recognised by the council.

But in reality, who actually reads the fine print?

In the end, anyone having gone through these ‘compliance’ portals, answering affirmative to everything would be able to procure these certificates and remarkably, some acquirers even accept them as proof of third party audit (which they are clearly NOT). Again, we are not stating that QSAs providing this service is doing anything wrong. There is nothing essentially wrong with certificates on its own, or QSAs providing these certificates as a simple means to show a company has undergone PCI-DSS compliance. But where it becomes a gray area is when there is too much dependence placed on these certificates to the point where even the AoC is rejected and acquirers insist on every company showing them these certificates. In this case, QSAs who are willing to provide so called certificates to companies without having undergone any assessment and only answering questions from the SAQ based on their own knowledge or whim – unless the QSA is willing to go through each question of each customer and validate these through evidence submission and review (the process called audit); then these creation of self signed certificates should be stopped. It’s akin to a banking website issuing a self-signed SSL cert on their own website and tell everyone to trust it. Does this happen in the world of e-commerce? No, it’s absurd. Then why is it different in the world of compliance? Why is this practice still allowed to prosper? How do we stop this practice?

We have been advocating removing certificates for years now from the PCI-DSS landscape and to have a more consistent and acceptable way to show PCI validation. Unfortunately, unlike the satirical tale above, this still eludes us. Drop us an email at pcidss@pkfmalaysia.com if you have any ideas and comments to this!

Do or Do Not – ASV for SAQ A

July 24, 2021 / / 0 Comments
pci-compliance

I would have thought this debate died out with the extinction of dinosaurs, but apparently, we are still at this subject in 2021. Still. Going. On.

So in the past weeks, there were some debate between us and some consultants as to whether the SAQ A requires an ASV scan or not. Our position was No. Their position was yes. So let’s look at it.

Now, keep in mind, we aren’t talking about best practice. We are talking about PCI-DSS v3.2.1 and what it says about ASV scans being mandatory for SAQ A. That’s it. That’s the statement. Now, debate.

There is actually no debate. This isn’t some sort of grey area, hard to explain, obscure rule in Sanskrit and written on the Sankara stones. This is just: Look at SAQ A, search for ASV, don’t find it. Thank you.

The ASV requirement is present in item 11.2.2 of PCI-DSS.

SAQ A does not have it.

So why do consultants still insist people do ASV scans for SAQ A?

There could be a lot of reasons, ranging from ‘guideline’, ‘best practice’ and so on. No doubt, having a scan (which isn’t expensive in any case) would be the least effort of security done by the merchant if they are hosting an e-commerce website that is redirecting customers to their payment processor once the “Click here to pay” is clicked. I mean, even if it has nothing to do with PCI, it may seem like common sense to have at least a scan done on your site to ensure it passes the very minimal requirement of security. So do we advocate an ASV scan to be done on any e-commerce site that deals with payment options (not necessarily payment data)? Yes, we do. There are many ways a site may get compromise. A coding error may allow data to be siphoned off, or passwords may be compromised. A re-direct may be vulnerable to man in the middle attacks; or even a total redirect to another page altogether where payment data is inadvertently entered. While the e-commerce site may be outsourcing the payment part to a processor, it still has the job of redirecting traffic to it.

Think of it as an usher (not the singer, but the job); where you enter into a dark auditorium, let’s say Royal Albert Hall to watch Ed Sheeran – and the usher takes you through this row of lights to what is supposedly your seat which you paid RM10,000 for.

When the lights come on, you find yourself in nice cosy room and in front of you someone who seemed to resemble Ed Sheeran but slightly off. His hair isn’t ginger and he isn’t as chubby as you see that guy on TV and he speaks with a slight Indian accent. And isn’t the Royal Albert Hall a HALL? Why are you in this room that resembles a glorified grandmother’s living room? You find out later that the usher had led you through the wrong Hall into a neighboring pub attached to the side of the hall and you are listening to the wonky music of Eddy Shiran.

The point is, the usher is pretty important in leading people to their seats. So as a redirect, even though you aren’t the main draw, you could end up leading your customers to Eddy Shiran instead.

But back to the main debate, whether it is required for SAQ A customers to go through ASV? No, it’s not.

However, there is always a but in everything. There are exceptions.

Some acquirers make it a point to state that they still require an ASV report even if merchants are going through SAQ A. That’s completely fine because the guidelines from Visa/Mastercard are just guidelines. At the end, the acquirer or payment brands may make individual decisions based on merchants, so it’s not written in stone. However, if there are no such requirement, we’re left to interpret the SAQ as it is, and it doesn’t state anything there.

Some may point out within the SAQ A under part 3a, there is a statement

ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name)

Triumphantly being pointed out as proof of ASv requirement

Take note however, that above, under Part 3a, the instructions do state:

Signatory(s) confirms:
(Check all that apply)

the realisation that asv is still not needed for Saq A (or B)

Even under the title “PCI DSS Self-Assessment Completion Steps” of the SAQ:

Submit the SAQ and Attestation of Compliance (AOC), along with any other requested documentation—such as ASV scan reports—to your acquirer, payment brand, or other requester.

It does seem to be grappling at straws if this sentence was used to justify the requirement for PCI-DSS. “Such as” generally denotes an example, which may or may not exist or is required.

In previous requirements of merchants from Visa, there used to be statements describing merchant levels such as 

 * Merchant levels are based on Visa USA definitions
** The PCI DSS requires that all merchants perform external network scanning to achieve compliance. Acquirers may require submission of scan reports and/or questionnaires by level 4 merchants

And perhaps there is where the myth was perpetuated from. In recent times Visa has updated its site (https://www.visa.com.my/support/small-business/security-compliance.html) to reflect a better understanding, stating:

“Conduct a quarterly network scan by an Approved Scan Vendor (“ASV”) (if applicable)”

In conclusion, SAQ A and B do not require ASV scans. If it’s required by the acquirer then so be it. If it’s supposed to be done out of best practice requirements, so be it. But you don’t want to hear an ASV/QSA telling you that you need to do something that is above and beyond your PCI requirement without them pointing to something in the standards that states so.

Finally – for SAQ B, which usually applies to POS terminals dialing up to the bank for authorisation; we’ve even seen some consultants requiring the merchant’s website to undergo ASV, which has nothing to do with their POS Terminals. Why ASV the website? Don’t know. So the merchants go about scanning their website that hasn’t been updated since 2012 and wonder, what sort of nonsensical requirement is this from PCI-DSS that needs them to pay just to scan something that is built by an 18 year old intern who had left the company 10 years ago? You don’t need to. So don’t do it.

Anyway, that’s it for now. Let us know your thoughts or questions and send to us at pcidss@pkfmalaysia.com and we will get back to you ASAP. Now, back to listening to our Spotify for Eddy Shiran!

The Biggest (Real) Myths of PCI-DSS: Part 3

May 10, 2021 / / 0 Comments
pci-compliance

OK, we are down to the final 3 Real Myths of PCI-DSS, so here we go!

Real Myth 8: PCI-DSS gets easier and cheaper every year

This is quite understandable, seeing that the idea behind PCI-DSS , to many is to do once and be done with it. And in a sense, this is actually borderline correct. If you learn how to ride a bike at the start, you may need to get your Dad to teach you how to ride it so he is holding you for a while. After a while (sometimes, for some, maybe six years), you are able to ride the bike on your own and you don’t need your Dad hanging around anymore. So it’s the same. Except, replace the bike with PCI activities and your Dad with outsourced consultants or implementers.

The great thing about PCI-DSS is that it doesn’t dictate you to go out and purchase expensive services. In fact, the more you “in-source” the less costly your PCI will cost you (in terms of money going out of your company). If for the first year, you paid maybe 20K for all your penetration testing services – after 2 or 3 years, you decide to set up an internal InfoSec team to do these activities – done. You don’t have that 20K output anymore, and you have a team of pentesters to do it. (Of course, the question comes – how much are you paying your pentesters’ salary?)

However, whether it becomes easier/cheaper is probably not the case. You see, the first time you go through PCI-DSS, you are in what we call, First Time Certification stage. In this part, some of the requirements, such as quarterly ASV scan, quarterly IVA, half yearly firewall reviews, 12 months of log archives etc does not apply. And you go, huh? Why? Because you get a free pass, that’s why. In the first time cert, you simply have to do one iteration of these activities. For instance, the ASV scan, you just need to demonstrate one cycle of scan for all in scope systems. Your first time cert time range should be around 6 months…so, in this case, you could run an ASV scan one time, submit that as evidence for certification and get certified.

Once you are certified, keep an eye on the date when you signed off your AoC. 12 months from that date is your expiry, so that is your maintenance year. Your maintenance year is then divided into 4 quarters and you will need to ensure your annual, quarterly, bi-weekly, weekly, daily activities are done accordingly. So instead of ONE ASV scan, you now have 4. For each of your IP. Instead of one Internal VA, you have 4. Instead of one segment PT, you have 2. Instead of 1 Firewall Review, you now have 2. You get the gist. So for those who wonder if it gets easier in the second, third, fourth year, there is a rude shock. Furthermore, your scope may increase based on your growth so instead of testing 10 systems, your second year may test 20. Additionally, knowledge may also not be kept because there your IT team or compliance team may leave. That’s reality, so you are typically back where you started. So now you know. PCI-DSS is not unlike a marriage. You need to keep working on it to make it work.

Real Myth 9: A company is considered PCI compliant even after the expiry of certification, due to 90 days grace period from the council

I know what you are thinking. You are thinking, this myth is way too specific and it sounds as if this is a real life scenario that actually occurred. You are right. Because this was exactly what we faced not long ago. You see, we had a financial institution we were chasing for a PCI renewal. They outsourced their datacenter to another company (which is common), so therefore, in accordance to PCI requirements, that datacenter needs to be included in their PCI-DSS, either demonstrating their (DC’s) own AoC or to participate with my client’s. The DC chose the former, to show their own AoC. So far, it’s ok. But then, our client’s PCI-DSS expiry is on February. The DC over the years have always managed to renew their own PCI-DSS cert on time (about a month or so before our client) so we have always had a compliant report from them (the DC). Until recently.

So while checking requirement 9 Physical Security, we noted that the AoC provided to us from the DC had already expired about two months back, and our client’s expiry is in about a month’s time. So we rightly requested them to provide us an updated AoC. Instead we received a response stating that even though their AoC has ‘expired’, as per PCI, their compliance status is still valid for 90 days (3 months) grace period, and they will be conducting an audit sometime within these 3 months.

Oh-kay.

Firstly, just to be clear, PCI-DSS doesn’t give any 90 days grace period or what not. As in, it’s not part of the standard, or part of the PCI Council’s policy. Any grace period is given by the card brands to those under their contract and that even if they choose to do so. It’s those sort of thing that is like a ‘privilege not a right’. However, since this data center has NOTHING to do with the card brands (they are directly providing service to an Financial institution, and not connected to the card brands), how did the card brands provide this 90 day grace period to them? It’s definitely not the QSA who can provide any grace period. So where did it come from?

Secondly – a grace period is a grace period against something that you did not meet. In this case, it’s the PCI standard that you did not meet, i.e you are NON COMPLIANT with an expired AoC. That’s why it’s called a grace period. Whatever the penalty or action is, that 90 days is the ‘grace period’ you have before the hammer of justice falls. The fact is, the deadline has already been missed. You are now under ‘grace’. The meaning of grace is ‘undeserved favor’ (evangelicals like to use this terminology, but I digress). You don’t deserve it, because you are non-compliant and you have missed the deadline. But the card brand is giving you a favor before they implement PCI-DSS penalties or fees on you. 90 days, get your act together, else boom.

Now, obviously, if this data center gives this response as a justification of not producing a compliant AoC, how can our QSA accept that as a proof of compliance? Unless you are saying, our client should also be delayed 3 months from their compliance date just because this data center decides to take advantage of this so called ‘grace period’? You see where the problem is. The grace period isn’t stating the company is still compliant to PCI (they are no longer compliant without a valid AoC) – it’s stating, that’s the period of time the card brands will give before they smack you with penalties according to their contract.

Real Myth 10: If the company is an ISMS certified company, they have already complied to 90% of PCI-DSS

We get this a lot. And again, it’s very understandable why people think of such. And to be honest, there is some truth here. Being ISMS certified DOES help you become PCI compliant. And vice versa. They are both IT security standards/guidelines and seen as a distant cousin of each other. However, we do get potential customers arguing to us that because they are already ISMS certified, then we should only charge them 10% of what we normally charge for PCI.

That’s a head scratcher for sure. It’s like if I had a driving license from Malaysia and I apply to get my license in Australia and I demand the Australian government (or whoever runs their driving license department) to give me the Australian driving license for 10% of the fee. How? The audit for PCI needs to be done regardless of whether you are ISMS or not. Where you will likely save up money is in the remediation stage where you may end up implementing less controls. But the audit has to be done in the same manner as any other audit.

Additionally, while both ISMS and PCI deals with the same subject – Information Security – the philosophy is different. ISMS hinges on the Statement of Applicability and the risk assessment process. That’s key. In fact many of the controls and their implementation will be based on the risk process – and furthermore, how the ISMS can be improved in every iteration. It is a ‘system’ after all.

PCI is different. While there is a ‘token’ risk assessment in there, you need to understand that PCI-DSS is a risk-based standard…only, not your risks. But the card brand’s. It’s the result of a risk assessment, which has already been done by the card brands. That’s why they decide to impose these standards – logical security, audit and monitoring, secure software development etc on you. There’s not much disaster recovery or backup requirements because that’s a business risk. It’s not a risk to credit card confidentiality. So is a risk assessment still useful? I think it still is. A whole article can be written on how useful or superfluous one may find the risk assessment requirement is for PCI, but let’s leave it for another day.

Summary

Even from the start of writing this series till now, I’ve been beset with new enquiries and PCI interpretations that has left me flabbergasted. Some of these interpretations are not unlike theories of the flat world, where it can be easily explained. Others have found little tiny crevices in the standard itself that I myself after reading the standard a dozen times over would never think of. So, to say, we are still learning a lot about PCI-DSS and how different entities see it and interpret it, so these myths may not age well. There could be a whole new list of 10 Real Myths in about a year or so. Till then, drop us any enquiries at pcidss@pkfmalaysia.com and we will do our best to guide you through PCI-DSS and the infinity that lies beyond.

The Biggest (Real) Myths of PCI-DSS: Part 2

April 29, 2021 / / 0 Comments
pci-compliance

So, continuing the Real Myths of PCI-DSS, lets move down the list.

Real Myth 5: All PCI-DSS services must be outsourced

Now, this is a very important myth to clear up. Because it directly relates to the usually biggest concern of all: cost. A while ago, we provided an idea on how to cost PCI-DSS, and break it up into certification/advisory costing and implementation cost. While the certification-advisory cost is easier to gauge based on locations, processes, card storage, activities covered , implementation cost is harder to gauge. Because number one – you don’t know your scope yet. This means, you may have 10 or you may have 200 systems in scope, you don’t know. Some go, “Ah but we know, because we have already decided our scope!” and we go, “Ah, but that’s the Real Myth 7, that you can decide your own scope…read on, intrepid adventurer of PCI!”

In any case, one way to cap a cost or save cost is to in-source your work, i.e have your own people provide the implementation services. There are no “PCI-certified” company to actually do the implementation services. All services – except for ASV scans – can be performed by your own, if you are qualified enough to do it (more on that later). I’ll throw in some services that for a typical PCI project, is a must:- Penetration testing, Internal Vulnerability assessment, secure code review and code training, patching, logging and monitoring and daily review of logs, card data scan, application testing, systems hardening, segmentation penetration testing, encryption, key management etc. These are fairly typical activities you will find in PCI – and you can do it all on your own if you have the resources and knowledge to do it. So, don’t feel cornered by any firms or consultants stating that these services must be done by them in order to pass PCI-DSS!

Real Myth 6: All service providers MUST be certified to do implementation services

This is an extension of Real Myth 5. So once the company decides to outsource the PCI services, in the case where they do not have the resources to do it internally – they go about requiring “PCI qualified” service providers to do these services. We’ve seen this requirement before where the requirement was to be a “QIR – Qualified Integrator and Reseller” to do services like penetration testing and code reviews and such. QIR isn’t created for that. QIR is created for implementing merchant payment systems and has nothing to do with the services mentioned. Aside from that, there is a growing call for PCI services to be only performed by “Certified Penetration Testing Companies” with CREST or individuals with certifications like Certified Ethical Hacker etc. Now, while these are all well and good, and certainly mentioned even by the PCI-DSS as a guidance in selecting your vendors, these are by no means a requirement by the standard. Meaning, the QSA cannot enforce all your testing to be done by the above said certified entities if you have ready, qualified and experienced personnel on your end to do it. Again – this doesn’t mean any Tom, Dick and Harry, Joe and Sally can perform testing or activities in your environment. The above certs and qualifications obviously carry weight and we should not dismiss the fact that if an organisation takes the trouble to go through CREST, versus a company that was set up two days ago, and employ 2 testers working in Elbonia – which you should prefer or which one will the QSA has less of an issue of – that’s pretty obvious. What I am stating here is that, we’ve seen many veterans who are far more efficient or experienced in systems testing and security testing than we can ever hope to be and for whatever reason, they don’t bother much about these paper chase or certifications.

At the end, the QSA may raise a query on who carried out the test and may choose to check the credentials of the testers, but in most cases, if the testing seems to be in order, most QSAs are OK with it.

Real Myth 7: PCI scope and application of controls can be determined by the customer

This one is my favourite. Because it played out like an episode of a slapstick comedy. I was called one day by one of our clients who had a new group handling their PCI-DSS program. You see, we’ve been doing their program for four plus years and we’ve been servicing them fine for years – but the new group handling PCI now isn’t well versed with PCI. It’s frustrating because no matter how many “knowledge transfer” sessions we gave, we still ended up with the same questions. We realised we were stuck in a Groundhog Day scenario, where things never change no matter what we do. The group wasn’t technical, which was an obstacle but overall, I think maybe they just have too many things on their plate.

So on this call, they said they were going to compare our quote to other providers this time around and I said, yeah, it’s fine. They then proceeded to give me a scope to quote and I commented, “Hold on, this is the wrong scope. This is the list of assets two years back. You have now changed your scope, and there is a new list of assets under scope for PCI.”

From there, the proverbial excretion hit the fan. They maintained how did I know their scope? I said, well, we helped you guys work it out. Your operations team is aware of it, that every year we help you validate your scope (as per PCI-DSS guidance). And they went: “Why must the scope come from you? We are the owners of the environment and the project, so we decide the scope!”

Aha. This is where our points diverge. You see, while the organisation does have the overall responsibility in setting the scope for PCI, PCI-DSS also has a guidance document “Guidance-PCI-DSS-Scoping-and-Segmentation” that defines how that scope should include assets and networks and therefore affecting how and where services should be implemented. So for illustration:

Company A says, “Well, we have a payment gateway and a payment switch business. We also have a call center and a merchant business that accepts credit cards through kiosks or direct POS acceptance in our outlets. Now, getting our merchant environment to be certified is going to be a pain. We have decided to just certify our payment switch environment which is isolated in a cloud, and not related to our payment gateway at all which we are just about to launch a few months from now, so there are no transactions yet.”

So there you go, Company A has set their scope and from the outset, it kinda looks fine. Yeah, if these are all isolated environment, it’s ok. In any case, in the report of compliance, the QSA would detail any services offered by the company that are NOT assessed, making clear what are the services NOT PCI compliant for that company.

However, what Company A cannot decide are the services and the assets involved in their scope. There is a method to scoping defined by PCI-DSS and we have written at length in this article here.   There are a few ways to minimise the scope by segmentation and so on, but for instance if you run a flat network and insist on it being flat, then everything within that network comes into scope – be it it’s your payment gateway, your merchant business servers, your call center laptops etc. So you can ‘define’ your scope, but what gets sucked into your scope to do hardening, pentesting, patching and all the PCI controls – that is already defined by the PCI on how it’s done. And we just have to identify these assets and systems and networks that get sucked into scope. PCI is a like a giant vortex or blackhole. Everything that is sitting on the same network or touches the systems in CDE, gets pulled into scope.

So there you have it. We will be exploring the final 3 Real Myths of PCI soon, but for now, if you have any queries on PCI-DSS, or ISMS or Theory of Relativity and Blackholes, drop us a note at pcidss@pkfmalaysia.com. Till then, be safe!

« Older posts

© 2024 PKF AvantEdge

— Up ↑