PCI Requirement 3
Protect Stored Cardholder Data
Welcome to PCI Requirement 3. Does your organization store cardholder data? If so, you’re in right place to start learning how to appropriately protect and store cardholder data. PCI Requirement 3 gives organizations an opportunity to consider which retained data is required and which is becoming a liability for your organization. So how do you protect the stored cardholder data that is vital to your business?
In these video resources, you will learn about implementing encryption, truncation, masking, and hashing – all methods that can be used to protect and store cardholder data. We will also discuss dual control, split knowledge, rendering data unreadable, key-custodians, PAN, sensitive authentication data – all elements that need to be understood in order to fully protect and store cardholder data. Click on a video below to get started with PCI Requirement 3.
PCI Requirement 3.1 – Keep Cardholder Data Storage to a Minimum
PCI Requirement 3.1 requires organizations to securely delete data that is not required to be retained for business or legal requirements. Why is complying with PCI Requirement 3.1 important? So that cardholder data cannot be recreated by malicious individuals.
PCI Requirement 3.2 – Do Not Store Sensitive Authentication Data after Authorization
PCI Requirement 3.2 states, “Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon complete of the authorization process. It is permissible for issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely.”
PCI Requirement 3.2.1, 3.2.2 & 3.2.3 – Do Not Store the Track, Service Code, or PIN after Authorization
PCI Requirement 3.2 requires that organizations do not store sensitive authentication data after authorization, even if encrypted. Sensitive authentication data includes full track data (magnetic-stripe data or equivalent on a chip), CAV2/CVC2/CVV2/CID, and PINs/PIN blocks. Along with PCI Requirement 3.2 comes three sub-requirements.
PCI Requirement 3.3 – Mask PAN when Displayed
PCI Requirement 3.3 states, “Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.”
PCI Requirement 3.4 – Render PAN Unreadable Anywhere it is Stored
PCI Requirement 3.4 requires, “Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: one-way hashes based on strong cryptography (hash must be of the entire PAN), truncation (hashing cannot be used to replace the truncated segment of PAN), index tokens and pads (pads must be securely stored), strong cryptography with associated key-management processes and procedures.”
PCI Requirement 3.4.1 – Use of Disk Encryption
If your organization is going to use disk encryption as a means to render data unreadable, you need to comply with PCI Requirement 3.4.1. PCI Requirement 3.4.1 requires, “If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts. This requirement applies in addition to all other PCI DSS encryption and key-management requirements.”
PCI Requirement 3.5 – Protect Keys Used to Store Cardholder Data
If your organization is using encryption to render cardholder data unreadable, you must have a key management program in place. PCI Requirement 3.5 requires organizations to, “Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.”
PCI Requirement 3.5.1 – Maintain a Documented Description of the Cryptographic Architecture
PCI Requirement 3.5.1 is an additional requirement that only applies to service providers. It requires that your organization, “Maintain a documented description of the cryptographic architecture that includes: details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date, a description of the key usage for each key, and an inventory of any HSMs and other SCDs used for key management.”
PCI Requirement 3.5.2 – Restrict Access to Cryptographic Keys
PCI Requirement 3.5.2 states, “Restrict access to cryptographic keys to the fewest number of custodians necessary.” There should be very few employees who have access to your organization’s cryptographic keys. Typically, only those deemed “key custodians” have this type of access. In order to comply with PCI Requirement 3.5.2, your organization needs to maintain strict access controls around who has access to cryptographic keys in order to prevent an unauthorized user from gaining access to the encryption/decryption keys.
PCI Requirement 3.5.3 – Store Secret & Private Keys Used to Encrypt/Decrypt Cardholder Data
PCI Requirement 3.5.3 requires organizations to, “Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:
PCI Requirement 3.5.4 – Store Cryptographic Keys in the Fewest Possible Locations
PCI Requirement 3.5.4 states, “Store cryptographic keys in the fewest possible locations.” Reducing the amount of locations where cryptographic keys are stored helps your organization to track and monitor all key locations. If you have 100 locations, your organization would have to maintain strict control over 100 locations, which could lower the quality of control and increase the chance of unauthorized exposure. Minimizing the amount of locations to places that are necessary helps decrease the potential for an attack.
PCI Requirement 3.6 – Document & Implement All Key-Management Processes & Procedures for Cryptographic Keys
PCI Requirement 3.6 states, “Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data.” PCI Requirement 3.6 and its sub-requirements are meant to build your organization’s key management program because, according to the PCI DSS, “The manner in which cryptographic keys are managed is a critical part of the continued security of the encryption solution. A good key management process, whether it is manual or automated as part of the encryption product, is based on industry standards and addresses all key elements at 3.6.1 through 3.6.8.” NIST is a great industry standard to base your key management program off of.
PCI Requirement 3.6.1 – Generation of Strong Cryptographic Keys
PCI Requirement 3.6.1 requires, “Generation of strong cryptographic keys.” It also requires that, “The encryption solution must generate strong keys, as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under "Cryptographic Key Generation."
PCI Requirement 3.6.2 – Secure Cryptographic Key Distribution
PCI Requirement 3.6.2 states, “Secure cryptographic key distribution.” Whether it’s placing tamper-proof or tamper-evident packaging on trackable packages or tracking data that you’ve transmitted electronically, any method that your organization is using to transmit keys needs to be done securely.
PCI Requirement 3.6.3 – Secure Cryptographic Key Storage
If your organization is storing PCI-related data using encryption, those keys must be stored securely, as PCI Requirement 3.6.3 commands, “Secure cryptographic key storage.” If your key storage is securely stored, has the appropriate protections, and access is limited to the fewest number of people and locations as possible, you prevent your organization from being susceptible to an attack.
PCI Requirement 3.6.4 – Cryptographic Key Changes at Cryptoperiod Completion
Encryption keys have a lifespan. PCI Requirement 3.6.4 states,…
PCI Requirement 3.6.5 – Replacing Weakened Keys
The PCI DSS states, “Keys that are no longer used or needed, or keys that are known or suspected to be compromised, should be revoked and/or destroyed to ensure that the keys can no longer be used. If such keys need to be kept (for example, to support archived, encrypted data) they should be strongly protected.”
PCI Requirement 3.6.6 – Using Split Knowledge & Dual Control
PCI Requirement 3.6.6 is one requirement that both assessors and clients struggle to understand. PCI Requirement 3.6.6 states, “If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.”
PCI Requirement 3.6.7 – Prevention of Unauthorized Substitution of Cryptographic Keys
Your organization must have the appropriate controls in place to prevent unauthorized key substitution. PCI Requirement 3.6.7 requires, “Prevention of unauthorized substitution of cryptographic keys.”
PCI Requirement 3.6.8 – Key-Custodian Responsibilities
Someone in your organization needs to be responsible for managing the encryption of your environment and accept the important of this role. This is why PCI Requirement 3.6.8 states, “Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.”
PCI Requirement 3.7 – Security Policies & Operational Procedures
PCI Requirement 3 states, “Protect stored cardholder data.” We’ve discussed encryption, truncation, masking, and hashing – all methods that can be used to protect cardholder data. We’ve talked about dual control, split knowledge, rendering data unreadable, key-custodians, PAN, sensitive authentication data – all elements that need to be understood in order to fully protect and store cardholder data.
