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.
Leave a Reply