PCI DSS Requirement 3: Protect stored cardholder data
Security mechanisms such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. Data cannot be read and used by attackers if they circumvent other security checks and access encrypted data without correct encryption keys.
See Also: How do I Protect the Stored Payment Cardholder Data?
Such methods should also be considered opportunities to secure stored sensitive data and reduce potential risks. For example, cardholder data should not be stored among risk minimization methods unless it is necessary.
Besides, if the full primary account number (PAN) is not required due to business requirements, the cardholder data must be truncated or masked. Primary account numbers (PANs) should not be sent explicitly using end-user technologies such as e-mail or messaging.
PCI DSS Requirement 3 concerns the protection of stored data. It specifically aims to protect primary account numbers (PAN) and sensitive authentication data (SAD) using hashing, truncation, or encryption methods.
This requirement has the main purpose of minimizing all risks associated with storing cardholder data. If you do not need such sensitive data for your organization’s business needs, do not store it.
Let’s take a look at all the sub-requirements in PCI DSS requirement 3.
PCI DSS Requirement 3.1: Keep cardholder data (CHD) storage to a minimum by applying data retention and destruction policies, procedures, and processes.
A formal policy on data retention defines which data should be stored and where the data is located. This data can then be destroyed or deleted safely when it is no longer needed.
See Also: Card Hunting: Finding Card Data For PCI
Only the primary account number or PAN, expiry date, cardholder name, and service code can be stored in an unreadable format after authorization.
It is necessary to understand and know where the cardholder data is stored to be erased or removed when it is no longer needed. To identify acceptable data retention criteria, an organization must first recognize its business needs and legal or regulatory responsibilities related to the type of data relevant to or held in its sector.
See Also: What are the PCI DSS Data Retention and Disposal Requirements?
Identifying and removing stored data that has reached the specified retention period prevents the over-processing of data no longer needed. This method can be either manual, automatic, or a mixture of both.
For example, a programmatic procedure can be used to find and remove data or to review data storage areas manually. Secure deletion methods may ensure that data is not received and deleted when it is no longer needed.
The basic precaution you can take to store and manage your cardholder data will be if you do not need it, do not store it.
- Limit the amount of data retention and retention period to the time required for legal, regulatory, or business requirements.
- Create specific retention requirements for cardholder data.
- Define actions to delete data when data is no longer needed securely.
- Repeat the quarterly process to identify and securely deleting stored cardholder data that exceeds the set retention period.
Sensitive authentication data consists of full-track data, validation code or value, and PIN code. This data is valuable to malicious people as it allows them to create fake payment cards and fraudulent transactions.
It is therefore prohibited to store sensitive authentication data after authorization by the PCI DSS requirements!
See Also: How to Permanently Delete Sensitive Authentication Data
Organizations that offer payment cards, services, or assistance providers and control sensitive authentication data as part of the card’s issuing. Companies providing, creating, or providing services may only store sensitive authentication data if they have legitimate business needs. Besides, all requirements of the PCI DSS apply to such organizations.
See Also: PCI Requirements For Storing Credit Card Information
The important point here is that the legitimate reason stated is not convenient for the organization, but only a necessary one. Such sensitive data must be stored securely following all PCI DSS requirements and related payment brand requirements.
It is not allowed to keep sensitive authentication data after the authorization of organizations other than the institutions that provide payment cards, services, or assistance.
Track data includes the magnetic stripe on the back of the card, comparable data on the chip, or equivalent data located elsewhere. This data is alternatively called full track, track, track 1, track two, and magnetic stripe data.
If full track data is stored, malicious individuals who obtain the data may use it to reproduce payment cards and complete fraudulent transactions.
In businesses’ normal business processes, the following data items on the magnetic stripe may need to be retained:
- Cardholder’s name
- Primary account number (PAN)
- Expiration date
- Service code
Keep only those data items needed for the job to minimize the risk.
Examine the following data sources to verify that the contents of any piece of comparable data on the magnetic stripe or chip on the back of the card are not stored after authorization:
- Incoming transaction data
- All logs (transaction, history, debugging, errors)
- History files
- Trace files
- Various database schemes
- Database content
The card verification code is a three-digit or four-digit number printed on the front or back of the payment card used to verify transactions without a card. The purpose of the card verification code is to protect the internet or mail order/phone order (MO/TO) “card-not-present” transactions performed without the card.
If such data is stolen, fraudulent Internet and MO / TO transactions can be performed by malicious people.
Check that the 3-digit or 4-digit card verification code or value (CID, CAV2) printed on the card or signature panel (CVV2, CVC2) is not stored after authorization from the following data sources:
- Incoming transaction data
- All logs (transaction, history, debugging, errors)
- History files
- Trace files
- Various database schemes
- Database content
The personal identification number (PIN) and the encrypted PIN block should be known only to the cardholder or bank that issued the card. If this data is stolen, malicious individuals may perform fake PIN-based payments, such as ATM withdrawals.
To ensure that the Personal Identification Number (PIN) or the encrypted PIN block is not stored after authorization, examine the following data sources:
- Incoming transaction data
- All logs (transaction, history, debugging, errors)
- History files
- Trace files
- Various database schemes
- Database content
PCI DSS Requirement 3.3: Mask primary account number (PAN) data when displayed.
The first six and last four digits of the primary account number (PAN) are the maximum number of digits to be displayed. Only staff with a legitimate business need can see more than PAN’s first six and last four digits.
See Also: What are the Acceptable Formats for Truncation of PAN
Viewing full primary account numbers (PANs) on items such as computer screens, payment card receipts, faxes, or paper reports may result in the unauthorized and fraudulent use of such data.
Ensuring that full primary account numbers (PANs) are displayed only for people with legitimate business needs minimizes the risk of unauthorized persons accessing PAN data to view PANs.
The masking method should always ensure that only the minimum number of digits required to perform a particular job function is shown.
For instance, if only the last four digits are needed to perform a business function, mask the PAN so that people who perform this function can see only the last four digits.
As another example, if you need a function to access the Bank Identification Number (BIN) for routing, unmask the BIN digits (traditionally the first six digits) during this process.
This requirement relates to PAN’s safety in displays, such as on screens, paper receipts, and printouts. Don’t confuse this requirement with PCI DSS requirement 3.4 applied to protect PAN data when stored in files, archives, and databases.
Establish written policies and procedures for masked display of primary account numbers (PANs), including:
- Create a list of roles that need access to impressions that exceed the top six and the last four, including the full PAN, and legitimate document business needs so that each role has such access.
- Only staff with a legitimate business need should be masked so that PAN can see more than the first six and last four digits.
- All roles that are not authorized to see the full PAN should only see masked PANs.
This requirement does not replace stricter standards such as point-of-sale (POS) receipts, legal or payment card brand requirements to display cardholder data.
PCI DSS Requirement 3.4: Make PAN unreadable wherever it is stored
Personal account numbers (PANs) can be stored in multiple locations, including portable digital media, backup media, and logs. Hashing, truncation, or encryption methods should be used to render PAN data unreadable.
See Also: How can you make unreadable stored PAN information?
Both PANs stored in primary storage, such as databases, and non-primary storage, such as backups or audit logs, must be secure.
- One-way hashes (Hash) based on strong cryptography (the hash must contain the entire PAN.)
- Truncation (hash cannot be used to replace the cut segment of PAN.)
- Index tokens and pads (pads should be stored securely.)
- Strong cryptography with associated key management processes and procedures
If a malicious person has access to both the truncated and hashed version of PAN, rebuilding the original PAN data is a relatively trivial effort. Suppose the organization has hashed and shortened versions of the same PAN in its environment. In that case, it should use additional controls to ensure that the hashed and truncated versions cannot be associated with rebuilding the original PAN.
All PANs stored in primary storage areas such as databases or electronic text files and non-primary storage areas such as backup, audit logs, exception, or troubleshooting logs should be protected.
One-way hashing methods based on strong cryptography can be used to render cardholder data unreadable. Since the unidirectional mixing functions are irreversible, it is convenient when there is no need to get the original number.
It is recommended that the cardholder be given an additional random input value before interference to reduce the likelihood that an attacker can derive PAN by comparing data with pre-calculated hash tables.
The purpose of truncation is to remove a segment of PAN data permanently. Thus, only a portion of the PAN is stored, usually not more than the first six and the last four digits.
The index token is an encryption token that replaces the index-based PAN with an unpredictable value. One-time padding is a system where a randomly generated private key is used only once to encrypt a message, decrypted using a matching one-time padding and key.
The purpose of strong encryption is that encryption is based on an industry-tested and accepted strong encryption key algorithm.
A malicious person can easily derive the original PAN value by combining hashed and truncated versions of a particular PAN. Controls that prevent that data from being correlated will help to keep the original PAN unreadable.
PCI DSS Requirement 3.4.1: If disk encryption is used, logical access must be managed independently of local operating system authentication and access control mechanisms. Decryption keys should not be associated with user accounts.
Disk-level encryption encrypts the entire disk or part of the hard drive and automatically decrypts the information requested by an authorized user.
See Also: Things to Know About Full Disk Encryption
This requirement is intended mainly to create a separation that does not allow the user’s password to automatically access the data set if the user’s authentication information is disclosed.
Most disk encryption solutions stop operating system read/write operations and perform necessary encryption conversions without any special intervention by the user, except for system startup or password at the start of a session.
To comply with this requirement, the method of disk-level encryption cannot:
- Use the same user account authenticator as the operating system.
- Use a decryption key associated with or derived from the system’s local user account database or public network login credentials.
Full disk encryption helps protect data when a disk is physically lost and may be suitable for portable devices that store cardholder data.
This requirement applies besides all other requirements for PCI DSS encryption and key management.
PCI DSS Requirement 3.5: Create and implement procedures to protect keys used to protect stored cardholder data against disclosure and misuse.
Cryptographic keys must be strongly protected as sensitive data can be decrypted using these keys by those who gain access to them. Key encryption keys should be as strong as the data encryption key to ensure that the key that encrypts the data and the data encrypted with this key is properly protected.
See Also: Encryption Key Management Essentials
Key disclosure and the need to protect against misuse apply to both data encryption keys and key-encryption keys. Key encryption keys require strong protection measures because a key-encryption key can access many data encryption keys.
This requirement also applies to keys used to encrypt stored cardholder data and key encryption keys that are used to protect data encryption keys. Such key encryption keys must be at least as strong as the data encryption key.
To prevent the disclosure of encryption keys and protect cardholder data from abuse, processes should be established that include the following items:
- Access to keys should be limited to the minimum number of registers required.
- Key encryption keys should be as strong as the data encryption keys they protect.
- Key encryption keys are to be stored separately from data encryption keys.
- The keys should be stored securely at the least possible location and form.
PCI DSS Requirement 3.5.1: Additional requirement for service providers only: Create a documented description of the encryption architecture.
This requirement applies only when the organization being assessed is a service provider.
Descriptions of the encryption architecture should include the following items:
- Details of all algorithms, keys, and protocols used to protect cardholder data, including key strength and expiry date.
- Key usage description for each key
- Inventory of HSMs and other SCDs used for key management
Creating and maintaining valid documents of the encryption architecture helps an organization understand the algorithms, protocols, and encryption keys used to protect cardholder data and devices that generate, use, and protect keys.
See Also: PCI DSS Compliant Key Management Lifecycles
These documents help an organization keep up with the threats to its infrastructure and architecture, allowing it to plan changes and updates as the levels of assurance offered by different algorithms and key forces change.
The creation and protection of such documents also enable an organization to detect lost or missing keys or key management tools and recognize unauthorized changes in the encryption infrastructure.
PCI DSS Requirement 3.5.2: Limit access to cryptographic keys to the minimum number of custodians required.
Few people are expected to have access to cryptographic keys. In general, these accesses should only be for those with key storage responsibilities.
Restricting access reduces the potential for creating cardholder data that could be viewed by unauthorized persons.
PCI DSS Requirement 3.5.3: Always store secret and private keys used to encrypt and decrypt cardholder data in one or more of the forms below.
Encryption keys must be stored securely to prevent unauthorized or unnecessary access that may cause cardholder data exposure. Key encryption keys are not intended to be encrypted but must be protected against disclosure and misuse.
See Also: What Are the PCI DSS Encryption Requirements
If key-encryption keys are used, storing key encryption keys that are physically or logically separate from data encryption keys reduces unauthorized access to both keys.
Secret and private keys used to encrypt and decrypt cardholder data should be stored in the following forms:
- The key that is powerful as the data encryption key and stored separately from the data encryption key must be encrypted with the encryption key.
- Secure encryption device (such as Hardware Security Module (HSM) or PTS-approved Interaction Point Device)
- At least two full-length key components or key shares should be used according to the industry’s method.
Public keys do not need to be stored in one of these forms.
PCI DSS Requirement 3.5.4: Store cryptographic keys in the fewest possible locations.
Storing cryptographic keys in minimal locations helps an organization track and monitor all key locations. Besides, this minimizes the possibility of exposure and exposure of keys to unauthorized parties.
PCI DSS Requirement 3.6: Document and implement all key management processes and procedures for encryption keys used to encrypt cardholder data
How encryption keys are managed is a critical part of the continuous security of the encryption solution. Although manual or automated methods are used as part of the encryption product, good key management processes should be based on industry standards.
See Also: HSMs for PCI DSS Compliance
Guiding customers in securely transmitting, storing, and updating encryption keys will help prevent the keys from being mismanaged or exposed to unauthorized assets. This requirement applies to keys used to encrypt stored cardholder data and related key-encryption keys.
You can refer to reliable industry resources such as NIST for key management.
PCI DSS Requirement 3.6.1: Creation of strong encryption keys
The encryption solution should generate strong keys. Using strong encryption keys will significantly increase the security of encrypted cardholder data.
PCI DSS Requirement 3.6.2: Secure encryption key distribution
The encryption solution should distribute keys securely. Keys should only be distributed to the custodian as defined in Requirement 3.5.2 and never explicitly distributed.
PCI DSS Requirement 3.6.3: Secure encryption key storage
The encryption solution should store keys securely. For example, a key must be encrypted with an encryption key and stored. Storing keys without proper protection can give attackers unauthorized access and cause cardholder data to be decrypted and exposed.
PCI DSS Requirement 3.6.4: Cryptographic key changes for keys that reach the end of their encryption period must be based on the manufacturer’s or keyholder’s and industry’s best practices and guidelines.
Cryptoperiod is the period that a particular cryptographic key can be used for its defined purpose. Considerations for defining the crypto period include the strength of the basic algorithm, the size or length of the key, the risk of compromising the key, and the encrypted data’s sensitivity.
See Also: PCI DSS Key Rotation Requirements
When keys reach the end of their encryption period, periodic replacement of encryption keys is mandatory to minimize the risk of someone taking over and using encryption keys to decrypt them.
PCI DSS Requirement 3.6.5: When the key integrity is weakened or suspected of compromising the keys, the keys must be removed or replaced as deemed necessary.
Keys that are no longer used, or keys are known or suspected of being exposed, should be deleted or removed to ensure that the keys can no longer be used.
If such keys need to be stored to support archived or encrypted data, they must be strongly protected. The encryption solution should provide and use a process for replacing keys that need to be changed, known, or thought to be disclosed.
Key management procedures should include the following processes:
- When the integrity of the key weakens, the key must be removed or replaced.
- Keys known or suspected to be in danger must be replaced.
- Keys held after removal or replacement should not be used for encryption operations.
PCI DSS Requirement 3.6.6: In the case of manual open text encryption key management operations, these operations should be managed using split knowledge and dual control.
Dual control and split knowledge of keys are used to eliminate the possibility of accessing the entire key. This control is valid for manual key management operations or when the encryption product does not implement key management.
Manual actions may include any key management activity that requires human interaction with the key. Examples of such activities include key generation, transmission, loading, storage, and destruction.
Split knowledge is a method in which two or more people have individual key components. Each person knows only their key component, and each key component does not contain any information about the original encryption key.
Two or more organizations must have individual key components that do not provide information on the resulting cryptographic key. Splitting the AES-128 encryption key in half and giving a 64-bit key to one person and a 64-bit key is not enough.
Dual controls require two or more persons to perform a function, and no one can access or use the authentication information of another person.
Manual open-text key management procedures should include the following processes:
- The fragmented key information is such that the key components are under the control of at least two people who only know their key components;
- Dual key control, where at least two people are required to perform any key management process, and no one can access authentication materials such as a password or key from someone else.
The encryption solution should not allow or accept the replacement of keys from unauthorized sources or unintended transactions.
PCI DSS Requirement 3.6.8: Cryptographic key custodians need to formally acknowledge that they understand and accept their key responsibilities.
This process will help those who act as key responsibilities to assume the key custodian’s role, understand, and accept responsibilities.
Key responsible people are one of the most important people in your organization. They are accountable for creating encryption keys, changing keys, recovering keys, turning keys, distributing keys, protecting keys, etc. They manage every aspect of your environment’s encryption.
Key custodians will have a higher chance of fulfilling their roles with the essential responsibilities by enabling them to sign an official document stating that they understand and accept their responsibilities.
Your key custodians should understand the weight of the work they do and the responsibility they bear. If key custodians do not do their job correctly or securely, this affects your entire organization and can lead to various violations.
PCI DSS Requirement 3.7: Ensure that security policies and operational procedures are documented, in use, and known to all affected parties to protect stored cardholder data.
Employees should be aware of and abide by security policies and documented operating procedures to manage the secure storage of cardholder data permanently.
For detailed information, see the PCI DSS Quick Reference Guide from the PCI SSC Documentation library.
To review all of the PCI DSS Requirements, you can review our PCI DSS Requirements and PCI Compliance articles.
This is so chock full of useful information i can’t wait to dig deep and start utilizing the resource you have given.