4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
Only trusted keys and certificates are accepted.
The protocol in use only supports secure versions or configurations.
The encryption strength is appropriate for the encryption methodology in use.
Examples of open, public networks include but are not limited to:
• The Internet
• Wireless technologies, including 802.11 and Bluetooth
• Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)
• General Packet Radio Service (GPRS)
• Satellite communications
4.1.a Identify all locations where cardholder data is transmitted or received over open, public networks. Examine documented standards and compare to system configurations to verify the use of security protocols and strong cryptography for all locations.
4.1.b Review documented policies and procedures to verify processes are specified for the following:
- For acceptance of only trusted keys and/or certificates
- For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported)
- For implementation of proper encryption strength per the encryption methodology in use
4.1.c Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all cardholder data is encrypted with strong cryptography during transit.
4.1.d Examine keys and certificates to verify that only trusted keys and/or certificates are accepted.
4.1.e Examine system configurations to verify that the protocol is implemented to use only secure configurations and does not support insecure versions or configurations.
4.1.f Examine system configurations to verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.)
4.1.g For TLS implementations, examine system configurations to verify that TLS is enabled whenever cardholder data is transmitted or received.
For example, for browser-based implementations:
• “HTTPS” appears as the browser Universal Record Locator (URL) protocol, and
• Cardholder data is only requested if “HTTPS” appears as part of the URL.
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.
Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data. Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted.
Note that some protocol implementations (such as SSL, SSH v1.0, and early TLS) have known vulnerabilities that an attacker can use to gain control of the affected system. Whichever security protocol is used, ensure it is configured to use only secure versions and configurations to prevent use of an insecure connection—for example, by using only trusted certificates and supporting only strong encryption (not supporting weaker, insecure protocols or methods).
Verifying that certificates are trusted (for example, have not expired and are issued from a trusted source) helps ensure the integrity of the secure connection.
Generally, the web page URL should begin with “HTTPS” and/or the web browser display a padlock icon somewhere in the window of the browser. Many TLS certificate vendors also provide a highly visible verification seal— sometimes referred to as a “security seal,”
“secure site seal,” or “secure trust seal”)—which may provide the ability to click on the seal to reveal information about the website.
Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.)
Note: SSL/early TLS is not considered strong cryptography and may not be used as a security control, except by POS POI terminals that are verified as not being susceptible to known exploits and the termination points to which they connect as defined in Appendix A2.