Evan Schuman's StorefrontBacktalk

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 David.Taylor@KnowPCI.com or visit www.KnowPCI.com and click "Get Involved" to join the PCI Knowledge Base.