PCI DSSSeven Questions for Payment Card Industry (PCI) Compliance Data
There is a time-honored method to gain an understanding of a new concept by asking seven questions. Everybody has heard this before, but it’s going to come in handy when I describe one misunderstood part of the Report on Compliance (RoC) dealing with data storage.
The seven questions are:
- Who?
- What?
- Why?
- When?
- Where?
- How?
- How Much?
I am going to apply these to a table in the RoC that I get some trepidation from my clients on every time we undertake an assessment project. The object under review is PCI DSS executive summary table 4.3 (abbreviated E4.3) Cardholder Data Storage. I want to break down each of the five fields in the table and provide what is captured to file the report.
Where is the data found?
The left two columns of the table establish the where. The first column is the Data Store, which could be the name of the application or the name of the database where the cardholder data resides. It needs to be descriptive enough that if you told it to another person, they would know where the data is. It is used along with the second column, File and/or Table, to narrow the exact location of the data. The first column is the ‘where’ within the company the data store resides, and the second column is where within the data store it resides. If it is a database, make sure you capture in the first column the database vendor name and version to be more descriptive. A RoC is meant to be handed to someone who knows absolutely nothing about your world, and they can get an understanding of your environment just by reading the executive summary.
“What are you storing?”
“What are you storing?,” is the key question under the center column, “Cardholder data elements stored.” The obvious entry here is the Primary Account Number, PAN, but you could also be storing the cardholder name and the expiration date of the card too. Storing sensitive authentication data is prohibited post authorization, so we do not see that very often. I do have one client who we list “Card Security Codes,” CSC, under this column, which is sensitive authentication data, but as you will see in the next section, it is OK.
Many clients want to put elements like “Truncated PAN” in this column, which is getting ahead of yourself and incorrect. The base data element is what you are capturing here. Its up to the next column to show how.
How are you protecting the data element?
That belongs under “How Secured.” For a PAN, is it truncated? Tokenized? Encrypted? You need to fully disclose how the data element is rendered unreadable. You do not need to write your life story here, just a phrase like ‘Tokenized.’ When the protection is encryption, you need to cite the encryption algorithm and strength, like AES256. I mentioned above that I have a client listing card security code. What he is storing is a token of either 100, 200 or 1000. While it raises eyebrows every time I write the RoC for that client, they do not store the actual CSC, just a dummy value returned by the upstream payment processor along with the PAN token. It is literally just something to put on the database to fill a field. The only organizations that should be storing CSC are issuing entities, and they need it to produce the cards.
Who accessed the data?
The who of the seven questions is the last column. The field for the table is “How access to the data stores is logged” and captures who is accessing the data. They want to see that you have a method to log when someone accesses the data, be it in the database or on a file on a disk. That logging should conform to requirements found in Requirement 10.
The last three questions, Why, When and How Much do not get captured in the E4.3 table in the RoC, but in the spirit of the query, I’ll provide where you will find those answers.
Why are you storing it and when does it happen?
To answer why you need to store the data, it is not found in the E4.3 table, really because it needs more detail than an entry in a table. Why you would store the cardholder data is elaborated in Executive Summary sections 2.1 (description of the entity’s payment card business) and 4.2 (detailed data flows) and forms the basis of how you process cards. In the same executive summary sections are answered when you store the data. As in when in the data flow you capture the data for putting on your data store.
Which leads me to the final question, “How Much?”
Like Why and When, its not going to be in the E4.3 table because it is not a defined quantity. The “how much” is set by your retention policy and shows up in Requirement 3.1 where you have to describe how long you keep data and provide a means to securely delete the data once it reaches that retention threshold. As part of testing for the PCI DSS controls, we QSAs will look at your database and make sure you do not have data older than your retention value. The retention value is variable and may be set by your acquiring bank, industry, or regulatory bodies.
The PCI SSC wants to know about all card data.
You are probably saying to yourself that all this sounds pretty straightforward and you just need to capture the required data in the E4.3 table, but there is a wrinkle that gets people every time. The PCI SSC wants to know about all card data. By that, I mean some firms do not actually store card data. They receive the cardholder data via web pages or a payment terminal, they hold it in memory until its authorized and then they only keep the last four digits of the PAN to put on receipts or in case there is research on the transaction later. The last four digits of the PAN cannot be used to recreate a full card number, so we QSAs consider it technically not to be cardholder data, but the PCI SSC wants it tracked anyway. So, when I write a RoC, I have to put an entry on the E4.3 table that captures the PAN is being stored (read: What), but it shows a “how secured” of “Truncated (last4)” (read: How). You do not have to mention the stored data again, just that one time. The net result is other requirements like keys (requirement 3.5) and key management processes (requirement 3.6) will usually be “Not Applicable” because you are not storing a full PAN, and if someone broke into your database they wouldn’t get anything they could use for fraudulent transactions.
Another point in closing; the E4.3 table applies to all cardholder data storage, including hardcopy storage. While you cannot encrypt or tokenize hardcopy data, it can be covered with something as simple as a magic marker. Even then you will still need to put it on the table
_____________________
_____________________
Written by Drew Cathey
Drew Cathey has been a member of the SecureTrust team for five years and has been in IT for 35 years. Coming from a background in telecommunications IT operations, he has held positions in engineering, project management and IT security. Drew holds degrees in biology, engineering and an MBA in Information Technology management along with PMP, CISSP, CISA and QSA certifications. He resides in St. Petersburg, FL with his two children and enjoys running, bicycling and tennis.