PCI DSS 4.0 framework: securing cardholder data with requirement updates that promote secure coding practices.

The Payment Card Industry Data Security Standard (PCI DSS) is a critical framework for securing cardholder data. With the release of PCI DSS 4.0 in 2022, significant updates have been introduced to enhance software security and promote secure coding practices.  

Obviously, software security is an essential component of protecting cardholder data. Vulnerabilities in software can be exploited by malicious actors to gain unauthorized access to sensitive information. Therefore, PCI DSS 4.0 places an even stronger emphasis on ensuring that software development practices incorporate robust security measures from the outset. 

Following our previous article on the training requirements, in this article we focus on the software security aspects of PCI DSS 4.0, mapping the requirements to general software security issues, and looking at the key changes as compared to the previous version 3.2.1. 

Secure coding requirements in PCI DSS 4.0 

The PCI Security Standards Council Glossary defines secure coding as “The process of creating and implementing applications that are resistant to tampering and/or compromise”. So far so good (more or less). This definition covers two elements from the CIA, namely Confidentiality (as long as we take “compromise” to refer to information disclosure) and Integrity (with tampering as the threat); it however does not address the third component, namely Availability (or denial of service as the associated threat), which is as important as the other two. And the lack of this requirement in the definition above is well aligned to the lack of focus on this security property in the PCI DSS itself. 

Extending the CIA model to STRIDE, Authentication and Authorization are well covered via Requirement 8 and 7. Repudiation however is also badly missing, despite the fact that it is a key requirement in financial transactions. 

When mapping specific requirements of PCI DSS 4.0 to secure coding, we can see that nearly all requirements have a strong link to some of the secure coding topics. Let’s see these connections one by one. Note that some of the mentioned requirements are “just” best practices until a well-defined transition period is over – this is always clearly indicated in the standard. 

Requirement 2: Secure configuration and hardening 

Secure configuration and hardening of software applications and systems are critical for reducing the attack surface. This requirement connects well to the A5 Security Misconfiguration of the OWASP Top Ten (2021), and secure coding relevant topics include configuration principles and guidelines, hardening, cookie security, and XML parser configuration to prevent External Entity Attack (XXE). 

Configuration and hardening requirements are more explicit in PCI DSS 4.0. The new version outlines specific guidelines for developing and enforcing secure configuration and hardening practices, implementing configuration management processes, and leveraging automation. 

Requirements 3 and 4: Cryptography 

These two requirements govern how stored account data and cardholder data should be stored. The most direct link to secure coding is cryptography, aligned to the 2021 OWASP Top Ten A2 and A8, covering topics such as information exposure, random number generation, hashing, encryption, MAC and digital signatures, as well as using certificates with Public Key Infrastructure (PKI), and secure communication protocols. 

PCI DSS 4.0 strengthens the requirement by mandating the use of up-to-date encryption protocols, most importantly prescribing the use of only TLS 1.2 or 1.3. It also enhances key management practices, encourages active monitoring and detection mechanisms, and provides guidelines for securing new technologies, including wireless networks. 

Requirement 6: Secure software development 

This requirement is at the core of secure coding within PCI DSS. Starting off from the need of setting up and maintaining a Secure Software Development Lifecycle, relevant secure coding topics include security by design (OWASP Top Ten 2021, A4), input validation, injection (A3), Cross-Site Scripting, vulnerability management and using vulnerable components (A6), Server Side Request Forgery (A9), as well as general software security weakness categories, such as XML and JSON security, code quality and error handling. 

Comparing Requirement 6 we can see that while PCI DSS 3.2.1 did include requirements for secure coding practices, PCI DSS 4.0 places a stronger emphasis on incorporating security into each phase of the software development lifecycle, even suggesting some well-known methodologies for setting up a secure SDL, like Open SAMM, BSIMM or SafeCode (Requirement 6.2.1). 

The secure coding guidelines in PCI DSS 4.0 are more detailed and comprehensive compared to those in PCI DSS 3.2.1. The new version provides specific requirements for input validation, authentication and authorization, and error handling and logging, among other practices, emphasizing the importance of “shifting security left”. 

As for the potentially vulnerable dependencies, PCI DSS 4.0 places greater emphasis on maintaining a software inventory and managing vulnerabilities. While PCI DSS 3.2.1 included requirements for patch management and vulnerability scanning, the new version provides more detailed guidance on tracking software components and addressing vulnerabilities in the software supply chain (Requirement 6.3). 

Most importantly, training software development personnel is described in Requirement 6.2.2 in PCI DSS 4.0 in more detail. The need for role-based training is unchanged, and should happen on a yearly basis, which can be provided in-house or by third parties. The curriculum should be aligned to the programming language(s) in use, should deal with both secure design and the implementation, as well as should touch testing techniques and tools. 

