Nov 12 2009
I don’t get a ton of questions about PCI sent to me, but from time to time someone asks a question that deserves a blog post. Earlier today I received a question from a reader, Michele, that reflects a common misunderstanding in the PCI sphere:
I was reviewing the PCI DSS 1.2 section 3.4 yesterday, and was surprised to see that “masking” was not an option for PAN at rest / storage. Am I interpreting it correctly that it must be encrypted while stored, but upon display it would be decrypted and masked? To further that thought, if we receive PAN already masked and then store it, does that fall under PCI DSS? My thinking is that technically it does not, as the PAN is already masked when received and there is no ability to trace back to the original clear text PAN.
There’s a basic misunderstanding of what exactly masking is. Many people either don’t know that there’s such a thing as truncation and assume any time they can’t see the entire card number it’s masking, or they assume masking and truncation are the same thing. They are not and here’s the definitions of masking and truncation straight from the PCI Council Glossary:
Method of concealing a segment of data when displayed. Masking is used
when there is no business requirement to view the entire PAN.
Method of rendering the full PAN unreadable by permanently removing a
segment of PAN data.
Think of the cardholder data as numbers written down on a piece of paper. Masking the numbers would be similar to taking a piece of correction tape and covering up the majority of the numbers so only the last four would be readable by the next person you hand the paper to. The data still exists under the correction tape, even though it’s hidden. But the piece of tape can be peeled back with some amount of effort and therefore that piece of paper still needs to be protected so that no one with malicious intent can recover the cardholder data and use it.
Truncation however can be thought of as never writing the numbers down in the first place or erasing them so completely they’re never recoverable. You’re not recording the entire data on the sheet of paper and therefore it can never be used as to commit fraud against the credit card companies or consumers. That piece of paper has no value to the malicious attacker and therefore doesn’t need to be protected, at least not to the same degree that the masked data needs to. There may still be other data of value associated with the record, but the truncated data itself has no data.
If you’re viewing the data on the screen and you can only see a small portion of the data, you don’t know if you’re viewing truncated or masked data without digging deeper into the process. Can the data be recovered in some way or is what’s in the database the same thing you’re seeing on the screen. If you’re on the average sales floor, you can review the tickets for the day and see the last four digits of the card number on the receipts and the reports. If the application has been built correctly, it won’t matter if you’re a salesperson or the manager, you won’t be able get more than the last four digits since they aren’t being saved in the store and there’s no way for anyone in the store to get the data back from system since it’s been truncated and no longer exists at that location.
Switch to the back office and the accounting or loss prevention departments and it’s a different story. The default view that the members of these departments should be seeing is only the last four digits of the card number. However, if there’s a billing issue or a potential fraud situation, company personnel have the ability to unmask the full card number as part of their research. The data still exists on the server, however the majority of the time it is being hidden (masked); only when someone with legitimate business need reveals it is it shown. Since the data is available for recall on the servers, they are fully in scope for a PCI assessment and need to be protected appropriately.
To answer the question, data at rest can never be ‘masked’. It’s only when it is recalled and presented in part to the user that it is considered masked. This is why you don’t see masking as an option in requirement 3.4. If you’re only receiving cardholder data that contains the a subset of the full card number, such as the last four or the first six and the last four, then it’s been truncated. At that point you don’t have the full card number, it can’t be reconstructed and it doesn’t have to be protected as if it was cardholder data. That’s not to say the other data associated with that record don’t have value and shouldn’t be protected, however truncated data is not governed by the PCI requirements.
If your company is receiving the full card number but only displaying the masked to workers, even if no one at your company has access to the card holder data, you’re responsible for protecting the data pursuant to the PCI requirements. If there’s no need for the data, ask for truncated data in the first place and save your company the effort of dealing with PCI, QSA’s and the entire Report on Compliance process. I’m a nice guy, but even my biggest fans amongst the clients I deal with will tell you that there’s always a certain level of pain associated with having me come on-site for the annual review.