Welcome back to our series on PCI DSS Requirement Changes from v3.2.1 to v4.0. Today, we’re discussing Requirement 6, which is crucial for protecting cardholder data. It mandates the use of vendor-supplied security patches and secure coding practices for in-house developed applications. These measures help mitigate vulnerabilities that hackers could exploit. The requirement also emphasizes the importance of vigilance in identifying and remediating vulnerabilities. So, let’s get started! To learn more about the other requirements of PCI DSS, check out our comprehensive guide on the “12 requirements of PCI DSS.”
Below, we provide an explanation of the changes made in Requirement 6 from v3.2.1 to v4.0:
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.3 focused on the development of both internal and external software applications, including web-based administrative access to applications. - 6.3.a: Verify that software-development processes align with industry standards/best practices. - 6.3.b: Ensure information security is integrated throughout the development life cycle. - 6.3.c: Confirm that software applications comply with PCI DSS. - 6.3.d: Interview developers to ensure these processes are implemented. | In PCI DSS v4.0, Requirement 6.2.1 focuses on secure development of “bespoke and custom software”, replacing the terms “internal and external”. - The software should be developed based on industry standards and/or best practices for secure development. - The development should be in accordance with PCI DSS (Payment Card Industry Data Security Standard). This includes aspects like secure authentication and logging. - Information security issues should be considered during each stage of the software development lifecycle. - The requirement mandates that software development procedures must be documented and examined to ensure that all security considerations are integrated into every stage of the development process. This ensures a clear documentation trail of security practices. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.5 addressed common coding vulnerabilities in software-development processes. - It required developers to be trained at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities. -It also required applications to be developed based on secure coding guidelines. -The verification process involved examining software-development policies and procedures, records of training, and verifying that processes are in place to protect applications from certain vulnerabilities. | The updated requirement of PCI DSS v4.0 is now 6.2.2. It focuses on "bespoke and custom software" and mandates annual training for developers working on such projects. This training covers software security related to their roles, development languages, secure design, and coding techniques. Additionally, it includes learning how to use security testing tools for detecting software vulnerabilities. The verification process involves checking development procedures, training records, and interviewing personnel to ensure relevant training in line with job functions and languages. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| PCI DSS v3.2.1 Requirement 6.3.2 mandated review of custom code before release to identify potential vulnerabilities. - It required code changes to be reviewed by others than the author, following secure coding practices. - Code had to adhere to secure coding guidelines and any corrections were to be made before release. - The results of the code review had to be approved by management. - Verification involved examining software-development procedures and interviewing personnel. | PCI DSS v4.0, Requirement 6.3.2 is renumbered to 6.2.3 with a new sub-requirement 6.2.3.1 for manual code reviews. It now specifically targets “bespoke and custom software” for review before release to identify and correct potential coding vulnerabilities. - Code reviews still follow secure coding guidelines and look for both existing and emerging software vulnerabilities. - Corrections are implemented before release. - Verification involves examining procedures, evidence of changes, and interviewing personnel. - Manual code reviews have similar requirements under 6.2.3.1. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| PCI DSS v3.2.1 Requirement 6.5.1 – 6.5.10 6.5.1 Injection Flaws: - Prevent attacks where hackers modify code in your system with bad data. - Validate all user input to block tampering attempts. - Use database safeguards (parameterized queries) to stop injections. 6.5.2 Buffer Overflows: - Prevent memory misuse attackers can exploit to run malicious code. - Check memory boundaries when handling data. - Limit the length of data your system accepts. 6.5.3 Insecure Cryptographic Storage: - Protect encryption keys and sensitive data they can access. - Use strong encryption, prevent flawed implementations. 6.5.5 Improper Error Handling: - Don't give away system details with specific error messages. - Show users generic errors to prevent information leaks attackers can exploit. 6.5.6 High-Risk Vulnerabilities: - Fix serious weaknesses ASAP that attackers could use to harm your system. - Identify weaknesses: See PCI DSS Requirement 6.1 for this process. 6.5.7 Cross-Site Scripting (XSS): - Stop attackers injecting code into your websites that can harm users. - Validate and sanitize data coming from users, don't include it directly. 6.5.8 Improper Access Control: - Prevent unauthorized access to system data and functions. - Check user rights at every access point. - Secure file and code to stop users bypassing website checks. 6.5.9 Cross-Site Request Forgery (CSRF): - Stop websites tricking users into performing actions they don't mean to. - Don't rely solely on cookies for authorization, add further checks. 6.5.10 Broken Authentication and Session Management: - Protect user sessions from hijacking. - Secure cookies, prevent exposing session IDs, timeout inactive sessions. | PCI DSS v4.0 Requirement 6.2.4 emphasizes a holistic approach to software security, requiring organizations to prevent: Injection Attacks: - Prevent attackers from sneaking malicious commands into your system by masquerading them as normal data (e.g., injecting SQL code into a website form). Attacks on Data Structures: - Prevent attackers from manipulating memory in ways that allow them to run unauthorized code (e.g., buffer overflows). Attacks on Cryptography Usage: - Protect against attempts to break weak encryption, flawed implementations, or exploit vulnerable cryptographic modes. Attacks on Business Logic: - Prevent attackers from abusing application functions designed for normal use (e.g., manipulating client-side web code, circumventing API safeguards, exploiting features beyond their intended purposes). This includes attacks like XSS and CSRF. Attacks on Access Control: - Securely implement login systems, permissions checks, and any mechanism responsible for granting users access - attackers exploit flaws here to gain unauthorized control. High-Risk Vulnerabilities: - Prevent any serious weaknesses known within your system as discovered in the vulnerability process outlined in Requirement 6.3.1. |
Organizations are required to maintain documented procedures that ensure their developers are well-versed in understanding potential threats. Moreover, developers should actively employ techniques to counter these threats in the software they build.
In a broader perspective, version 4.0 mandates a flexible, risk-based approach to software security. This approach should be tailored to the organization’s unique environment and associated risks. The primary objective is to address common software vulnerabilities throughout the development process.
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.1: Organizations need to have a system in place where they can spot and rank security issues. They should be using trustworthy sources for this. And to make sure everything is on track; they should check their policies and have a chat with the people responsible. Requirement 6.2: Organizations need to shield their systems from known issues by using patches provided by the vendor. And if a patch is critical, they should be installing it within a month. To ensure this is happening, they should be checking their policies and doing some system checks. | Requirement 6.3.1: Expands on v3.2.1’s Requirement 6.1 by specifying sources for identifying new security vulnerabilities, including alerts from CERTs. Introduces a risk ranking system for all high-risk or critical vulnerabilities. Now covers vulnerabilities for bespoke, custom, and third-party software. Requirement 6.3.2: New requirement for maintaining an inventory of bespoke, custom, and third-party software components. This inventory aids in vulnerability and patch management. Requirement 6.3.3: Builds on v3.2.1’s Requirement 6.2 by specifying that all system components must be protected from known vulnerabilities by installing applicable security patches/updates within set timelines. |
The requirement 6.3 of PCI DSS v4.0 provides more detailed guidelines for identifying and managing security vulnerabilities, maintaining software inventories, and installing security patches/updates. It expands the scope to include bespoke, custom, and third-party software components.
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.6 focused on addressing new threats and vulnerabilities. - It required either a manual or automated application vulnerability security assessment at least annually and after any changes, or the installation of an automated technical solution that continually checks all traffic. | Requirement 6.4.1 builds upon this by introducing more specific guidelines: - The frequency of reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods is now specified to be at least once every 12 months and after significant changes. - The requirement now explicitly states that the review should be conducted by an entity that specializes in application security. - It includes, at a minimum, all common software attacks in Requirement 6.2.4. - All vulnerabilities must now be ranked according to Requirement 6.3.1. - All vulnerabilities must be corrected, and the application must be re-evaluated after the corrections. - If an automated technical solution is installed that continually detects and prevents web-based attacks, it must be actively running and up to date, generate audit logs, and be configured to either block web-based attacks or generate an alert that is immediately investigated. |
| PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|
| Requirement 6.3.1: Before activating or releasing an application, all development-related accounts, user IDs, and passwords must be removed to prevent misuse. 6.4: Organizations must have strict change control procedures, which ensure: - 6.4.1: Development/test environments are strictly isolated from production systems with access controls preventing unauthorized transitions. - 6.4.2: Personnel in development/test roles are different from those in production, enforcing accountability. - 6.4.3: Live card data (PANs) are never used in development/test environments to prevent compromise. - 6.4.4: All test data and test accounts are removed before a system goes into production to prevent lingering vulnerabilities. - 6.4.5: Documented change control procedures must include these elements to track and secure all changes: * Reason for the change and a full description * Analysis of security impact before implementation * Approval by authorized personnel only * Testing to ensure change doesn't weaken security * Procedures for rolling back a change if it causes problems - 6.4.6: After major changes, the system MUST be re-verified for compliance with all applicable PCI DSS rules with updated documentation. | Requiement 6.5.1: All production system changes must follow documented procedures. These procedures must ensure: - Clear change justification & description. - Documented analysis of security risks introduced by the change. - Authorization by approved personnel. - Testing to prevent security compromise from the change. - For custom code: Verification of compliance with Requirement 6.2.4 (secure coding practices). - Processes to handle failures, ensuring a return to secure operation. 6.5.2: When significant system changes occur, organizations must: Re-verify that they comply with all relevant PCI DSS requirements Update all documentation to accurately represent the changed systems 6.5.3: Production (handling live card data) must be strictly isolated from pre-production (dev/test) environments. This separation is enforced via access controls. 6.5.4: Different personnel must manage production vs. pre-production environments. This promotes accountability so unauthorized changes don't reach production. 6.5.5: Live PANs (card numbers) should never be used in pre-production, as this risks data exposure. Exception: When a pre-production environment is fully secured within the Cardholder Data Environment (CDE) in line with all PCI DSS rules. 6.5.6: It's essential to remove all test data and test accounts from systems before transitioning them into production to prevent later security lapses. |
PCI DSS v4.0 requirement 6.5 introduces several important changes aimed at improving security for organizations involved in handling cardholder data:
- Expanded Change Control: All system changes must follow secure, robust procedures.
- Compliance Re-verification: After significant changes, systems must be checked against all relevant PCI DSS standards.
- Enforced Isolation: Stricter separation between development/test and production environments.
- Accountability Focus: Separate personnel managing different environments promote responsibility.
New Requirements:
Requirement 6.1.2
This requirement ensures everyone involved in security-related tasks knows their exact role and what’s expected of them. (It should be implemented immediately for v4.0 Assessments and it’s applicable to all entities.)
- Clear job descriptions should outline security responsibilities.
- Assign appropriate personnel to these roles officially.
- Communicate with staff to ensure they comprehend their security duties.
Requirement 6.3.2:
You need to track all the software you use, especially custom-made software, to fix security issues quickly. (This requirement is a best practice until 31 March 2025.)
- Maintain a comprehensive software list, encompassing custom and third-party components.
- Regularly review it for security vulnerabilities, applying patches.
- Compare the list with official documentation to ensure accuracy and completeness.
Requirement 6.4.2:
Protect your website from online attacks with specialized software. (This requirement is a best practice until 31 March 2025.)
- Employ specialized software, such as a Web Application Firewall (WAF), to safeguard against web attacks.
- Deploy it for public-facing websites.
- Keep the software running and up to date, logging its detections.
- Configure it for either automatic blocking or immediate alerts for investigation.
Requirement 6.4.3:
Control the scripts running on your payment pages to keep them secure. (This requirement is a best practice until 31 March 2025.)
- Establish clear guidelines for authorized scripts on payment pages.
- Verify scripts’ integrity and maintain a list with justifications for each script’s necessity.
- Implement official script management procedures within the company.
- Monitor staff adherence through interviews and record checks.
Conclusion:
In summary, PCI DSS v4.0 Requirement 6 emphasizes secure software development and vulnerability management with significant enhancements. Defined roles and responsibilities, alignment of custom code review and developer training, consolidation of secure coding practices, separate requirement for vulnerability management, elimination of manual web app assessments, and new mandates for change control and script management aim to strengthen system security. Robust patch management, strict change control, and secure coding practices are essential for protecting cardholder data. Visit VISTA InfoSec’s website for more information on PCI DSS Requirement 6 and related topics. Stay informed and secure.
Lets us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
