One of the things that differentiates the leading merchants that we interviewed for the PCI Knowledge Base research, from other merchants, is that nearly 40% 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.  While 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.  So, 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 of the people we’ve interviewed for our PCI Best Practices research have identified some 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 you various types of “confidential class” data uniquely to a data searching tool.  The “questionnaire approach” – emailing 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, we are adding specific vendor listings to the PCI Knowledge Base in early 2009.)

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 re-draw 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 re-drawn 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 three steps above.  Be sure to let me know when you’ve finished your “assignment” <grin>.

If you want to discuss this column or any other security or compliance issues, please send me an E-mail at This e-mail address is being protected from spambots. You need JavaScript enabled to view it .