Evan Schuman's StorefrontBacktalk

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

Are your automated backup systems expanding your PCI scope? Almost everyone agrees that backing up your important data is a smart thing to do. Except, that is, when it’s not. The problem starts when your sensitive data seeps into places you don’t expect.

Your backup systems then unintentionally spread cardholder data to locations you don’t suspect and expand your PCI scope in the process. Should you be concerned? I think you should be, and I’m not the only one–the PCI Council thinks retailers may have a problem, too.

As a QSA, once I identify where cardholder data is stored, I start asking about the backup systems to see where else data could be lurking. This plan works pretty well when we think we know where all the data is stored. But it can’t handle situations when the data has leaked to locations we don’t know about.

The answer is to go beyond the network and dataflow diagrams to find your cardholder data–all of it. Then, once you have found the data, start checking for backups.

The problem begins because cardholder data has a way of leaking into all kinds of unexpected places. Sometimes this leakage is from users violating company policy: They copy data to their laptops or local databases, sometimes synching to mobile devices. When these systems are backed up, the data is duplicated in new places, compounding the problem.

The data leakage is, however, often not intentional. A colleague of mine recently encountered a large store of PAN data on a client’s network. The source was a workstation previously used for testing that was transferred to another user without first being purged of all cardholder data. The new user had no idea what was on the computer, which–naturally–was backed up daily.

Data may also be unknowingly backed up when an application uses Windows restore points. I have noticed that some PA-DSS application providers instruct users to disable the restore point feature in their implementation guide. This situation is a case of an “unknown-unknown.” That is, you have data you don’t know you have, and it is stored in a location you don’t know to search. Unfortunately, because this system likely was backed up, you have an unknown-unknown backup to deal with, too.

E-mail systems may complicate the problem. I sometimes run into situations where people send and receive E-mails containing PAN data. PCI Requirement 4.2 specifically prohibits the practice of sending unencrypted E-mails with PAN data, but it happens on a regular basis. For example, callcenters E-mail PANs internally, which they should not do. Similarly, acquirers (and even some issuers) can send full PANs in unencrypted E-mails and faxes to merchants as part of their dispute resolution process or reporting for corporate cards.

Every E-mail system I’ve seen has automated backups. As such, we can assume that this PAN data exists not only in the original E-mails but on the recipients’ and the senders’ computers as well. And now it’s in the company’s E-mail backup and maybe in each user’s own backup.

Let me illustrate how cardholder data can spread: An automated system sends a single fax with cardholder data to an E-mail distribution list of, say, five people. The data is now on your mail server and on five workstations. Next, those five workstations and the server are backed up, getting us to 12 locations storing electronic cardholder data.