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.If we think the five users' smartphones have a copy (admittedly, this assumption may be a stretch), we get to 17 locations and then to 22 when the users sync their phones to their home computers. Because most users back up their home systems, we now have 27 locations before considering any Windows restore points, which could take us up to 32 locations.
All these locations sprang from one digitized fax, and I'm not even counting the paper backup or the electronic copy remaining on the fax machine's internal memory. And you thought only Tribbles could multiply this quickly!
Even low-tech backup systems expand your PCI scope. Printed order forms used in callcenters or sent in by customers frequently contain PAN data. Many merchants retain these forms in (hopefully locked) file cabinets as a backup system in case of a dispute. Sometimes the forms are scanned into electronic databases.
Smart retailers and their callcenters design their forms to place the cardholder data on the bottom, so it can be easily separated and shredded once the transaction is authorized. Simply scratching out the PAN with a pen or a marker does not count as truncation for PCI compliance purposes. You can still read the PAN pretty easily by tilting the paper or holding it up to the light.
Merchants mistakenly keep these paper records as a backup system. They think they need the data in case of a dispute. Hopefully, Visa's recent guidance will convince these merchants they don't need to keep these complete records. Merchants need to store payment data--name, date, amount, first six or last 4 digits of the card--for any number of reasons, but they do not need to keep cardholder data.
The spread of cardholder data and your PCI scope gets more complicated when card security codes are involved. These codes (e.g., CVV2, CVC2, CID) are never to be retained after authorization. Unfortunately, retailers can inadvertently store these in backup paper records or electronically in forms they have scanned into a database.
As we reported back in April, the PCI Council is very well aware of the risk in data backups, both those you know about and those unknown-unknown ones. I expect version 2.0 of the PCI-DSS will require every merchant to have some process or procedure to locate all their cardholder data. I do not know what they will require or how frequently (i.e., annually during your compliance assessment or quarterly like vulnerability scanning). What I do know is that data storage is a dynamic process, and just because you checked last week doesn't mean someone hasn't done something new today.
What do you think? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].