Take a look at the receipt from your last purchase which you paid for using a credit or debit card. It probably includes the name of the merchant that processed the transaction, the date, and amount billed, and the items bought. If you paid with a card, chances are also high that most of the numbers of the 16-digitcard number are truncated with X’s or zeroes. Rest assured that there wasn’t an error in printing the receipt – there’s good reason that the merchant printed it this way and it all has to do with PCI DSS requirement 3.4.
What is the PCI DSS?
Every merchant accepting credit or debit card payments must comply with the Payment Card Industry Data Security Standard (PCI DSS), a set of twelve requirements mandating the protection of cardholder information. Originally put into place in 2004 when the world’s five major credit providers—Visa, MasterCard, American Express, Discover, and JCB—formed the Payment Card Industry Security Standards Council (PCI SSC), the PCI DSS was created to streamline the data security requirements demanded by each provider, and offer one standard that each would recognize and accept.
Each of the twelve requirements focus on a different area of data security, ranging from how a merchant secures their network, to how they maintain a vulnerability management plan. Depending on the merchant level, there are various types of assessments that merchants must complete, from as simple as filling out a Self-Assessment Questionnaire (SAQ), to as in depth as an annual on-site audit by a Qualified Security Assessor (QSA).
What is PCI DSS Requirement 3.4?
Requirement 3 of the PCI DSS is all about protecting stored cardholder data, and it’s six sub-requirements outline specific guidelines for how merchants may store the various pieces of information on a card, including the account number, the CVC code, the expiry date, and the cardholder name.
PCI DSS requirement 3.4 specifically states, “Render PAN unreadable anywhere it is stored – including on portable digital media, backup media, in logs, and data received from or stored by wireless networks. Technology solutions for this requirement may include strong one-way hash functions of the entire PAN, truncation, index tokens with securely stored pads, or strong cryptography.”
What is the PAN? Simply put, PAN stands for the Primary Account Number, or the 16-digit code found on every card. The PCI Glossary goes on to define it as the “unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account.” This part of the definition is particularly important because if a fraudster gets hold of a PAN, they will not only be able to identify the card issuer, but they can also trace back an account to a particular cardholder. For this reason, it is understandable why the PCI DSS requires merchants to protect this information.
What Does Requirement 3.4 Mean for Merchants?
The PCI SSC makes an important distinction on this sub-requirement in this explanation provided in its guide titled PCI Data Storage Do’s and Don’ts:
“Requirement 3 of the Payment Card Industry’s Data Security Standard (PCI DSS) is to ‘protect stored cardholder data.’ The public assumes merchants and financial institutions will protect data on payment cards to thwart theft and prevent unauthorized use. But merchants should take note: Requirement 3 applies only if cardholder data is stored. Merchants who do not store any cardholder data automatically provide stronger protection by having eliminated a key target for data thieves.”
While requirement 3.4 does make an allowance for the PAN to be stored in a merchant’s system, it only applies to institutions choosing to do so. That means if your company has chosen not to store PANs, you don’t have to worry about requirement 3.4, as it doesn’t apply to you.
If you do store PANs or other cardholder data, there are thankfully several ways to comply with requirement 3.4.
How to Comply with PCI DSS Requirement 3.4
To comply with this sub-requirement, organizations can use a number of techniques to render the PAN unreadable:
- One-way hashing – This method must be based on strong cryptography and is ideal for situations where there is no need to retrieve the original number, due to the irreversible nature of the technique.
- Truncation – In this method, most of the PAN is removed (as in the receipt example above), and no more than the first six and last four digits may be shown. Hashing may not be used to replace the truncated digits.
- Index tokens and pads – This method employs an encryption algorithm which pairs a random key or “pad” with sensitive plain text data to mask the original digits. This only occurs once.
- Strong cryptography – This method must include associated key-management processes and procedures, and an assessor must verify that an industry-accepted encryption protocol is being used.
Of course, as previously mentioned, the easiest way to comply is to not store this data at all. Unless there is a strong business need to store the PAN, merchants should make every effort possible to reduce their risk and avoid storing them entirely.
Sensitive Authentication Data and Requirement 3.2
When taking into account data storage procedures for the PAN, it’s also important to distinguish between the other sub-requirements in requirement 3 and their divergent stipulations for different pieces of cardholder information.
While requirement 3 allows the storage of the PAN, cardholder name, service code, and the expirationy date, sub-requirement 3.2 explicitly prohibits merchants from storing sensitive authentication data under any circumstances, even if it is encrypted. Sensitive Authentication Data includes the CVC code, full magnetic stripe data, and the PIN or PIN block.
The recording of Sensitive Authentication Data can become especially problematic in call and contact center environments, where companies taking payments over the phone or through webchat channels may ask their customers to read their card numbers and security codes aloud or type them into the chat box so that the customer service representative (CSR) can then process the transaction. This can open a whole can of worms because the cardholder information can inadvertently be saved on call recordings or in chat logs, in turn causing a huge compliance headache.
Avoid Storing Cardholder Data Entirely
PCI DSS sub-requirement 3.1 establishes a best practice of only storing the cardholder data that is absolutely necessary for your business, stating, “Limit cardholder data storage and retention time to that required for business, legal, and/or regulatory purposes, as documented in your data retention policy. Purge unnecessary stored data at least quarterly.”
At Semafone, we have a similar mantra: “They can’t hack what you don’t hold,” meaning that organizations should reduce their risk and cut out any data that isn’t business critical. This not only helps with PCI DSS compliance, but is also a best practice for reducing the burden of the requirements found in the EU GDPR.
In the call and contact center setting, DTMF masking technologies like Semafone’s signature Cardprotect solution, allow customers to make credit card payments over the phone by entering their PAN using the keypad, all while staying on the line with the CSR for the entirety of the call. Not only does it allow for PCI DSS compliant payments, but it also enables a better and more streamlined customer experience as well. Doing so can help descope your contact center entirely for PCI DSS compliance, and can reduce the associated costs and headaches.
The post PCI DSS Requirement 3.4: A Deep Dive into Storage of Cardholder Data appeared first on Semafone.
*** This is a Security Bloggers Network syndicated blog from Semafone authored by Aaron Lumnah. Read the original post at: https://semafone.com/press-releases-us/pci-dss-requirement-3-4-a-deep-dive-into-storage-of-cardholder-data/