The data you never meant to store

1. Account numbers on other media. There is a tendency to think that the PCI standards address only your computer system. That's not true. But so often we worry about network security while ignoring the sensitive information floating around our offices on paper. Many organizations receive credit-card numbers on mail-in order or donation forms. If  you do this, you need a policy for rendering this information unreadable. And you need to verify that users are trained to use the techniques properly. A security auditor I spoke to said that he reviewed an organization where staff conscientiously blacked out account numbers on printed registration forms with a marker. Nonetheless,  the number was still fully legible on nearly half the forms he looked at. Common sense - and a shredder - can go a long way toward eliminating this risk.

2.  Account Number Skimming. Whether or not you store credit card numbers, you have them in your possession briefly. There is a real risk that card data can be hijacked on its way to verification.  Security folks call this "skimming." Skimming can be performed by sophisticated hardware devices that monitor your internet connection for unencrypted credit card data, or software apps that install themselves on your client machines and look for credit-card numbers as they are typed.

But sophistication is not a requirement for skimming.  Again, PCI is not just about securing your computer systems: it's about securing cardholder data. A rogue staff member taking telephone orders or donations, for example, might cut and paste account numbers into notepad and later take them home. You need to be aware of this possibility and have procedures in place to sample and monitor staff handling of cardholder data to lower the risk of staff skimming.

More about skimming here.

3. The data you never meant to store. Statistics show that 63% of credit card data breaches involve the compromise of data that was not known to be stored.  This is a frightening number. It means that despite your policies about the handling of credit card data,  there is the very real possibility that you have unsecured cardholder info on your servers or desktops. And odds are your staff put it there for what they perceive as valid business reasons.

For example, a department may keep a list of credit-card numbers that are billed monthly in an excel spreadsheet instead of figuring out how to use the secure system that's been installed to manage this.  They know it is not policy, but they are not really aware of how this puts the organization at risk.

Another source of cardholder data leaks might come directly from the IT department itself. I'm thinking of card numbers that appear in log files and debugging output from software applications -- output that should have been shut off before the system went into production. For example, we had a programmer who developed a routine for compliant triple DES encryption of card-holder data for a client of ours. But when he installed it at the client site, he left a log file turned on that he'd been using to help get the program working in the first place.  So while there were no plain-text card-numbers in the database, there were plenty in the debugging files sitting unprotected on the server.  Fortunately we discovered this before any malfeasors did.

Even PA-DSS certified payment applications may produce these sorts of logs of sensitive data when operated in debugging or test modes.  The PA-DSS standard requires that such applications provide an Installation Guide that clearly states which options must be set for the application to run in a compliant way. Custom applications, of course, are not eligible for certification as PA-DSS compliant and so cannot give you quite this level of comfort.

Fortunately, there are some software tools available to help you determine if there are credit card numbers stored on your servers, and where they are.  The most widely used is the Spider application developed at Cornell University. Spider is a piece of software designed specifically to look for credit card numbers, social security numbers, and other sensitive data elements. Scanning your servers regularly with a tool like Spider should be a regular component of your compliance program. And remember, once such files are found, deleting them is not enough - applications that look for card-holder data can often still find them, since deletion does not wipe your drives clean -- it just drops files from the directory. Indeed, Spider itself will detect credit card numbers on the disk drive even if the file they were in has been deleted.