When I received notification of the standard’s publication on March 31, 2022, I thought it was an April fool’s joke. So I let the day pass to check the next day, and well no – it’s just an April fool’s joke.*** The standard has indeed been published!***

Transition period

The transition period is from March 31, 2022 to March 31, 2024. You have this time to modify documentation, reports and other forms or records to comply with the new requirements. PCIDSS 3.2.1 remains valid during this period, for those already certified. Newcomers may be able to slip in while QSAs (Qualified Security Assessors) complete their training.

Some of the new requirements in version 4.0 will not become mandatory until March 31, 2025. Until this date, these requirements are considered “best practice”.

However, it is advisable to start implementing them early, so as not to be faced at the last minute with requirements that may prove difficult to implement quickly or simply.

In order to understand the changes, I looked at the standard itself and especially at the new ROC (Report on compliance). In my opinion, this is where the changes lie, but above all the nuances of these changes, because this is where we find the requirements that auditors (QSA) have to audit firms.

Customized approach

The standard adds a new way of complying with a security measure by means of a Customized implementation. Please note that this approach is not possible for certain security measures. The aim of this change is to give companies greater flexibility, since a good solution for company A is not the same for company B.

That said, the new version of the standard adds many (too many) new elements. Here are a few examples:

  • At least every 12 months and whenever a significant change occurs, document and confirm the PCI DSS scope of the in-scope environment (PCI DSS 12.5.2);
  • A targeted risk analysis for any control using the customized approach at least every 12 months with written approvals from top management (PCI DSS 13.3.2);
  • At least one annual risk analysis for all controls that have a flexible control frequency (PCI DSS 13.3.1);
  • At least one annual review of encryption suites and protocols (PCI DSS 12.3.3);
  • At least one annual review of hardware and software technologies in use, with a remediation plan for obsolete technologies approved by senior management (PCI DSS 12.3.4);

The importance of access management

In addition, version 4.0 of the PCI DSS standard increases the importance of access control through the following constraints:

  • Use of multi-factor authentication for all accounts accessing cardholder data, not just administrators accessing the cardholder data environment.
  • Passwords for accounts used by applications and systems must be changed at least every every 12 months and in the event of suspected compromise.
  • Use strong passwords for accounts used by applications and systems, which must contain at least 15 charactersincluding numeric and alphabetic characters.
  • PCI DSS now requires that passwords be checked against a list of known bad passwords.
  • Access privileges should be reviewed at least once every six months.
  • Supplier or third-party accounts can only be activated when necessary, and monitored when used.

More concretely, here are the changes listed by requirement. It should be noted that the numbers have been modified, either in the order or in the sub-items.

There are no major changes to requirements 1 and 2.

For each section – A policy must be defined and a person in charge assigned.

Requirement 3 – Protection of stored account data

  • Sensitive authentication data (SAD) stored electronically prior to transaction authorization (for the duration of data processing) must be encrypted using strong cryptography (encryption was not specified before).
  • Add technical controls to prevent copying and/or relocation of the PAN when using remote access technologies. (The RDP session must prevent “copy/paste”)
  • During hashing, a secret value (or key) must be added to the process to render the PAN (primary account number) unreadable.
  • Disk or partition encryption is only used to render the NAP unreadable on removable electronic media or, if used on non-removable electronic media, the NAP is also rendered unreadable by a mechanism identified in the point above.
  • The use of the same cryptographic keys in production and test environments is prohibited.

Requirement 4 – Protect cardholder data with strong cryptography during transmission over open and public networks

  • Confirm that certificates used for PAN transmissions over open and public networks are valid and have not expired or been revoked.
  • Maintain an inventory of trusted keys and certificates.

Requirement 5 – Protect all systems and networks against malware

  • Define the frequency of periodic assessments of system components that are not exposed to malware in the targeted enterprise risk analysis. (Beware of Linux-based virtualizations such as ESXi, which have recently been infected with specific viruses – see: Lockbitand Hellokitty. )
  • Define the frequency of periodic malware scans in the entity’s targeted risk analysis.
  • A solution for malware on removable electronic media
  • Detect and protect staff against phishing attacks

Requirement 6 – Develop and maintain secure systems and software

  • Maintain an inventory of customized software.
  • Deploy an automated technical solution for public-facing web applications that continuously detects and prevents web-based attacks.
  • Management of all payment page scripts loaded and executed in the consumer’s browser.

Requirement 7 – Restrict access to system components and cardholder data for professional information purposes

  • Review of all user accounts and associated access privileges
  • Assign and manage all application and system accounts and associated access privileges
  • Review all application and system account access and associated access privileges.

Requirement 8 – Identify users and authenticate access to system components

  • Increase password length from a minimum of seven characters to a minimum of 12 characters (or if the system doesn’t support 12 characters, a minimum of eight characters).
  • If passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days, or access to resources is automatically determined by a dynamic analysis of account security posture. (Switch to passwordless)
  • Implement multi-factor authentication (MFA) for all CDE access.
  • Manage system or application accounts that can be used for an interactive connection
  • Do not hard-code passwords/passphrases in files or scripts for application and system accounts that may be used for interactive login.
  • Password/passphrase protection for application and system accounts against misuse.

Requirement 9 – Limit physical access to cardholder data

  • Define the frequency of periodic inspections of point-of-sale terminals, based on the entity’s targeted risk analysis.

Requirement 10 – Log and monitor all access to system components and cardholder data

  • Use automated mechanisms to perform audit log reviews
  • Targeted risk analysis to define the frequency of periodic log reviews for all other system components.
  • Detect, alert and rapidly deal with failures in safety-critical control systems.
  • React quickly to failures of any safety-critical control.

Requirement 11 – Regularly test system and network security

  • Manage all other applicable vulnerabilities (those not classified as high-risk or critical) discovered during internal vulnerability scans.
  • Perform internal vulnerability scans with a valid account (Authentication)
  • Requirement for third-party hosted/cloud service providers to support their customers for external penetration testing.
  • Use intrusion detection and/or prevention techniques to detect, alert/prevent and deal with clandestine malware communication channels.
  • Deploy a modification and alteration detection mechanism to report unauthorized changes to HTTP headers and payment page content received by the consumer’s browser.

Requirement 12 – Support information security with organizational policies and programs

  • Carry out a targeted risk analysis for any PCI DSS requirement that offers flexibility in terms of the frequency of its execution.
  • Document and review the cipher suites and cryptographic protocols used at least once every 12 months.
  • Review hardware and software technologies at least once every 12 months.
  • Document and confirm the scope of the PCI DSS standard at least once every 12 months for merchants and twice a year for service providers. And whenever there is a significant change in the environment concerned.
  • Documented review of the impact on the scope of the PCI DSS standard and the applicability of controls in the event of significant changes to the organizational structure, such as company reorganizations or mergers.
  • Review and update (if necessary) the security awareness program at least once every 12 months.
  • Security awareness training including awareness of threats and vulnerabilities that could impact on CDE security.
  • Security awareness training must include awareness of the acceptable use of end-user technologies.
  • Support customer requests for information to meet requirements 12.8.4 and 12.8.5.
  • Carry out a targeted risk analysis to define the frequency of periodic training courses for incident response personnel.
  • Obligation to set up incident response procedures and trigger them as soon as a NAP stored in an unexpected location is detected.

Read the blog: PCI Guru for an opinion, he has a strong opinion on the new PCI DSS standard 4

I invite you to click on “Follow” to continue learning more about the field of information security.