In our exploration of PCI DSS v4.0’s changes, we’ve reached the heart of the matter – Requirement 3: Protect Stored Account Data. While the previous two requirements focused on network and access control, Requirement 3 tackles the crucial issue of securing sensitive cardholder information once it’s captured and stored. 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.”
So, what’s the purpose of Requirement 3?
It boils down to minimizing the risk of data breaches and maximizing the security of cardholder information. This is achieved through a multi-pronged approach:
-
Data Encryption:
Requirement 3 mandates the use of strong cryptographic controls such as encryption for stored cardholder data. This means that even if a malicious actor gains access to the data, they would not be able to read or use it without the decryption keys.
-
Limited Data Storage:
Organizations are encouraged to limit the amount of stored cardholder data to the minimum necessary for business function. This reduces the potential damage in case of a data breach.
-
Masking:
When displaying cardholder data, Requirement 3 stipulates that only the minimum necessary amount of data should be shown. For example, only the last four digits of a PAN may be displayed.
-
Key Management:
Requirement 3 also covers the secure management of cryptographic keys used for encryption of cardholder data. This includes secure storage, periodic key changes, retirement of old or suspected compromised keys, and prevention of unauthorized key substitutions.
In essence, Requirement 3 aims to create a data security fortress around cardholder information. By minimizing its presence, rendering it unreadable when not actively used, and rigorously validating its protection, organizations significantly reduce the risk of data breaches and ensure the trust of their customers.
Changes in Requirement 3 from PCI DSS v3.2.1 to v4.0:
Now, let’s delve into the modifications introduced in Requirement 3 from v3.2.1 to v4.0.
[table id=36 /]
Also Read : PCI DSS Requirement 2
New requirement:
3.5.1.1 The process of rendering PAN unrecognizable involves using keyed cryptographic hashes that cover the entire PAN. This process is governed by key-management procedures and protocols that align with Requirements 3.6 and 3.7.
- 3.5.1.1.a Review the documentation detailing the hashing method employed to render PAN unrecognizable. This includes information about the vendor, system/process type, and encryption algorithms (where applicable). The review should confirm that the hashing method results in keyed cryptographic hashes of the entire PAN, supported by associated key management processes and procedures.
- 3.5.1.1.b Review the documentation detailing the key management procedures and processes associated with the keyed cryptographic hashes. This review should confirm that keys are managed in line with Requirements 3.6 and 3.7.
- 3.5.1.1.c Inspect data repositories to confirm that the PAN has been rendered unrecognizable.
- 3.5.1.1.d Review audit logs, including payment application logs, to confirm that the PAN has been rendered unrecognizable
Purpose: The elimination of stored PAN in cleartext is a secondary control measure designed to protect the data if an unauthorized individual gains access to stored data by exploiting a vulnerability or misconfiguration in an entity’s primary access control. Independent secondary control systems (for example, those governing access to, and use of, cryptography and decryption keys) prevent a breach of stored PAN confidentiality due to the failure of a primary access control system.
New requirement:
3.5.1.2 If encryption at the disk-level or partition-level (as opposed to file-, column-, or field-level database encryption) is employed to render PAN unrecognizable, it should be implemented in the following manner:
- On removable electronic media,
OR
- If used for non-removable electronic media, PAN should also be rendered unrecognizable using another mechanism that meets Requirement 3.5.1.
- 3.5.1.2.a
Review encryption processes to confirm that, if disk-level or partition-level encryption is employed to render PAN unrecognizable, it is implemented in the following manner:
- On removable electronic media,
OR
- If used for non-removable electronic media, review the encryption processes used to confirm that PAN is also rendered unrecognizable using another method that meets Requirement 3.5.1.
- 3.5.1.2.b
Review configurations and/or vendor documentation and observe encryption processes to confirm that the system is configured according to vendor documentation, resulting in the disk or partition being rendered unrecognizable.
Also Read:- PCI DSS Requirement 4
Purpose: Disk-level and partition-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. For this reason, disk-level encryption is not suitable for protecting stored PAN on computers, laptops, servers, storage arrays, or any other system that provides transparent decryption upon user authentication.
You can also watch the video on PCI DSS Requirement 2:
Conclusion:
In this post, we’ve examined PCI DSS Requirement 3 and its evolution from v3.2.1 to v4.0. This requirement, focusing on protecting stored account data, has seen significant changes, underlining the need for organizations to stay current and compliant.
PCI DSS’s goal extends beyond compliance; it’s about creating a secure environment that earns customer trust. We trust this post has shed light on the changes in PCI DSS v4.0.
Stay tuned for our next post on the updated PCI DSS requirements. Until then, stay secure and compliant!
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 (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.
