Evan Schuman's StorefrontBacktalk

Often transmitting unencrypted confidential customer data over weakly-protected connections, retailers risk privacy and create backdoors for cyber thieves. And yet, no one’s giving the merchants much of a choice.

When retailers make changes to any system that might impact credit-card processing?be it point-of-sale upgrades, OS patches, database changes, connection improvements, etc.?it needs to be tested.

For the test to be meaningful, it needs to replicate every aspect of the transaction, all the way through to the card processor deducting the money from the customer’s account and crediting it to the retailer’s account. That means the credit card number, expiration date and verification code must be recognized by the various banks that get involved in the many different kinds of credit and debit cards out there today.

The best theoretical way to deal with these tests would be to use specially-created data that is not linked to any actual customers and is designed solely for the purpose of these kinds of tests. To date, no one has spent the time?nor the money?to create such data. That leaves retailers with few options and most use real customer data.

Even worse, security budgets are finite and live externally-facing systems are going to be the priority. In short, these test connections have live customer data?often unprotected?and it’s being transmitted in relatively non-secure means. Many in the retail industry see this as a recipe for security disasters.

“Some 90 percent of the retailers out there don’t even realize how big a problem test data security is because they don’t know the test environment,” said David Taylor, president of the PCI Security Vendor Alliance. If auditors knew what to look for, “you could easily have 75 to 85 percent of retailers fail on this criterion alone.”

Although Taylor said that few retailers understand this, that ignorance is not shared by cyber thieves looking for the easiest way to get into retail networks. “External hackers and (ill-intentioned) internal IT people,” Taylor said, “if they’re going to attack anywhere, they’re going to attack a weak link. This is one of the most well known weak links. If you’re going to attack, this is where you’re going to attack.”

The question of protecting customer data during retail POS testing is also a concern of Richard Simpson, a 21-year Bank of America veteran who recently took a newly created position at the Federal Reserve Bank. Simpson’s new job?Senior IT Risk Coordinator within the Fed’s banking supervision and regulation area?gives him the daunting task of “raising awareness of risks which might undermine public confidence in the U.S. financial system.” Clearly, Simpson sees retail test data procedures as just such a risk.

“A vulnerability that the Fed has observed during supervisory reviews is the practice of retaining unencrypted test data. Often large amounts of data will be pulled into a separate file for use as test data to verify program patches, run volume tests or simulate production output or reporting,” Simpson said. “The proper approach for temporary data is to destroy it immediately after use, to encrypt it if future use is planned, or to mask fields containing any customer confidential information.”

But that’s not typically happening, he said. “Companies often consider test data to be less vulnerable than live transaction data and, therefore, take fewer precautions. Test data may also be accessed by third parties?such as vendors and outsourcers–more frequently than live data,” Simpson said. “Yet if the test data contains reusable customer information?credit card numbers, social security numbers, name and address?it can easily be used for fraudulent purposes if accessed by internal or external hackers.”

Beyond the clear threat of cyber thieves accessing the data and penetrating the network?potentially leaving Trojan Horse programs to do more damage later?the use of such test data can also create problems later on when attempts are being made to both catch the thieves and to identify what was taken.

“If a fraudulent intrusion occurs, companies often have a difficult time certifying what data was in old test files breached by hackers,” Simpson said. “This is one of many challenges faced by TJX as it has attempted to verify the number of accounts accessed by Internet criminals who hacked into their systems.”

Some retailers have tried to mitigate the damage by using older customer data, on the belief that such data would have outdated information, that might be less valuable if intercepted. But Mark Rasch, the former head of the U.S. Justice Department’s high-tech crimes unit and currently a security consultant, questions that premise.

“The fallacy is that there is something called ‘old data,'” Rasch said, adding that most credit card information?including name, address and often the credit card number itself?does not change with any frequency. “What’s personal about me tends to remain personal even with the passage of time,” he said.

The credit card’s expiration date will periodically change, but there’s such a small number of possible month/year combinations in the typical 2-year period that a thief could simply try them all until the right combination was discovered.

Rasch also has concerns about whether the use of such information for network testing violated “the implicit agreement between the merchant and the customer” that “you get my data for certain purposes, primarily to sell me the product and to validate payment.”

As for why test data hasn’t been created to safely test systems, Rasch said it’s a matter of money. To make it work, the test data would have to have a lot of numbers, with segments created to replicate various banks and other processors. It would do a retailer little good, for example, to test a Visa connection using a MasterCard number or even a card number from one major bank when testing a different bank’s card. “The question really is, ‘Who’s going to pay for it?’,” Rasch said.

Money is also behind the lack of security on the networks transmitting the test data, said the PCI Security Vendor Alliance’s Taylor. “These people are operating on a limited budget. What you secure first is the production environment and anything that is outwardly facing,” he said.

As for protecting the data itself, that’s a combination of laziness coupled with cheapness, Taylor said. There is a way to properly sanitize test data, he said, but it’s a lot of work.

He cited one insurance company that was testing with non-sanitized test data. “They didn’t have any way of generating test data on an enterprise basis. No tools, no procedures, not even a policy. They had no system-level prevention at all,” Taylor said. “They were using production data without masking, without encryption, without scrambling.”

Why? “Hey, it’s hard. Unless someone makes them do it, they’re not going to do it,” Taylor said. “You need policies. It’s so much easier to just copy production records.”

Is there a way out? Taylor said such numbers could be created by a group of card issuers coordinated by some overarching entity, such as Visa or some other industry group. Why has it not yet happened? Said Taylor: “I just assume it’s not their priority.”