PCI DSS Requirement 4 - Changes from v3.2.1 to v4.0 Explained

Published on : 24 Jan 2024


PCI DSS Requirement 4

Welcome back to our ongoing series on the Payment Card Industry Data Security Standard (PCI DSS). In our previous posts, we’ve covered the various requirements of this critical security standard. Today, we’re going to delve into Requirement 4, which focuses on protecting cardholder data with strong cryptography during transmission over open, public networks. So, let’s get started! To learn more about the other requirements of PCI DSS, check out our comprehensive guide on the “12 requirements of PCI DSS.”

Understanding Requirement 4 

PCI DSS Requirement 4 emphasizes the use of robust cryptography to safeguard data confidentiality, integrity, and non-repudiation, especially when transmitting Primary Account Number (PAN) over accessible networks, including untrusted and public ones. 

Malicious individuals often exploit misconfigured wireless networks and vulnerabilities in outdated encryption and authentication protocols to gain access to cardholder data environments (CDE). Networks that store, process, or transmit cardholder data naturally fall within the PCI DSS scope and must be assessed accordingly. 

Also Read : PCI DSS Requirement 3

 

Requirement 4 pertains to PAN transmissions unless otherwise specified. Protection can be achieved by encrypting the data prior to transmission, the session during transmission, or both. Although not mandatory, it is advisable to apply robust cryptography at both the data and session levels. 

PCI DSS v3.2.1 PCI DSS v4.0
4.1

Implement robust cryptographic methods and security protocols to protect sensitive cardholder data when transmitted over open, public networks. This includes:



-> Acceptance is limited to trusted keys and certificates.

-> The employed protocol supports only secure versions or configurations.

-> The strength of encryption is suitable for the encryption technique in use.


Open, public networks can be, but are not limited to, the following:

- The Internet

- Wireless technologies, such as 802.11 and Bluetooth

- Cellular technologies, like Global System for Mobile communications (GSM), Code division multiple access (CDMA) General Packet Radio Service (GPRS)

- Satellite communications

Testing Procedures:

4.1.a

Pinpoint all areas where cardholder data is transmitted or received over open, public networks. Scrutinize documented standards and juxtapose them with system configurations to ensure the application of security protocols and potent cryptography in all areas.

4.1.b

Scrutinize documented policies and procedures to ensure that processes are outlined for the following:

-> Only trusted keys and/or certificates are accepted.

-> The protocol in use is configured to support only secure versions and configurations and does not support insecure ones.

-> The encryption strength is suitable for the encryption method being used.

4.1.c

Select and monitor a subset of real-time inbound and outbound transmissions (for example, by observing system processes or network traffic) to ensure that all cardholder data is encrypted with potent cryptography while in transit.

4.1.d

Inspect keys and certificates to ensure that only trusted keys and/or certificates are accepted.

4.1.e

Review system configurations to ensure that the protocol is configured to use only secure settings and does not support insecure versions or configurations.

4.1.f

Review system configurations to ensure that the appropriate encryption strength is applied for the encryption method in use. (Refer to vendor recommendations/best practices.)

4.1.g

For TLS implementations, review system configurations to ensure that TLS is enabled whenever cardholder data is transmitted or received. For example, for browser-based implementations:

-> The browser Universal Record Locator (URL) protocol displays “HTTPS”, and

-> Cardholder data is only requested if “HTTPS” is part of the URL

4.2.1.a

Review documented policies and procedures and conduct interviews with personnel to ensure processes are defined to include all elements specified in this requirement.



4.2.1.b

Inspect system configurations to ensure that robust cryptography and security protocols are implemented in accordance with all elements specified in this requirement.



4.2.1.c

Review cardholder data transmissions to ensure that all PAN is encrypted with robust cryptography when it is transmitted over open, public networks.



4.2.1.d

Review system configurations to ensure that keys and/or certificates that cannot be verified as trusted are rejected.
New requirement:

4.1.2

The tasks and responsibilities associated with executing activities in Requirement 4 are documented, assigned, and understood.

Testing Procedures:

4.1.2.a

Evaluate documentation to ensure that the descriptions of tasks and responsibilities for executing activities in Requirement 4 are documented and assigned.

4.1.2.b

Interview personnel tasked with executing activities in Requirement 4 to ensure that tasks and responsibilities are assigned as documented and are understood.

New requirement:

4.2.1

Robust cryptography and security protocols are utilized as follows to secure PAN during transmission over open, public networks:

-> Acceptance is limited to trusted keys and certificates.

-> Certificates used to secure PAN during transmission over open, public networks are confirmed to be valid and are not expired or revoked. This item is best practice until its effective date; please refer to the notes below for applicability details.

-> The protocol in use only supports secure versions or configurations and does not allow fallback to, or use of insecure versions, algorithms, key sizes, or implementations.

-> The encryption strength is appropriate for the encryption technique in use.

Testing Procedures:

4.2.1.a

Review documented policies and procedures and conduct interviews with personnel to ensure processes are defined to include all elements specified in this requirement.


4.2.1.b

Inspect system configurations to ensure that robust cryptography and security protocols are implemented in accordance with all elements specified in this requirement.


4.2.1.c

Review cardholder data transmissions to ensure that all PAN is encrypted with robust cryptography when it is transmitted over open, public networks.


4.2.1.d

Review system configurations to ensure that keys and/or certificates that cannot be verified as trusted are rejected.

New requirement:

4.2.1.1

An up-to-date log of the entity’s trusted keys and certificates, utilized to safeguard PAN during transmission, is maintained.


Testing Procedures:

. 4.2.1.1.a

Evaluate documented policies and procedures to ensure that processes are established for the entity to maintain a log of its trusted keys and certificates.



. 4.2.1.1.b

Examine the log of trusted keys and certificates to ensure that it is consistently updated.

 

You can also watch the video on PCI DSS Requirement 4:

Conclusion: 

We trust that this blog has provided you with comprehensive and technical insights into the changes in PCI DSS v4.0, specifically Requirement 4. We invite you to explore our website for more in-depth knowledge about PCI DSS v4.0. At VISTA InfoSec, we have been committed to delivering profound knowledge in the field of Cyber Security for over three decades. Our reputation as a trusted Cyber Security consultancy is a testament to our dedication and expertise.

In our commitment to continuous learning and sharing, we are excited to announce that we will be publishing more technical blogs focusing on Requirement 5 and other upcoming changes in PCI DSS v4.0. Stay tuned for these updates as we continue to delve deeper into the intricacies of Cyber Security standards. Thank you for choosing us as your guide in this journey of learning.

Lets us help you

Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.

We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.

We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.

We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.

Narendra Sahoo
Narendra Sahoo

Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.