So here we are in 2023 and PCIv4.0 is on everyone’s thoughts. Most of our customers have finished their 2022 cycle; and some are going through their 2023 cycle. Anyone certifying this year in general, means that for the next cycle on 2024, they will be certified against v4.0. V3.2.1 will be sunset in March 2024, so as a general rule of thumb, anyone going for certification/recertification in 2024 – hop onto v4.0.
Take also special note of the requirements where statements are “Best practices until 31 March 2025, after which these requirements will be required and must be fully considered during a PCI DSS assessment “.
It doesn’t mean that you can actively ignore these requirements until 2025; rather, to use this period of around 2 years as a transition period for your business to move into these newer requirements. So, to put it short: start even now. One of the requirements that gets a lot of flak is 3.5.1.2 which is the disk level encryption; in other words, technology like TDE being used to address encryption requirements. This is no longer a get out of jail free card because after March 2025, you will need to implement (on top of TDE, if you still insist on using it), if you are not using it on removable media – the 4 horsemen of the apocalypse – Truncation, Tokenization, Encryption or Hashing. And before you get too smart and say yes, you are using Encryption already, i.e transparent or disk-level encryption; PCI is one step ahead of you, you Maestro of Maleficant Excuses, as they spell out “through truncation or a data-level encryption mechanism“.
So, for v4.0 it’s probably easier to just break it up into
a) SAQs v4.0 – Self assessment
This is straight forward – a lot of changes have occurred to some of the venerable SAQs out there, such as SAQ A. I’ll cover that in another article.
b) ROC v4.0 – from QSA/ISA
Most QSAs should be able to certify against v4.0. You can check on the PCI-DSS QSA lists, they have ” ** PCI DSS v4 Assessors ” under their names. There also may be some shakeout that some underqualified QSAs may not go through the training to upgrade to v4 assessors. On another note, ISAs don’t generally have these requirements to upgrade to v4.0; although it’s recommended.
Now, perhaps is a good time to just go through a very big overview of V4.0 and explain why some of these changes had been effected.
Changes to Requirements
For this overview, we will first look at the 12 requirements statements and see where the changes are. In a big move, the council has updated the main requirements (not so subtly), getting rid of many of the tropes of previous incarnation of the standard. Let’s start here.
Requirement 1 is now changed to “Install and Maintain Network Security Controls” as opposed to “Install and maintain firewall configuration to protect CHD.”
This is a good change; even if the wordings are still a little clumsy. After all Network Security Controls are defined so broadly and may not just be a service or product like a firewall or a NAC or TACACs. It could be access controls, AAA policies, IAM practices, password policies, remote access controls etc. So how do you ‘install’ such policies or practices? A better word would be to “Implement” but I think that’s nitpicking. Install is an OK word here, but everytime I hear that, I think of someone installing a subwoofer in my car or installing an air-cond in my rental unit. But overall, it’s a lot better than just relying on the firewall word – since in today’s environment, a firewall may no longer just function as a firewall anymore; and integrated security systems are fairly common where multiple security functions are rolled into one.
Requirement 2 now reads as “Apply Secure Configurations to All System Components.” Which is a heck better than “Do not use vendor supplied defaults for system passwords and other security parameter.” The latter always sounded so off, as if it’s like a foster child that never belonged to the family. Because it reads more like a control objective or part of a smaller subset of control area as opposed to an overarching requirement. It just made PCI sounds juvenile compared to much better written standards like the ISO, or NIST or CIS.
Requirement 3 changes are subtle from “Protect stored cardholder data” to “Protect stored account data” – they removed cardholder data and replace it with “account” data. It generally means the same thing; but with account data, they possibly want to broaden the applicability of the standard. Afterall, it may be soon that cards may be obsolete; and it might be all information will be contained in the mobile device, or authenticated through virtual cloud services. Hence a traditional person ‘holding a card’ may no longer be a concept anymore.
Requirement 4 reverts back to cardholder data, with the new 4.0 stating “Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks”. Which is sometimes frustrating. If you have decided to call account data moving forward, just call it account data and not revert back to cardholder data. Also this requirement changed from the older “Encrypt transmission of cardholder data across open, public networks”. It may sound the same, but it’s different. It removes the age old confusion on, what if I encrypt my data first and then only transmit it? In the previous definition, it doesn’t matter. The transmission still needs to be encrypted by the way it is written. However, with the new definition, you are now able to encrypt the data and send it across an unencrypted channel (though not recommended) and still be in compliance. Ah, English.
“Requirement 5: Protect All Systems and Networks from Malicious Software” is a definite upgrade from the old “Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs”. This gives a better context from the anti-virus trope – where QSAs insist on every system having an antivirus even if its running on VAX or even if it brings down the database with its constant updates. Now, with a broader understanding that anti-virus is NOT the solution to malicious software threats; we are able to move to a myriad of end point security that serves a better purpose to the requirement. So long, CLAMAV for Linux and Unix!
Requirement 6 reads about the same except they changed the word ‘applications’ to software i.e “Develop and maintain secure systems and applications” to “Develop and Maintain Secure Systems and Software”. I am not sure why; but I suppose that many software that may serve as a vector of attack may not be classified as an application. It could be a middle ware, or an API etc.
By the way, just to meander away here. I noted that in V4.0 requirements, every word’s first letter is Capitalised, except for minor words like conjuctions, prepositions, articles. This seems to be in line with some of the published standards such as CIS (but not NIST), and its basically just an interesting way to write it. This style is called “Title Case”, and It Can Be Overused and Abused Quite a Lot if We Are Not Careful.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know vs previous version Requirement 7: Restrict access to cardholder data by business need to know. Again, this is more expansionary; as system components (we assume those in scope) may not just be containing cardholder data; but have influence over the security posture of the environment overall. Where previously you may say, well, it’s only access to the account data that requires ‘business need to know’ or least privvy; now, access to authentication devices; or SIEM, or any security based service that influences the security posture of the environment – all these accesses must be restricted to business need to know. Again – this is a good thing.
Requirement 8: Identify Users and Authenticate Access to System Components vs previous version “Identify and authenticate access to system components”. This seems like just an aesthetic fix. Since, yes, you probably want to identify USERS as opposed to identify ACCESS. It could mean the same thing, or it may not. A smart alec somewhere probably told the QSA, hey, we identified the access properly. It came from login 24601 from the bakery department at 6 am yesterday. Do we know the user? No, but PCI just needs us to identify the ‘access’ and not the user, right? OK, smart alec.
Requirement 9: Restrict Physical Access to Cardholder Data is the only one that does not have any changes, except for the aforementioned Title Case changes.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data vs Track and monitor all access to network resources and cardholder data. So two things changed here. “Log” vs “Track” and System Components vs Network Resources. I personally find the first change a bit limiting when you are saying to just log instead of ‘track’. But I know why they did it. Because Tracking is redundant, if you are already Monitoring it. So in another dimension somewhere, the same smart alec may state, no where did it tell us to ‘log’ or keep logs in this statement – they just want us to Track/Monitor users. So its just for clarity that from here on, you log and monitor, not just track/monitor. The second change is very good, because now, there is no ambiguity for non-network resources. It’s true when one day, we actually came across a client stating this does not apply to them because they do not put their critical systems on the network and they only use terminal access to it, therefore there’s no need to log or monitor. The creativity of these geniuses know no bounds when it comes to avoiding requirements.
Requirement 11: Test Security of Systems and Networks Regularly vs Regularly test security systems and processes. Switching the word regularly is done just for aesthetic reading, but the newer word strings better and again, removes ambiguity. I mean first thing, the older requirement tells us to test ‘security systems’. Now most of the workstations et al may not be defined as ‘security systems’. I would define security systems as a system that contributes to the security posture of a company – an authentication system, a logging system, the NAC, the firewall etc. Of course, this isn’t what PCI meant and they realised, snap, English is really a cruel language. “Security systems” does not equal to “Security of Systems”. That two letters there changed everything. Now, systems are defined as any system in scope – not just one that influences security. We need to test security of all systems in scope. The second change to remove processes and insert in Networks is better, I agree. I did have a client asking me, how do we ‘test processes’ for PCI. Do we need to audit and check the human process of doing something? While that is true in an audit, that’s not the spirit of this requirement. This is for technical testing, i.e scans, penetration testing etc. So rightly, they removed ‘processes’ and inserted Networks; which also clears the ambiguity of performance of a network penetration testing, as well as application penetration testing.
Again, I just want to add, all these are actually clarified in the sub controls in the both v3.2.1 and v4.0 but if someone were just to skate through PCI reading the main requirements titles – I can see where the misunderstanding may occur with the old titles.
Finally, Requirement 12 Support Information Security with Organizational Policies and Programs is an upgrade from the previous Maintain a policy that addresses information security for all personnel. The previous title was just clumsy. Many clients understood it to be a single policy, or information security policy that needs to be drawn up, because it states Maintain A Policy. One Policy to rule them all. And this policy governs information security for all humans. Which doesn’t make sense. Unless the ‘for’ here was to mean that this policy needs to be adhered by all personnel; not that the personnel were the subjects of the information security. Yikes. The newer route makes more sense. Have your policies and programs support information security overall. Not information security of your people; but information security, period.
So just by reading the titles (and not going deep dive yet), we can see the improvement in clarifying certain things. There is more function in the sentence; there is more of an overarching purpose to it and most of all, it looks and reads more professionally that puts PCI more into the stately tomes of ISO, CIS or NIST.
While waiting for the next deep dive article, drop us a note at pcidss@pkfmalaysia.com if you have any queries at all about PCI, ISO27001, NIST, SOC or any standard at all. Happy New Year, all!
