4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following:
[ul]
[li]Only trusted keys and certificates are accepted.[/li][li]The protocol in use only supports secure versions or configurations.[/li][li]The encryption strength is appropriate for the encryption methodology in use.[/li][/ul]
Examples of open, public networks include but are not limited to:
[ul]
[li]The Internet[/li][li]Wireless technologies, including[/li][li]802.11 and Bluetooth[/li][li]Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA)[/li][li]General Packet Radio Service (GPRS).[/li][li]Satellite communications. [/li][/ul]
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. 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.
4.1.b Review documented policies and procedures to verify processes are specified for the following:
[ul]
[li]For acceptance of only trusted keys and/or certificates[/li][li]For the protocol in use to only support secure versions and configurations (that insecure versions or configurations are not supported)[/li][li]For implementation of proper encryption strength per the encryption methodology in use[/li][/ul]
4.1.c Select and observe a sample of inbound and outbound transmissions as they occur 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 SSL/TLS implementations, examine system configurations to verify that SSL/TLS is enabled whenever cardholder data is transmitted or received.
For example, for browser-based implementations:
[ul]
[li]“HTTPS” appears as the browser Universal Record Locator (URL) protocol, and[/li][li]Cardholder data is only requested if “HTTPS” appears as part of the URL.[/li][/ul]
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 v2.0, SSH v1.0 and TLS 1.0) 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, TLS v1.1, or later, certificates obtained from a recognized, public certificate authority and supporting only strong encryption, may be considered.
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 SSL 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