...
PCI DSS: Home

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

PCI Security Standards Council

In the last post, we discussed the requirements and best practices to protect stored account data. In this post, we will understand PCI DSS Requirement #4 Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.

Overview

To protect against compromise, PAN must be encrypted during transmission over networks that are easily accessed by malicious individuals, including untrusted and public networks. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targeted by malicious individuals aiming to exploit these vulnerabilities to gain privileged access to cardholder data environments (CDE). Any transmissions of cardholder data over an entity’s internal network(s) will naturally bring that network into scope for PCI DSS since that network stores, processes, or transmits cardholder data. Any such networks must be evaluated and assessed against applicable PCI DSS requirements. It applies to transmissions of PAN unless specifically called out in an individual requirement.

4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented

4.1.1 All security policies and operational procedures are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

4.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

4.2 PAN is protected with strong cryptography during transmission

4.2.1 Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks: • Only trusted keys and certificates are accepted • Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked • The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations • The encryption strength is appropriate for the encryption methodology in use

The network and data-flow diagrams 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. 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.

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

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

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

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.

4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies

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

Key Takeaways

  • The network and data-flow diagrams are useful resources for identifying all connection points where account data is transmitted or received over open, public networks.
  • 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.
  • While it is not required that strong cryptography be applied at both the data level and the session level, it is strongly recommended.
  • 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.
  • To be considered trusted, a certificate should be issued from a trusted source, such as a trusted certificate authority (CA), and not be expired.
  • 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.
Scroll to Top
Seraphinite AcceleratorOptimized by Seraphinite Accelerator
Turns on site high speed to be attractive for people and search engines.