PCI DSS compliance is a must for any business that handles credit card data. It's an information security standard that stipulates what data must be retained and what must not, as well as time limits for storage and how data should be stored.
You can listen to the interview as an MP3 or read the transcript below.
Download for later:
Download the podcast with Mathieu Gorge
• Internet Explorer: Right Click > Save Target As
• Firefox: Right Click > Save Link As
SearchStorage.co.UK: What are the key elements of PCI DSS compliance?
Gorge: PCI DSS has been around since December 2004. It is a collective effort from the major card brands to harmonise their various security standards that they impose on merchants, payment service providers and banks.
It was started by MasterCard, Visa, Amex, JCB and Discover, and it sets 12 high-level requirements with in excess of 200 controls that are split into three categories. There are some technical controls and technical settings that you need to have in place. There are a number of policies and procedures that you need and also requirements in terms of training for employees and third parties and specific technical skills in terms of how … you implement the technical controls.
PCI DSS applies to any organisation that has a merchant ID and either transmits or processes data related to credit card holder data.
It is important to understand that information known as cardholder data is more than the primary account number, which is the 16-digit number on most credit cards. Some of the data elements [of] the cardholder data include the primary account number, the cardholder name, service code, expiry data, [as well as] includes sensitive authentication data such as full magnetic stripe data, the three-digit code from the back of the card and the PIN number.
The whole idea of PCI DSS is to protect that information and ensure that the right information is protected the right way, and that includes requirements for encryption, authentication and auditing. A lot of it has implications for what kind of data you can store and what you cannot store.
SearchStorage.co.UK: What does PCI DSS compliance mean for storage professionals, and how they must deal with data that falls under PCI DSS rules?
Gorge: The first thing to do -- as with any storage security strategy -- is to understand what you can and can't store. The PCI has published a number of guidance documents including a very simple table showing which data elements you can store and what you need to do if you store it.
Some of the stuff that cannot be stored at any given stage includes full magnetic stripe data, CVV2 number and PIN number.
However, you may be able to store the primary account number, and if you do that storage is permitted, but you have to follow the requirements of a specific control in PCI DSS known as control 3.4, which covers how you must render the primary account number so that it is completely unreadable anywhere it may be stored. That includes storage on servers as well as on portable digital media.
So, as a storage professional you need to know where that data is located on your network, and you [must] demonstrate you are protecting it according to PCI DSS requirements. Those requirements suggest in some cases and demand in others that you hash or truncate or use tokens to mask it.
Whichever way you choose, you must ensure the process is fully auditable from both the technical and access perspective. At the moment the PCI [Security Standards Council] is trying to help organisations reduce the scope of applicability of requirements of control 3.4. To do that, they are talking about what is known as end-to-end or point-to-point encryption. This is where you may use tokens instead of the primary account number such that when a credit card transaction is initiated a token is created, and that token is stored and it has absolutely no value other than for that transaction.
The whole idea of tokenisation -- which is a topical word in the PCI world right now -- is to make sure you store information that is no longer sensitive and therefore can comply with control 3.4 in an easier way.
This was first published in November 2010