PCI compliance requirement 3: Protect data

Diana Kelley and Ed Moyle, co-founders of Security Curve, review PCI compliance Requirement 3: "Protect stored cardholder data." PCI compliance Requirement 3 calls for:

• Encryption of stored data
• Protection of sensitive authentication data, like mag stripes. This cardholder data must not be stored, even with encryption.

Ed Moyle and Diana Kelley review common questions related to PCI compliance requirement 3, including "What's Appendix B all about?" and "Should the CVV never be stored?"

Watch the rest of the PCI compliance requirement videos.

Editor's note: This video is based on PCI DSS version 1.1. For updated information on the changes in PCI DSS version 1.2, see the following:

• Version 1.2 of PCI DSS answers questions, raises others
• PCI version 1.2 clarifications: How to get an early start on compliance audits

Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.     

PCI compliance requirement 3: Protect data

Diana Kelley: Requirement three, this is the big one. This is the one that seems simple. Protect the cardholder data, but this is the one that had infamous sub-requirement 3.4, which is about if you are going to store permanent account numbers, or PAN's, what the protections you need to have around storing those. So whether you store, or not, that cardholder data. If you do store you have a couple of options you can go ahead and truncate that information, or one way hash it, which renders it unusable however. So if you want to get that number back in the future, you're not going to be able to with one of those options. You can encrypt it, but if you encrypt it now you've got a whole lot of key management issues that you need to also do to make sure that you're protecting that account number. And then there's also the compensating controls, which are appendix B of the DSS that you can use to protect the cardholder data.

One thing, if you're going to truncate or one way hash that number so that it's not useable to you in the future, do check with what your service level agreement is with your acquiring bank and potentially with the brand in terms of charge backs. Because many retailers do report that they are not allowed to truncate the number, they need to have the full number retrievable going forward. Now the National Retail Federation has requested a change to this. But at this point you have to check with your own agreement with your acquire and with the brand, because you may actually need to store that whole number. If you don't, don't store it. That's the best thing you can do, but if you do need to store it we're going to talk about some of the things that you need to do.

Ed Moyle: Sure and keep in mind that there's also a difference between the PAN, the primary account number, the actual credit card number, as well as what they call sensitive authentication data. Which is track one, and track two, the magnetic stripe that's on the back of the card. That as well as the CDC or CVV, that's the number, the three digit, or four digit identification code that's on the back of the card. That authentication data, you can't keep that, we'll say at all. There are a couple of situations where you can keep if for a certain very limited period of time. We'll talk about that when we get to the questions, but just consider that as not being able to kept period.

Diana Kelley: A question that comes up a lot around the CVV and each brand has a different way that they call as a verification code, it could be CVV, so it depends on the brand. That's why we're using alternates for that. Like I said, it's either three of four digits front or back. Most of the time back, but if you've got [Nanex] it's in black flat on the front. But the question comes up, hey, I need to sell services and say you're a cell phone provider, and somebody wants to give you a credit card and say charge me automatically. That's fine well what if you can't put that charge though without the additional verification number?

Ed Moyle: In that case here's where it's important to understand specifically the language of the requirement. If it says don't store sensitive authentication data post authorization. This means that after the authorization for a transaction takes place, you may no longer keep it. However there are certain cases, for example in an offline context, if your acquire is down for example and you can't get access to their infrastructure to do an authorization in that case you can do a store and forward type of activity where the CVV or CVC 2, or CID, or whatever it is stored as well as the track data for that to go through. However that case is extraordinarily rare, so in the case like the one you're talking about. Somebody wants to do one click and have your CVV be a part of it, no. You can't do that, absolutely no way is that going to fly. If your QSA finds it you're going to be in a heaping pile of trouble, because that's just not going to fly.

Diana Kelley: So you could either ask them to go back to your site and give you for example the last four numbers of your credit card and the CVV or the CID, or you can get a service level agreement with your acquirer that allows you to accept transactions that do not have a CVV associated with them. And if you've done one click shopping at a company online like Amazon you have seen that in action.

Ed Moyle: Absolutely. Another question we get quite a bit is about appendix B 3.4. Indicates the thing about encrypting the pin, and storing it in an encrypted format. A lot of folks see the appendix B which is compensating controls specific to that requirement, and they ask, well you know, which should we do. Should we do the compensating controls or should we actually encrypt the pin. My advice is if you don't have to keep the pin at all, don't. Keep in mind that the compensating controls are a stop gap measure. The goal is never to use a compensating control to meet the requirement and never have to comply. The goal is to get to compliance. Really if you can, try to encrypt them and follow the actual requirements.

Diana Kelley: So some quick tips, you want to protect that card number on screen. If you're printing it out, give them the receipt. You're going to truncate it on those receipts if you are storing it long term. Protect it either with encryption and the additional key management sub-requirements. Use appendix B as a stop gap measure as you're moving towards the more solid encryption, or talk to your acquire, maybe you don't need to store it at all. Although that's not as common as yet.

Ed Moyle: And really a lot of folks, especially in the merchant community will come up and say things like, hey my acquirer said I need to keep the track data, or so and so over there says that's the way we've always done it, or our point of sale vendor tells us we have to. No matter who says to keep it. Post authorization doesn't. Even if it's your acquirer, because, whose responsibility is it for you to comply, yours. So if your acquirer tells you to do something that's clearly against the requirements, don't, don't do it.

Diana Kelley: And don't jump off the bridge if they tell you to do that.