Framework № PCI DSS 4.0 от 01.03.2022

6.4.1
Defined Approach Requirements: 
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: 

OR 

Customized Approach Objective:
Public-facing web applications are protected against malicious attacks. 

Applicability Notes:
This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2. 
This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective. 

Defined Approach Testing Procedures:

Purpose:
Public-facing web applications are those that are available to the public (not only for internal use). These applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. 

Good Practice:
Manual or automated vulnerability security assessment tools or methods review and/or test the application for vulnerabilities. 
Common assessment tools include specialized web scanners that perform automatic analysis of web application protection. 
When using automated technical solutions, it is important to include processes that facilitate timely responses to alerts generated by the solutions so that any detected attacks can be mitigated. 

Examples:
A web application firewall (WAF) installed in front of public-facing web applications to check all traffic is an example of an automated technical solution that detects and prevents web-based attacks (for example, the attacks included in Requirement 6.2.4). WAFs filter and block nonessential traffic at the application layer. A properly configured WAF helps to prevent application-layer attacks on applications that are improperly coded or configured. 
Another example of an automated technical solution is Runtime Application Self-Protection (RASP) technologies. When implemented correctly, RASP solutions can detect and block anomalous behavior by the software during execution. While WAFs typically monitor the application perimeter, RASP solutions monitor and block behavior within the application. 

6.4.2
Defined Approach Requirements: 
For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:

Customized Approach Objective:
Public-facing web applications are protected in real time against malicious attacks. 

Applicability Notes:
This new requirement will replace Requirement 6.4.1 once its effective date is reached. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Public-facing web applications are primary targets for attackers, and poorly coded web applications provide an easy path for attackers to gain access to sensitive data and systems. 

Good Practice:
When using automated technical solutions, it is important to include processes that facilitate timely responses to alerts generated by the solutions so that any detected attacks can be mitigated. Such solutions may also be used to automate mitigation, for example rate-limiting controls, which can be implemented to mitigate against brute-force attacks and enumeration attacks. 

Examples:
A web application firewall (WAF), which can be either on-premise or cloud-based, installed in front of public-facing web applications to check all traffic, is an example of an automated technical solution that detects and prevents web-based attacks (for example, the attacks included in Requirement 6.2.4). WAFs filter and block nonessential traffic at the application layer. A properly configured WAF helps to prevent application-layer attacks on applications that are improperly coded or configured. 

6.4.3
Defined Approach Requirements: 
All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:

Customized Approach Objective:
Unauthorized code cannot be present in the payment page as it is rendered in the consumer’s browser. 

Applicability Notes:
This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties. 
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 

Defined Approach Testing Procedures:

Purpose:
Scripts loaded and executed in the payment page can have their functionality altered without the entity’s knowledge and can also have the functionality to load additional external scripts (for example, advertising and tracking, tag management systems). 
Such seemingly harmless scripts can be used by potential attackers to upload malicious scripts that can read and exfiltrate cardholder data from the consumer browser. 
Ensuring that the functionality of all such scripts is understood to be necessary for the operation of the payment page minimizes the number of scripts that could be tampered with. 
Ensuring that scripts have been explicitly authorized reduces the probability of unnecessary scripts being added to the payment page without appropriate management approval. 
Using techniques to prevent tampering with the script will minimize the probability of the script being modified to carry out unauthorized behavior, such as skimming the cardholder data from the payment page. 

Good Practice:
Scripts may be authorized by manual or automated (e.g., workflow) processes. 
Where the payment page will be loaded into an inline frame (IFRAME), restricting the location that the payment page can be loaded from, using the parent page’s Content Security Policy (CSP) can help prevent unauthorized content being substituted for the payment page. 

Definitions:
“Necessary” for this requirement means that the entity’s review of each script justifies and confirms why it is needed for the functionality of the payment page to accept a payment transaction 

Examples:
The integrity of scripts can be enforced by several different mechanisms including, but not limited to: