At the heart of PCI DSS is the need to protect all cardholder data you carry. The PCI DSS standard includes examples of acceptable data security methods such as encryption, tokenization, truncation, masking, and hashing for cardholder data. You can effectively render stolen data unusable by using one or more of these security methods.
Protection methods such as encryption, tokenization, masking, and hashing are critical components of protecting cardholder data. If attackers bypass other security checks and access encrypted data without the appropriate encryption keys, the data cannot be read and used by that person.
See Also: PCI Requirements For Storing Credit Card Information
Other effective methods of protecting stored data should also be considered as potential risk reduction opportunities. For example, strategies to minimize risk include not storing cardholder data unless necessary, truncating cardholder data if a full PAN is not required, and not sending unprotected PANs using end-user messaging technologies such as email and instant messaging.
Protecting stored data is not one size fits all policy. To make life as difficult as possible for potential attackers, you should consider PCI DSS Requirement 3 as the minimum level of protection you can implement.
Know Data Storage Rules.
You need to know everywhere where data is stored. PCI DSS Requirement 3 also provides instructions on what data can and cannot be stored. One of the best recommendations for this requirement is to “don’t store if you don’t need it” cardholder data.
Additionally, PCI DSS Requirement 3.1 requires you to create retention requirements for cardholder data. As per PCI Requirement 3.1, you should analyze and precise old data quarterly through either a manual review or an automatic destruction process.
See Also: What are the Acceptable Formats for Truncation of PAN
PCI-DSS requirement 3.1 lays out the necessary methodology to ensure that cardholder data is limited to those required for legal, regulatory, or business needs. This requirement states that certifiers must develop data retention policies, secure deletion policies, and a quarterly process to identify and remove all cardholder data that exceeds the retention period.
See Also: How To Store Credit Card Information
Whether or not the company is aware that they are storing cardholder data, this quarterly phase is important. To find this data, there are several instruments and techniques that can be used. The most common is using a data discovery tool in conjunction with best practices to protect against a physical threat.
See Also: Advantages of Using a Credit Card Vault for PCI
Even if your process is automated, you should review every three months to ensure the methods are working correctly. During your evaluation, your evaluator will ask you to produce your oldest data set stored from you. It will then check the dataset to make sure it doesn’t exceed the storage requirements.
Make Stored Data Unreadable.
The PCI DSS standard requires that primary account numbers (PAN), including portable storage, backup devices, and even audit logs, are stored in an unreadable form wherever they are stored.
See Also: Things to Know About Full Disk Encryption
The PCI Security Standards Council’s deliberate use of the word unreadable helps the council avoid enforcing any new technology that proves future requirements.
If the storage of PAN is unavoidable, it must be made unreadable wherever that data is stored. PCI-DSS explicitly specifies acceptable methods to make this data unreadable, and PCI DSS requirement 3.4 provides several options for making PAN data unreadable, including:
- Strong cryptography-based one-way hashes where all PAN must be hashed
- Truncation that stores a PAN section (must not exceed the first six and last four digits)
- Tokenization, which holds a replacement or proxy for PAN instead of PAN itself
- Strong cryptography focusing on key management processes and security procedures
PAN data unreadable means that it would be challenging and time-consuming to decrypt the data if an attacker gets the data. Unreadable information means that the data becomes virtually useless to attackers.
See Also: How can you make unreadable stored PAN information?
Regardless of the methodology traders plan to use to make their stored data unreadable, they need to be protected by associating them with cryptographic keys or index tokens. PCI DSS requires you to use keys and tokens, such as a cryptographic token that replaces PAN for an unknown value based on a specific directory.
If PAN data is encrypted, QSA should check that it uses an industry-accepted encryption protocol to comply with PCI DSS Requirement 3 fully. Organizations should use the following PCI-specified guidelines to manage cardholder data or SAD in the Cardholder Data Environment (CDE):
It should be noted that the storage criteria of the above table applies to cardholder data (16-digit primary account number, expiry date, cardholder name) and not to sensitive authentication data (Track Data, PIN, PIN Block, CVV). After authorization, Sensitive Authentication Data (SAD) can never be stored.
Requirement 3.2 of the PCI-DSS specifies that Sensitive Authentication Data (SAD) cannot be stored after authorization, even if encrypted. Includes SAD, full track data, CVV, and PIN data. This data is precious to attackers for use in fraudulent transactions in both card and cardless transactions.
See Also: What Is Tokenization and How Does It Affect Your PCI Compliance?
The only organizations that can store this data are issuers with a legitimate business need to regulate services. Approving entities must create a cardholder data flow diagram that documents where and how cardholder data is moving or stored in the system.
If cardholder data is processed, transmitted, or stored in the CDE, merchants should implement the same safeguards on their wired networks to secure cardholder data at the POS as they do on their wireless network. Other methods of making PAN unreadable are one-way hashing and truncation, which we will discuss in the sections below.
Manage Encryption Keys Securely.
Whatever solution you plan to use to make your stored data unreadable, the relevant encryption keys must be protected. Strong encryption does not work when combined with a flawed key management method. It also requires you to document how specific keys are implemented and used throughout their life cycle.
See Also: HSMs for PCI DSS Compliance
PCI DSS requirement 3.5 extends the use of cryptography and requires organizations to take steps and document these procedures to protect encryption keys from disclosure and abuse.
The data can be decrypted if an intruder gets hold of the encryption keys. The safeguards to be implemented apply to key-encryption keys and data encryption keys to decrypt data and limit the likelihood of attackers using any of these keys to disclose cardholder data.
Cryptographic keys should be stored in as few places as possible with the least number of people accessing them. It would be better if both external threats and internal threats from employees were considered.
Your key management performance depends on getting suitable protectors of the cryptographic key, and they will be the people you trust who do not cooperate to attack your systems. Such persons are expected to formally acknowledge their understanding and acceptance of their obligations as principal parents.
See Also: Encryption Key Management Basics
You must also ensure that all interested parties in your company are documented and used in security policies and operating procedures to protect stored cardholder data.
Processes for key management of the use of cryptographic keys should be thoroughly documented. The process of cryptographic key management involves the secure generation, distribution, and storage of cryptographic keys and policies that require key changes at the end of the time of encryption or if the key’s integrity is compromised.
The weakening of cryptographic keys can be caused by a team member with clear text encryption key knowledge leaving the organization or when keys are suspected of being compromised.
Do not underestimate the substantial value of strong key management, and do not use any shortcuts. Your Qualified Security Assessor (QSA) will find your errors, and attackers can find them.
Mask PAN Data Before Displaying.
The PCI DSS standard provides exact recommendations for showing PANs. It should only be shown to employees permitted to use all of the digits (usually 16) for business purposes. In all other cases, masking should ensure that the PAN does not show more than the first six digits and the last four digits.
PCI DSS Requirement 3.3 states that the 16-digit Primary Account Number (PAN) should be masked when displayed. The maximum number that can be shown is the first six and the last four digits. Full PAN is only viewable for users whose roles need a legitimate job to view full PAN. This requirement applies to PAN displays on displays, paper receipts, and other printouts.
Ensuring that the customer’s PAN is encrypted using one-way hashing or interception methods ensures that cardholder data remains within PCI DSS limits and avoids potential breaches.
Understanding the importance of PAN and how violations can be avoided by taking a defensive approach to handling such sensitive data is the first of many vital steps merchants must bring in their quest to comply with and maintain compliance with the 3rd requirement of PCI DSS.
For detailed information, you can review the contents of PCI DSS Data Storage Dos and Don’ts.
