Penetration Testing PCI DSS V4.0 – Changes And Differences

  • Home
  • Blog
  • Penetration Testing PCI DSS V4.0 – Changes And Differences
Penetration Testing PCI DSS V4.0 – Changes And Differences
 

Australian Penetration Testing PCI DSS V4.0 – Major Changes And Differences

The long-anticipated release of the Payment Card Industry (PCI) Data Security Standard (DSS) Version 4.0 (v4.0) by the PCI Council occurred on March 31, 2022. Although not a revolution, the new version contains many changes from the previous version (v3.2.1). According to the Council, the changes represent their determination to “continue to meet the security needs of the payment industry, promote security as a continuous process, add flexibility for different methodologies, and enhance validation methods”. We summarized four of the most notable differences in the new version:

 

Risk-Based Approach to Determine Applicability of Requirements

Unlike previous versions, PCI DSS v4.0 allows two paths for the assessed entity to achieve compliance: A defined Approach and a Customised Approach.

Given the diverse nature of assessed entities, except for a few requirements, v4.0 allows the entities to determine and implement customised security controls that are best suited for their cardholder data environment (CDE). The Council intends for the Customised Approach option to be utilized by more established organisations that have demonstrated a robust risk management approach to security. The Customised Approach supports innovation in security practices and allows entities greater flexibility to show their current security controls meet the objectives for each individual requirement.

Different from Compensating Controls, the security control(s) under the Customised Approach must fulfil the PCI requirement objectives directly and the assessed entity must have a formalized risk assessment process to support and justify the Customised Approach.

During an assessment and within the Report on Compliance (ROC), the assessed entity and the Qualified Security Assessor (QSA) must identify the aspect(s) of the requirement where the Customised Approach is used and, for each control for which the Customised Approach is utilised, justification must be documented within the newly added Appendix E (Customised Approach Template).

On the other hand, the Defined Approach is the more traditional method of meeting requirements within PCI DSS v4.0. The Council intends for this approach be utilised by entities with security controls in place that meet the stated requirements directly or by entities that are new to information security or PCI DSS, and needs more direction to meet the required objectives.

 

New Requirements

Although PCI DSS v4.0 still contains 12 high-level requirement categories, many new requirements were added to those categories within the new version. For organisations with complicated a CDE, some of those new requirements may have a significant impact on their security programs. The new requirements and associated security controls that need to be implemented include:

  • Implement a method to manage and maintain all payment page scripts that are loaded and executed in the consumer’s browser (Requirement 6.4.3),
  • Review user access and related privileges every six months for all in-scope user accounts (Requirement 7.2.4),
  • Restrict application and system account access and conduct periodic access reviews for those accounts (Requirement 7.2.5.1),
  • Implement a payment page change detection mechanism (Requirement 11.6),
  • Formalise an annual risk assessment program (Requirement 12.3), and
  • Conduct annual hardware and software reviews (Requirement 12.3.4).

The Council recognises that it takes time for assessed entities to implement new security controls and fulfil all of these requirements. As such, the listed requirements are considered best practices until March 31, 2025, at which time they will become fully enforced requirements.

Incremental Tactical/Technical Changes

In addition to the above changes, there are gradual and incremental tactical changes in PCI DSS v4.0, as well. For example, for a long time the cyber security community has been concerned that the current requirements for user authentication (in particular, the 7-character minimum password length requirement) fall short of the industry’s standards. The new version now requires a minimum password length of 12 characters (or 8 characters for systems that do not support 12).

Another interesting evolution is the requirement regarding security awareness training. In v4.0, the PCI DSS formally requires the assessed entity to address social engineering and phishing risks within its security awareness training. Additionally, the security awareness program must be reviewed at least once every 12 months and to address any new threats and vulnerabilities that may impact the security of the entity’s CDE. Those are just two of the many incremental changes that stand out from PCI DSS v3.2.1. Those changes build upon the foundation of the previous versions and continue to evolve to meet the industry’s best practices.

Changes in ROC/SAQ Format

Besides the Customised Approach and verbiage updates, the most obvious and substantial changes are in the ROC and SAQ templates. The published PCI DSS v4.0 is 360 pages long, compared to the 139-page standard for v3.2.1. The Report on Compliance (ROC) template increased from 191 pages to 492 pages. The Self-Assessment Questionnaire (SAQ) templates are also changed to better align with the new requirements.

A large chunk of the increased volume in PCI DSS and the ROC template reflect the Council’s guidance for the Customised Approach and new requirements described above. But the Council are reorganised the ROC template to strengthen the documentation for the assessed entity’s background information and related payment processes. Additionally, the new ROC requires the QSAs to categorize the evidence work papers into four categories (“Documentation Evidence”, “Interview Evidence”, “Observation Evidence”, and “System Evidence”). Unlike the previous versions, within the subsequent “Findings and Observations” section, the QSA is no longer required to provide detailed descriptions of how the assessment is being performed, but rather must refer to those working papers and collected evidence directly (unless the Customised Approach and/or Compensating Controls are utilized). This change will likely result in the QSA spending more time and effort to document/strengthen the evidence gathered and, in turn, require the assessed entity to provide clear and concise audit trails to support their PCI DSS compliance.

Furthermore, the questions within the SAQs have been updated and some include additional requirements. For example, SAQ-A has increased from 22 questions to 29 questions and includes additional requirements for protecting card data, system development, system access and authentication, external vulnerability scans, and deployment of change detection mechanisms. Additionally, the new SAQs have been expanded to include five different responses from the previous four. The newly added response of “In Place with Remediation” allows the assessed entity to remediate any deficiencies noted during the self-assessment and complete the remedial actions before the completion of the SAQ.

Summary

All in all, those are just some of the highlights of the changes made to the PCI DSS in version 4.0. This is not intended to be a comprehensive guide for all the changes, but rather a brief introduction and overview. We will unpack all of the updates in more detail in some additional upcoming posts.

PCI DSS v3.2.1 will be sunset by March 31, 2024 and fully replaced by PCI DSS v4.0 at that time. The Council has allowed for a two-year transition. For the new requirements, the Council has allowed them to be best practices until March 31, 2025. As such, the assessed entities have less than three years in total to adopt and be fully compliant with all of the new aspects of the standard. If you have any questions on the PCI DSS v4.0, please let us know and we’d be happy to discuss further!

 

Siege Cyber – Australian Leader in Penetration Testing

Take charge of your company’s security posture by addressing vulnerability issues before they become the source of a significant data breach or other cyber-attacks. Siege Cyber helps companies identify and solve security problems within their networks, systems, and other assets. Contact us today at contact@siegecyber.com.au or contact us for a free consultation with one of our penetration testers today.

 

About Me

I’m co-founder of Siege Cyber and passionate about Cyber Security, Hiking and Mountain Biking. I’ve been working in Cyber for the past 20 years and most of those years as a penetration tester. As a penetration tester, I’ve tested some of the biggest companies in Australia before branching out and starting Siege Cyber. Siege Cyber was created to be an Australian owned and operated bespoke cyber security company focusing on helping our customers secure their organisation and stay up to date with their compliance requirements listed in PCI-DSS, CPS 234, ISO 27001 and others.

You can contact me at Jamie Janda or connect on Linkedin

Happy to chat, happy to help.