Requirement 4: Encrypt transmission of cardholder data across open, public networks

The detailed requirements in this section are relevant to HCL Commerce. Review each point carefully.

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:
  • 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 that are in scope of the PCI DSS are:
  • 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.

All payments in HCL Commerce are submitted via SSL requests.

For information on controlling and protecting HCL Commerce Payment Plugin Controller, see Payment plug-in specification

To meet the requirements of the PCI-DSS, you must disable weak keys and protocol implementations (such as SSL v2.0, SSL v3.0, SSH v1.0, TLS 1.0, and TLS 1.1) that have known vulnerabilities on your Web server. These encryption types are considered too weak for PCI-DSS compliance. Instead, you should use stronger implementations like TLS 1.2 or higher.
IBM HTTP Server

httpd.conf is updated as needed each release to disable weak ciphers.

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.

Although the network itself is transparent to HCL Commerce, it is important to protect your wireless network from intrusion. An unsecured wireless network could allow an attacker to circumvent your other security measures.

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

HCL Commerce does not provide any default capability to send the PAN by e-mail.

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.

The merchant is responsible for documenting and communicating the security policies and operational procedures to all affected parties.