So we are now in 2022. PCI-DSS v4.0 is due to be out and one of the things we have been doing for the first two weeks of the year is to get over our holiday hangovers. That’s right. In our country (Malaysia), the slowest months are December, January and February. It’s like starting a car in the dead of winter. These 3 months are like the Amen Corner in Augusta for businesses. December hits like a ton of bricks due to the Christmas season; and then just when things start moving in January, it grinds to a halt for Chinese New Year, where the entire nation just flat out refuses to work. When we are back in the second week of Chinese New Year, we are once more in first gear climbing up the hill again of 2022.
So we did things a bit differently. We started the first two weeks with a series of training for clients and potential clients, to go through PCI-DSS v4.0 and create an awareness of what is there to expect.
The above is taken from the PCI website and immediately we see some interesting things here. Number one: PCI-DSS v3.2.1 only retires in 2024. This is interesting, because usually the transition period isn’t so long. It’s long now because – I don’t know, there may be an ongoing pandemic and such. So here we are Q1 2022, and our customers are asking when do we transition to v4.0?
Well, the answer would be: as soon as you can. But in theory, you can probably stick to v3.2.1 validation for 2022 and realistically move to v4.0 in 2023. In fact, for some of our clients whose PCI maintenance period follows the calendar year, they can even force 3.2.1 into their 2023 validation year.
As for the actual content in PCI v4, it’s still a well kept secret like the plot of Spiderman: No Way Home; but we have been reading a bit and also have joined last year’s PCI-DSS community meeting and learnt some interesting tid-bits of it.
No 1: Compensating Controls
The-get-out-of-jail-free card. Customers have been dangling this Compensating Controls card in front of our faces ever since the Mesopotamian times. When they can’t address a control – use compensating controls! When they cannot implement something due to budget – compensating controls! When they can’t make changes to an application because it was designed by a group of kindergarten kids and it would break the moment you touch it – Compensating Controls! When you don’t know what to say to your wife after a long night out at the pub with the mates and come back smelling like a keg of kerosene – Compensating Controls!
The problem with compensating controls is that they are a pain in the neck to implement and to document. And to justify. The compensating control worksheet, the justification documentation, the implementation of the control itself to be ‘above and beyond’ the scope of PCI-DSS etc. Everyone things this is a silver bullet only to find it the deepest rabbit hole you can ever fall into.
So, PCI v4 does away with compensating controls. Great.
And they introduce Customized Implementation.
A lot of people are saying this is a game changer.
Honestly? Until more information comes out, we only have this to go with:
Cryptic PCI v4 DOCUMENTATION
Customized implementation considers the intent of the objective and allows entities to design their own security controls to meet it. Once an organization determines the security control for a given objective, it must provide full documentation to enable their Qualified Security Auditor (QSA) to make a final decision on the effectiveness of a control.
Design their own security controls? Well, ok, isn’t this the same as compensating controls? I am thinking this just expands the interpretation to something a bit broader in which case the control may not even be a technical control. So instead of stating , ok, we can’t meet certain password controls due to the legacy application issue, and compensating controls were previously excessive logging and monitoring; isolation of network, whitelisting of IPs and access; using WAF and DLP and Virtual patching etc etc; are we stating now, a possible customized approach would be: instead of all these technical controls; we now have a customized security approach. Which includes isolation of network, whitelisting of IPs and access; using WAF and DLP and Virtual patching etc etc.
Until we see some examples of this, it may just be well that most companies will go along with the ‘normal’ approach; or adopt a wait and see approach and eke out the last remaining drop of v3.2.1. into 2024.
No 2: UP in the Clouds
Another item that has been long overdue? Cloud. It’s about time things get addressed and not just cloud, but how services and containers work as well. We have had auditors coming to our clients insisting on them doing testing, VA/PT on services from AWS, not recognizing there’s not even an IP address to start with. To be fair to the SSC, they do have a few Cloud Guidelines Supplementary documentation, which we actually find very useful especially in our projects on certifying cloud technologies. We can see this being incorporated more formally into v4.0 where the requirements will be designed around Cloud environment more organically than what we see right now (sort of force-fitting many of the traditional concepts like Network IDS, Patching etc into the cloud environment).
No 3: Not another MF-A!
I have a bad feeling about this.
MFA has been a constant pain for us. Firstly, where MFA is being implemented – not just on perimeter but now on every access to the CDE. At least it’s now still on admin accounts. We hear they plan to introduce for ALL users. We also hear the collective screams of the tormented from the nine hells of Dante. Secondly, a lot of customers are still depending on MFA via SMS. If PCI goes along the NIST route, we could see this being deprecated soon. Also, clarifications as well on whether client side certificate are acceptable as a ‘something you have’ factor would be most welcomed. We see different QSAs interpreting this so differently you’d think we’ve asked them to interpret some ancient Thuggee text. Multi-factor challenges are already there for us over the past years, with Bank Negara’s RMIT focus on ‘strong MFA’ for large financial institutions. A clear guidance also should be there on how to evaluate multi-factor that is dependent on a cloud provider; and whether common implementation like Google Authentication etc can still be considered as good enough for V4.0
No 4: Encrypting everything
We also hear now that the “Pocket Protector Trope” security may be implemented. Remember those movies we watch, where the hero gets shot in the chest and you think he dies but he reveals that the bullet is stopped by his pocket watch; his badge; a bible; or some other dang sentimental thing that was given to him like 40 scenes ago?
So in PCI, usually when data is traversing the internet or network, it states the transmission needs to be encrypted. It doesn’t technically state anything about encrypting the data package itself while in transmission. The data encryption almost exclusive occurs during data at rest. So in this case, they are doubling the protection: They are adding that pocket watch to catch the bullet; so if the transmission gets compromised, the data is still secured. The bullet doesn’t hit the hero!
No 5: Recovery and Continuity
Not so much as something coming, but more of what we’d like to see. One of the biggest criticism we see customers bemoaning at PCI (other than the cost and budget and the complexity and..ok, everything else) – is that PCI has little focus on business continuity and disaster recovery. It’s almost as if PCI is standing there saying, “OK, you have outage for a few days? Great, make sure your credit card information is safe.” It’s not really business focused, it’s more credit card confidentiality focus. What we would like to see is a little more focus on this area. Over the past 2 years, we have seen customers getting all sorts of attacks from cyberspace. Malware, ransomware, hacking, fraud, defacement — it’s like the world goes into a pandemic and everyone’s bored to bits at home and everyone is taking up hacking as a part time gig. Malware for instance – how prepared is a PCI compliant company against ransomware attack? Have they done their backups? Have they tested their systems to recover?
So, if you have any queries on PCIv4 for us, drop us an email at pcidss@pkfmalaysia.com and we will definitely get back to you. Have a great and safe year ahead for 2022!