Requirement 7: Authorization 

Authorization is positioned #1 on the OWASP Top Ten 2021, titled Broken access control. Possible secure coding topics include missing or improper authorization, failure to restrict URL access, confused deputy (including path traversal, broken horizontal authorization or authorization bypass through user-controlled key), file upload and many others. 

PCI DSS positions authorization with the “need to know” basis, which, together with separation of duties and the principle of least privilege can ensure that no single individual has control over all critical aspects of a transaction or process. Compared to PCI DSS 3.2.1, version 4.0 enhances authorization requirement by introducing just-in-time (JIT) access, which is temporary access based on specific tasks or timeframes. In addition to this, using automated tools is emphasized for regular review of accesses. 

These updates aim to provide more granular and dynamic control over access to system components and cardholder data, ensuring that access is granted strictly based on business need and is continuously monitored and reviewed. 

Requirement 8: Authentication 

Authentication is a key secure coding practice, linking to A7 of the OWASP Top Ten (2021). Topics include authentication techniques, weaknesses, password management and storage, including the implementation of password policies. 

As a general rule, while password-based authentication is assumed to be the most common solution, PCI DSS now encourages the usage of more modern, user-friendly authentication practices, such as tokens, smart cards, or biometrics (Requirement 8.3.1). 

The introduction of Requirement 8 in PCI DSS 4.0 now explicitly mentions NIST Special Publication 800-63, Digital Identity Guidelines, stating that it provides additional information. Nevertheless, PCI DSS still deviates in some details from this document. 

The most interesting observations can be made when comparing the password management policies between PCI DSS 3.2.1 and 4.0. There are several key updates, which are mainly aligned to the usage of multi-factor authentication (MFA) and assessing the inherent risks. 

• The minimum password length is increased from the earlier 7 to 12, or just 8 if the system does not support more. This can however be shortened if MFA is used (Requirement 8.3.6). 

• While the usage of both numeric and alphabetic characters is still prescribed, now passphrases and more complex passwords are encouraged in general (8.3.6).  

• The periodic password expiration of 90 days has been shifted to risk-based expiration and can be completely omitted if MFA is used (8.3.9). 

• While users were not allowed to reuse their last 4 passwords earlier, now there is just a general recommendation to prevent password reuse, and the specific numbers may vary based on the risk assessment and implementation of MFA (8.3.7). 

• Account lockout has been increased from 6 to 10 failed attempts. Also, lockout duration was fixed to 30 minutes () or until the user’s identity is confirmed, and that is now configurable based on the risk and context (8.3.4). 

Requirement 10: Logging and monitoring 

This requirement can be mapped to A9 of the OWASP Top Ten. Aligned to that, topics include logging, monitoring, anti-malware (anti-virus) software, intrusion detection and prevention, and firewalls, including Web Application Firewalls (WAFs). 

PCI DSS 4.0 enhanced this requirement by incorporating more detailed logging requirements, emphasizing automated and centralized logging solutions, strengthening log protection measures, and integrating monitoring with incident response processes. These updates aim to provide more comprehensive and effective tracking, monitoring, and response to access events and security incidents. 

Requirement 11: Security testing 

PCI DSS 4.0 mandates regular code reviews and vulnerability assessments to identify and remediate security weaknesses in software applications. These practices help ensure that vulnerabilities are detected and addressed before software is deployed in a production environment, aligned to the “shift left” principle. 

While PCI DSS 3.2.1 recommended code reviews and vulnerability assessments, the new version mandates a combination of manual and automated reviews, as well as static and dynamic analysis, integrated into the CI/CD pipeline to identify and address vulnerabilities more efficiently. It also emphasizes the importance of regular updates and monitoring to address evolving security threats in dependencies. 

Conclusion 

Building on the foundation established by PCI DSS 3.2.1, PCI DSS 4.0 introduces significant updates to enhance software security and promote secure coding practices. The new version emphasizes the importance of integrating security into the entire software development lifecycle, conducting comprehensive code reviews and testing, and implementing robust secure coding practices. Additionally, PCI DSS 4.0 places greater emphasis on maintaining a software inventory, managing vulnerabilities, and securing the configuration of software applications and systems. 

Organizations transitioning from PCI DSS 3.2.1 to PCI DSS 4.0 must review and update their software development practices meeting the new requirements. By embracing the changes introduced in PCI DSS 4.0, organizations can better protect cardholder data and enhance the security of their software applications in an ever-evolving threat landscape. 

Despite the remarkable changes in the standard, one requirement is solid as a rock. Developers should be trained in secure software design and secure coding techniques on a yearly basis; they should stay knowledgeable about best practices, specifically in the context of their job function and their development language and framework. Check out our relevant course to learn more about how we can help you not only to tick the box of Requirement 6.2.2, but to really foster secure coding literacy in you organization.