Extending PCI Standards To Protect All Confidential Data

Written by Evan Schuman
April 17th, 2008

Guest Columnist David Taylor is Research Director of the PCI Alliance, Founder of the PCI Knowledge Base and a former E-Commerce and Security analyst with Gartner.

One of the things that differentiates the leading merchants that are part of the PCI Knowledge Base from other merchants is that nearly 40 percent of these merchants have targeted 2008 as the year they plan to extend the application of the PCI security standards to embrace other confidential data, beginning with Social Security numbers.

The rationale is simple, as is the argument to upper management: "Why are we protecting one type of confidential data (credit card numbers) differently from other confidential data?" Of course, there’s more to the problem than simply adding SSNs to credit card numbers on some list. But there are several steps that merchants can take that will help them reach the goal incrementally, with less pain and cost.

Identify Your Confidential Data. Any security consultant will tell you that it’s important to have a data classification scheme. Although it makes a nice spreadsheet, we have seen only a few leading-edge merchants and banks that actually attempt to enforce it and use it to drive access controls.

Why? "Data classification" is boring. How could you ever assign your best people (or person) to such an obviously boring task? So even though it’s the "wrong" way to do it, I suggest you pick a few "high-risk, highly visible" data elements, such as SSNs, account numbers and "trade secrets" to protect as a first phase.

Let’s face it: You need to "sell" the task to your IT people, the business or application owners and upper management. Telling these folks that you want to take your PCI "success story" (or whatever expletive you prefer) to other high-risk data is more saleable than telling them you want to undertake an "enterprise-wide data classification project."

Use a Software Tool, Not a Questionnaire. Some have identified useful software tools that help them find confidential data, when the characteristics of these numbers can be accurately defined to the tool. The automation of the task is actually made easier if you take the "high-risk" data element approach, described above, because the chances are slim that you can define all your various types of "confidential class" data uniquely to a data searching tool.

The "questionnaire approach"—E-mailing a questionnaire to all the departments in your organization asking: "Do you folks happen to have any confidential data lying around in your various systems unprotected?" tends to lead to, shall we say, "underreporting" of the problem. I think you can guess why. (By the way, if you want to know what tools people recommend, either check out the Knowledge Base or send me E-mail.)

Beyond the "Cardholder Environment." One of the things that PCI implicitly (but not explicitly) requires is that you separate the cardholder environment from the rest of your systems via one or more internal firewalls to create a DMZ. Exciting stuff, to be sure. It just turns out to be a fairly artificial construct when it comes time to protect "the rest" of your confidential data. It’s at this point that you’ll wish you’d thought to apply PCI security standards to SSNs and other confidential data up front. Because, now, you’ll likely have go back and retrace your steps in the network design and redraw the boundaries (via more internal firewalls, perhaps) around the broader set of confidential data. It’s a certainty that SSNs and account numbers and trade secrets are on more, and different systems than credit card data.

Don’t Forget Access Controls. Once you’ve redrawn your boundaries around the larger set of confidential data, then you need to apply the same set of access controls to these additional applications, databases, files, etc. Frankly, this process requires a separate column. So, we’ll save it for next week. That will give you the rest of this week to complete the steps above. Be sure to let me know when you’ve finished your "assignment."<grin>.

Again, if you want to discuss this column or any other security or compliance issues, please send me an E-mail at or visit and click "Get Involved" to join the PCI Knowledge Base.


Comments are closed.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.