choose sub requirement:

Requirement 4.1

Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) 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.

Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

Effective immediately, new implementations must not use SSL or early TLS.

POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.

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

Testing Procedure

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 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.

4.1.h
For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols:

Confirm the entity has documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS.

4.1.i
For all other environments using SSL and/or early TLS:

Review the documented Risk Mitigation and Migration Plan to verify it includes:

  • Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment;
  • Risk-assessment results and risk-reduction controls in place;
  • Description of processes to monitor for new vulnerabilities associated with SSL/early TLS;
  • Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments;
  • Overview of migration project plan including target migration completion date no later than June 30, 2016.

Guidance

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.)

Regarding use of SSL/early TLS: Entities using SSL and early TLS must work towards upgrading to a strong cryptographic protocol as soon as possible. Additionally, SSL and/or early TLS must not be introduced into environments where they don’t already exist. At the time of publication, the known vulnerabilities are difficult to exploit in POS POI payment environments. However, new vulnerabilities could emerge at any time, and it is up to the organization to remain up-to-date with vulnerability trends and determine whether or not they are susceptible to any known exploits.

Refer to the PCI SSC Information Supplement: Migrating from SSL and Early TLS for further guidance on the use of SSL/early TLS.

Requirement 4.1.1

Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission.

Note: The use of WEP as a security control is prohibited.

Testing Procedure

4.1.1
Identify all wireless networks transmitting cardholder data or connected to the cardholder data environment. Examine documented standards and compare to system configuration settings to verify the following for all wireless networks identified:

  • Industry best practices (for example, IEEE 802.11i) are used to implement strong encryption for authentication and transmission.
  • Weak encryption (for example, WEP, SSL) is not used as a security control for authentication or transmission.

Guidance

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.

Strong cryptography for authentication and transmission of cardholder data is required to prevent malicious users from gaining access to the wireless network or utilizing wireless networks to access other internal networks or data.

Requirement 4.2

Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.).

Testing Procedure

4.2.a
If end-user messaging technologies are used to send cardholder data, observe processes for sending PAN and examine a sample of outbound transmissions as they occur to verify that PAN is rendered unreadable or secured with strong cryptography whenever it is sent via end-user messaging technologies.

4.2.b
Review written policies to verify the existence of a policy stating that unprotected PANs are not to be sent via end-user messaging technologies.

Guidance

E-mail, instant messaging, SMS, and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. Do not utilize these messaging tools to send PAN unless they are configured to provide strong encryption.

Additionally, if an entity requests PAN via end-user messaging technologies, the entity should provide a tool or method to protect these PANs using strong cryptography or render PANs unreadable before transmission.

Requirement 4.3

Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.

Testing Procedure

4.3
Examine documentation and interview personnel to verify that security policies and operational procedures for encrypting transmissions of cardholder data are:

  • Documented,
  • In use, and
  • Known to all affected parties.

Guidance

Personnel need to be aware of and following security policies and operational procedures for managing the secure transmission of cardholder data on a continuous basis.

Goal: Protect stored cardholder data

Requirement 4.0

Encrypt transmission of cardholder data across open, public networks

Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments.