Impact of the new PCI 4.0 on the former 3.2.1 requirement 6 are in the form of : Reformulation, clarification and amendements and removal
Terminology:
New controls: 4 new controls:
4.0 - 6.4.3 Require to protect payment pages on the the consumer’s browser. It applies primarily to merchant e-commerce and/or processor gateways and virtual terminals which facilitate entry of cardholder information for authorization.
4.0 - 6.4.2 Requires deployment of an automated technical solution that continually detects and prevents web-based attacks as of 2025.
4.0 - 6.3.2 Require organizations to manage, create an inventory and document specific application components and services utilized by an application. Organizations also need need to invest in tools capable of alerting on component vulnerabilities to meet Requirement 4.0 - 6.3.3.
4.0 - 6.1.2 Require to document, assign and understand Roles and responsibilities for performing activities in Requirement 6.
Amended:
4.0 - 6.3.1 Require that new security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs) and that Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.
4.0 - 6.3.3 Require that applicable non critical or high-security security patches/updates be installed within an appropriate time frame as determined by organizations.
Removed:
3.2.1 - 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
- The term "relevant" is replaced by "applicable"
- the terms "Development environment" and "test environment" are replaced by "Pre-production environments"
- the term "custom code" is replaced by "bespoke and custom software"
New controls: 4 new controls:
4.0 - 6.4.3 Require to protect payment pages on the the consumer’s browser. It applies primarily to merchant e-commerce and/or processor gateways and virtual terminals which facilitate entry of cardholder information for authorization.
4.0 - 6.4.2 Requires deployment of an automated technical solution that continually detects and prevents web-based attacks as of 2025.
4.0 - 6.3.2 Require organizations to manage, create an inventory and document specific application components and services utilized by an application. Organizations also need need to invest in tools capable of alerting on component vulnerabilities to meet Requirement 4.0 - 6.3.3.
4.0 - 6.1.2 Require to document, assign and understand Roles and responsibilities for performing activities in Requirement 6.
Amended:
4.0 - 6.3.1 Require that new security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs) and that Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.
4.0 - 6.3.3 Require that applicable non critical or high-security security patches/updates be installed within an appropriate time frame as determined by organizations.
Removed:
3.2.1 - 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
Detailed analysis
Title
3.2.1 - Develop and maintain secure systems and applications
4.0 - Develop and Maintain Secure Systems and Software
3.2.1 - Develop and maintain secure systems and applications
4.0 - Develop and Maintain Secure Systems and Software
3.2.1 - 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.
Change: Reformulation, Clarification and amendement
4.0 - 6.3.1 Security vulnerabilities are identified and managed as follows:
Change: Reformulation, Clarification and amendement
4.0 - 6.3.1 Security vulnerabilities are identified and managed as follows:
- New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).
- Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
- Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.
- Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.
3.2.1 - 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor- supplied security patches. Install critical security patches within one month of release.
Change: Reformulation + Amendements/Clarification
4.0 - 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
Change: Reformulation + Amendements/Clarification
4.0 - 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
- Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
- All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).
3.2.1 - 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:
Change: Reformulation.
4.0 - 6.2.1 Bespoke and custom software are developed securely, as follows:
- In accordance with PCI DSS (for example, secure authentication and logging)
- Based on industry standards and/or best practices.
- Incorporating information security throughout the software-development life cycle
Change: Reformulation.
4.0 - 6.2.1 Bespoke and custom software are developed securely, as follows:
- Based on industry standards and/or best practices for secure development.
- In accordance with PCI DSS (for example, secure authentication and logging).
- Incorporating consideration of information security issues during each stage of the software development lifecycle.
3.2.1 - 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
Change: Removed
Change: Removed
3.2.1 - 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:
Change: Reformulation + Split + Amendement
4.0 - 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:
4.0 - 6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:
- Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.
- Code reviews ensure code is developed according to secure coding guidelines
- Appropriate corrections are implemented prior to release.
- Code-review results are reviewed and approved by management prior to release.
Change: Reformulation + Split + Amendement
4.0 - 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:
- Code reviews ensure code is developed according to secure coding guidelines.
- Code reviews look for both existing and emerging software vulnerabilities.
- Appropriate corrections are implemented prior to release.
4.0 - 6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:
- Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.
- Reviewed and approved by management prior to release.
3.2.1 - 6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls.
Change: Reformulation
4.0 - 6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls.
Change: Reformulation
4.0 - 6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls.
3.2.1 - 6.4.2 Separation of duties between development/test and production environments
Change: Reformulation and clarification
4.0 - 6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
Change: Reformulation and clarification
4.0 - 6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
3.2.1 - 6.4.3 Production data (live PANs) are not used for testing or development
Change: Reformulation and clarification.
4.0 - 6.5.5 Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements.
Change: Reformulation and clarification.
4.0 - 6.5.5 Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements.
3.2.1 - 6.4.4 Removal of test data and accounts from system components before the system becomes active / goes into production.
Change: Reformulation.
4.0 - 6.5.6 Test data and test accounts are removed from system components before the system goes into production.
Change: Reformulation.
4.0 - 6.5.6 Test data and test accounts are removed from system components before the system goes into production.
3.2.1 - 6.4.5 Change control procedures must include the following:
3.2.1 - 6.4.5.1 Documentation of impact.
3.2.1 - 6.4.5.2 Documented change approval by authorized parties.
3.2.1 -6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system.
3.2.1 -6.4.5.4 Back-out procedures.
Change: reformulation + Merge + Amendements
4.0 - 6.5.1 Changes to all system components in the production environment are made according to established procedures that include:
3.2.1 - 6.4.5.1 Documentation of impact.
3.2.1 - 6.4.5.2 Documented change approval by authorized parties.
3.2.1 -6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system.
3.2.1 -6.4.5.4 Back-out procedures.
Change: reformulation + Merge + Amendements
4.0 - 6.5.1 Changes to all system components in the production environment are made according to established procedures that include:
- Reason for, and description of the change.
- Documentation of security impact.
- Documented change approval by authorized parties.
- Testing to verify that the change does not adversely impact system security.
- For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.
- Procedures to address failures and return to a secure state.
3.2.1 - 6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.
Change: Reformulation.
4.0 - 6.5.2 Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.
Change: Reformulation.
4.0 - 6.5.2 Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.
3.2.1 - 6.5 Address common coding vulnerabilities in software-development processes as follows:
Change: Reformulation, Clarification, Amendement and Split
4.0 - 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:
- Train developers at least annually in up- to-date secure coding techniques, including how to avoid common coding vulnerabilities.
- Develop applications based on secure coding guidelines.
Change: Reformulation, Clarification, Amendement and Split
4.0 - 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:
- On software security relevant to their job function and development languages.
- Including secure software design and secure coding techniques.
- Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.
3.2.1 6.5.1 - 6.5.10 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.
6.5.2 Buffer overflows
6.5.3 Insecure cryptographic storage
6.5.4 Insecure communications
6.5.5 Improper error handling
6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
6.5.7 Cross-site scripting (XSS)
6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).
6.5.9 Cross-site request forgery (CSRF)
6.5.10 Broken authentication and session management.
Change: clarification + bundle
Moved requirements for addressing common coding vulnerabilities to align all software development content under Requirement 6.2.
Combined methods to prevent or mitigate common software attacks into a single requirement and generalized the language describing each type of attack.
4.0 - 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:
6.5.2 Buffer overflows
6.5.3 Insecure cryptographic storage
6.5.4 Insecure communications
6.5.5 Improper error handling
6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).
6.5.7 Cross-site scripting (XSS)
6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions).
6.5.9 Cross-site request forgery (CSRF)
6.5.10 Broken authentication and session management.
Change: clarification + bundle
Moved requirements for addressing common coding vulnerabilities to align all software development content under Requirement 6.2.
Combined methods to prevent or mitigate common software attacks into a single requirement and generalized the language describing each type of attack.
4.0 - 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:
- Injection attacks, including SQL, LDAP , XPath, or other command, parameter, object, fault, or injection-type flaws.
- Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
- Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.
- Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client- side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
- Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
- Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1
3.2.1 - 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
Change: Clarification + amendements
4.0 - 6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:
• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:
- Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
- Installing an automated technical solution that detects and prevents web- based attacks (for example, a web- application firewall) in front of public- facing web applications, to continually check all traffic.
Change: Clarification + amendements
4.0 - 6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:
• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:
- – At least once every 12 months and after significant changes.
- – By an entity that specializes in application security.
- – Including, at a minimum, all common software attacks in Requirement 6.2.4.
- – All vulnerabilities are ranked in accordance with requirement 6.3.1.
- – All vulnerabilities are corrected.
- – The application is re-evaluated after the corrections
OR
- – Installed in front of public-facing web applications to detect and prevent web- based attacks.
- – Actively running and up to date as applicable.
- – Generating audit logs.
- – Configured to either block web-based attacks or generate an alert that is immediately investigated.
3.2.1 - 6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.
Change: Reformulation.
4.0 - 6.1.1 All security policies and operational procedures that are identified in Requirement 6 are:
• Documented.
Change: Reformulation.
4.0 - 6.1.1 All security policies and operational procedures that are identified in Requirement 6 are:
• Documented.
- Kept up to date.
- In use.
- Known to all affected parties.
3.2.1 - None
Change: NEW.
4.0 - 6.1.2 Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.
Change: NEW.
4.0 - 6.1.2 Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.
3.2.1 - None
Change: NEW
4.0 - 6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
Change: NEW
4.0 - 6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
3.2.1 - None
Change: NEW. This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective. The key update here is that an automated solution is explicitly required ass of 2025.
4.0 - 6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
Change: NEW. This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective. The key update here is that an automated solution is explicitly required ass of 2025.
4.0 - 6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
- Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.
- Actively running and up to date as applicable.
- Generating audit logs.
- Configured to either block web-based attacks or generate an alert that is immediately investigated.
3.2.1 - None
Change: NEW.
4.0 - 6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
Change: NEW.
4.0 - 6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
- A method is implemented to confirm that each script is authorized.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written justification as to why each is necessary.
RSS Feed
