PCI Requirement 3.4 – Render PAN Unreadable Anywhere it is Stored
by Randy Bartels / July 28th, 2017
What is PCI Requirement 3.4?
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.”
What are Primary Account Numbers (PAN)?
PAN stands for Primary Account Number, and it is the most critical piece of cardholder data when it comes to PCI compliance. Since the PAN can be used in conjunction with other pieces of cardholder data, there are extra steps and regulatory compliance that must be met in order to ensure user data is properly secured.
The PCI DSS says, “The primary account number (PAN) is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment (CDE), they must be protected in accordance with applicable PCI DSS requirements.”
It should be noted that PCI DSS Requirements 3.3 and 3.4 apply only to PAN. If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.4.
How Do I Render PAN Unreadable?
Your assessor should ask what means and methods your organization is using to protect PAN. In any place that PAN is stored, it needs to be rendered unreadable. There are a couple of methods that your organization can use to accomplish this:
- One-way hashes based on strong cryptography are appropriate to use when there is no need to retrieve the original number, because one-way hashes are irreversible.
- Truncation permanently removes some of the PAN data so that only a portion (not to exceed the first six and last four digits) of the PAN is stored.
- Index tokens and pads can be used. The PCI DSS defines them as, “An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key.”
- Strong cryptography with associated key-management processes and procedures. If the data is encrypted, the assessor needs to verify that you’re using an industry-accepted encryption protocol.
- Controls that prevent the correlation of hashed and truncated versions of PAN will help to defend against hackers and work to ensure that the original PAN remains unreadable.
What Happens During the PCI Assessment?
We recommend that you take a full inventory of the places where your data resides before the assessment, so that when your PCI audit process begins, you can give your assessor documentation about your systems, files from data repositories, samples of removable media, and samples of audit logs to examine and ensure that the PAN is unreadable.
More PCI-DSS Compliance Resources
Beginner’s Guide to PCI Compliance
When Will You See the Benefit of an Audit?
PCI Requirement 3.4
There are going to be situations within your organization where you might need to store electronic data that contains sensitive information. Whether this be PCI data or whether this be social security numbers, it’s really in your best interest to ensure that data is encrypted. However, specific to PCI DSS Requirement 3.4, it states that you need to render this media or this information unreadable in any place that it’s stored. There’s a couple of ways that we can go about doing that. We can encrypt that data; if you encrypt it, it needs to be done with a strong protocol.
We can truncate the data; understand that if we truncate the data – where we have 16 digits in the credit card number, the first 6 and the last 4 can be displayed with no problem – if you remove those middle 6 numbers, that information is no longer really considered cardholder data. It can also be hashed with a 1-one hashing algorithm; understand that the hashing algorithm needs to be strong as well. The DSS also talks about using index tokens and pads; we don’t see those often in the assessment field. One of the things we’ll be doing as assessors is asking about how you’re protecting this data. What are the methods and means that you’ve implemented in order to render the information that you have unreadable. If you’re using encryption, we’re going to look at your encryption algorithms.
We’re going to look to see how you’ve actually implemented this. Understand that it is not acceptable to roll your own encryption. Encryptions are often broken and we want to make sure that you’re using an industry-accepted encryption protocol. As part of that, we’re also going to be asking to view that data. If you have it in a database, we’re going to be asking your database administrators to run queries against that data. We’re going to be looking to see that the data is not rendered in clear text. There might be situations where you receive a notification of a charge back from your bank. In situations like that, we often find that people will take and write that cardholder information down in an Excel document in the accounting department.
One of the things that we’d recommend you do, for your own compliance, is to perform a full inventory of all of the places where your data might reside. This would include your accounting department as well as any of the systems that are used to interact with that data. We have tools that we will ask you to run; card recon is one of those tools. We may ask you to run it on a sample of systems and that particular tool will run through all of the assets to try and identify if there is clear text cardholder data there. So it’s important that we protect this information, whether it’s PII data, PHI, financial information that you might retain on behalf of a third party. If you are storing cardholder data to support your business, it needs to be rendered unreadable.
