Introducing PCI DSS 4.0

After 3 years and 6,000+ feedback items from more than 200 organizations (including our own participation in the process), PCI DSS 4.0 has finally been released. There were 4 goals in the development of version 4.0:

• Continue to meet the security need of the payment industry
• Promote security as a continuous process
• Add flexibility for different methodologies
• Enhance validation methods

With the release of PCI DSS v4.0, there are a couple of revised dates to keep in mind. Version 3.2.1 of the standard will remain active until March 2024, after which it will be retired. And any future-dated new requirements will become effective on ch 31, 2025.

PCI DSS 4.0 also brings about two approaches for implementing and validating the requirements. There is the Defined Approach and the Customized Approach.

As per the standard, the Defined Approach "Follows the traditional method for implementing and validating PCI DSS and uses the Requirements and Testing Procedures defined within the standard." What remains as part of this approach is Compensating Controls. Again, as stated in the new standard, "As part of the defined approach, entities that cannot meet a PCI DSS requirement explicitly as stated due to a legitimate and documented technical or business constraint may implement other, or compensating controls, that sufficiently mitigate the risk associated with the requirement."

Where things really change up is the Customized Approach. This approach was designed to support innovations in cyber security and allow flexibility in showing how an entity's security controls meet a PCI DSS objective. It's suited for risk-mature companies that account for the new approach. The Customized Approach, according to the standard, "Focuses on the Objective of each PCI DSS requirement (if applicable), allowing entities to implement controls to meet the requirement's stated Customized Approach Objective in a way that does not strictly follow the defined requirement."

You can have a mix of the Defined and Customized Approach in your environment and subsequent assessment. However, note that "the controls implemented and validated using the customized approach are expected to meet or exceed the security provided by the requirement in the defined approach. The level of documentation and effort required to validate customized implementations will also be greater than for the defined approach."

Between versions 3.2.1 and version 4.0, there are three change types:

• Evolving requirement “Changes to ensure that the standard is up to date with emerging threats and technologies, and changes in the payment industry. Examples include new or modified requirements or testing procedures, or the removal of a requirement."
• Clarification or guidance “Updates to wording, explanation, definition, additional guidance, and/or instruction to increase understanding or provide further information or guidance on a particular topic."
• Structure or format “Reorganization of content, including combining, separating, and renumbering of requirements to align content."

For a moment let's look at some of the new future-dated Evolving requirements coming out of the new standard. Now is the time to look at these requirements in terms of an overall compliance program to ensure they are in place by the time the future-dated requirements become a reality.

• 3.3.2 SAD stored electronically prior to completion of authorization is encrypted using strong cryptography.
• 3.4.2 Technical controls to prevent copy and/or relocation of PAN when using remote-access technologies except with explicit authorization.
• 3.5.1.1 Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN with associated key management processes and procedures.
• 3.5.1.2 Implementation of disk-level or partition level encryption when used to render PAN unreadable.
• 4.2.1 Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked.
• 5.3.3 Anti-malware scans are performed when removable electronic media is in use.
• 5.4.1 Mechanisms are in place to detect and protect personnel against phishing attacks.
• 5.4.2 Deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks.
• 8.4.2 Multi-factor authentication for all access into the CDE.
• 10.4.1.1 Audit log reviews are automated.
• 11.3.1.1 Manage all other applicable vulnerabilities (those not ranked as high-risk or critical).
• 11.3.1.2 Internal vulnerability scans are performed via authenticated scanning.
• 11.6.1 A change-and-tamper-detection mechanism is deployed for payment pages.
• 12.10.5 The security incident response plan includes alerts from the change-and tamper-detection mechanism for payment pages.
• 12.10.7 Incident response procedures are in place and initiated upon detection of PAN.

These are but a few of the changes, and all of the above (as mentioned earlier) are future dated. But you get the sense that planning from now to not only meet the retirement date of version 3.2.1 but also the effective date for future-dated requirements is a must.

Organizations should start reviewing the new version of the standard and how the changes will affect their compliance program. They should work with their security partners and QSA to define a migration plan to move their compliance program to version 4.0 within the timeframe laid out by the PCI DSS.

Contact the VikingCloud team for more information about PCI DSS v4.0 or visit https://www.vikingcloud.com/compliance-risk/pci-compliance.