Framework № PCI DSS 4.0 от 01.03.2022

4.2.1
Defined Approach Requirements: 
Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from any transmissions over open, public networks. 

Defined Approach Testing Procedures:

Purpose:
Sensitive information must be encrypted during transmission over public networks because it is easy and common for a malicious individual to intercept and/or divert data while in transit. 

Good Practice:
The network and data-flow diagrams defined in Requirement 1 are useful resources for identifying all connection points where account data is transmitted or received over open, public networks. 
While not required, it is considered a good practice for entities to also encrypt PAN over their internal networks, and for entities to establish any new network implementations with encrypted communications. 
PAN transmissions can be protected by encrypting the data before it is transmitted, or by encrypting the session over which the data is transmitted, or both. While it is not required that strong cryptography be applied at both the data level and the session level, it is strongly recommended. If encrypted at the data level, the cryptographic keys used for protecting the data can be managed in accordance with Requirements 3.6 and 3.7. If the data is encrypted at the session level, designated key custodians should be assigned responsibility for managing transmission keys and certificates. 
Some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain access to the cleartext data. It is critical that entities maintain awareness of industry-defined deprecation dates for the cipher suites they are using and are prepared to migrate to newer versions or protocols when older ones are no longer deemed secure. 
Verifying that certificates are trusted helps ensure the integrity of the secure connection. To be considered trusted, a certificate should be issued from a trusted source, such as a trusted certificate authority (CA), and not be expired. Up-to-date Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) can be used to validate certificates. 
Techniques to validate certificates may include certificate and public key pinning, where the trusted certificate or a public key is pinned either during development or upon its first use. Entities can also confirm with developers or review source code to ensure that clients and servers reject connections if the certificate is bad. 
For browser-based TLS certificates, certificate trust can often be verified by clicking on the lock icon that appears next to the address bar. 

Examples:
 Open, public networks include, but are not limited to: 

Further Information:
Vendor recommendations and industry best practices can be consulted for information about the proper encryption strength specific to the encryption methodology in use. 
For more information about strong cryptography and secure protocols, see industry standards and best practices such as NIST SP 800-52 and SP 800-57. 
For more information about trusted keys and certificates, see NIST Cybersecurity Practice Guide Special Publication 1800-16, Securing Web Transactions: Transport Layer Security (TLS) Server Certificate Management. 

4.2.1.1
Defined Approach Requirements: 
An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained. 

Customized Approach Objective:
All keys and certificates used to protect PAN during transmission are identified and confirmed as trusted. 

Applicability Notes:
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:
The inventory of trusted keys helps the entity keep track of the algorithms, protocols, key strength, key custodians, and key expiry dates. This enables the entity to respond quickly to vulnerabilities discovered in encryption software, certificates, and cryptographic algorithms. 

Good Practice:
For certificates, the inventory should include the issuing CA and certification expiration date. 

4.2.1.2
Defined Approach Requirements: 
Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission. 

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from wireless network transmissions. 

Defined Approach Testing Procedures:

Purpose:
Since wireless networks do not require physical media to connect, it is important to establish controls limiting who can connect and what transmission protocols will be used. Malicious users use free and widely available tools to eavesdrop on wireless communications. Use of strong cryptography can help limit disclosure of sensitive information across wireless networks. 
Wireless networks present unique risks to an organization; therefore, they must be identified and protected according to industry requirements. Strong cryptography for authentication and transmission of PAN is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data. 

Good Practice:
Wireless networks should not permit fallback or downgrade to an insecure protocol or lower encryption strength that does not meet the intent of strong cryptography. 

Further Information:
Review the vendor’s specific documentation for more details on the choice of protocols, configurations, and settings related to cryptography 

4.2.2
Defined Approach Requirements: 
PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies. 

Customized Approach Objective:
Cleartext PAN cannot be read or intercepted from transmissions using end-user messaging technologies. 

Applicability Notes:
This requirement also applies if a customer, or other third-party, requests that PAN is sent to them via end-user messaging technologies. 
There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or delete the cardholder data and implement measures to prevent the channel from being used for cardholder data. 

Defined Approach Testing Procedures:

Purpose:
End-user messaging technologies typically can be easily intercepted by packet-sniffing during delivery across internal and public networks. 

Good Practice:
The use of end-user messaging technology to send PAN should only be considered where there is a defined business need. 

Examples:
E-mail, instant messaging, SMS, and chat are examples of the type of end-user messaging technology that this requirement refers to.