In a few days, retailers that accept payment card transactions are required to protect all Web-facing applications against attacks by either installing application-level firewalls in front of Web-facing applications or by doing application code reviews.
The requirement is spelled out in section 6.6 of the Payment Card Industry Data Security Standard (PCI DSS), established by the major credit card companies, including Visa Inc. and MasterCard Inc., to ensure the privacy of customer information. On June 30, the recommendation goes from best practice to compliance requirement.
What does the mandate mean? It means vendors are swooping in with products that promise to automate code review and make you PCI compliant. For example, Solidcore Systems Inc., a change control system provider in Cupertino, Calif., offers an embedded PCI product for point-of-sale (POS) devices that promises to protect against attacks like the Hannaford Bros. Co. breach in March.
Of course, security experts are at the ready for comment. The eminently quotable Gartner Inc. security analyst Avivah Litan has observed (everywhere) that most of the Stamford, Conn.-based firm's clients will indeed not be ready by June 30. And that most clients are opting for the application firewall rather than taking on the more onerous job of auditing their applications for flaws and fixing them.
But the important thing to note about the June 30 mandate, say many experts -- including Litan -- is that what is true about 6.6 is what has been true of PCI standards in general: The mandate is insufficient. Neither fix alone -- the firewall or the review code -- is enough to protect consumer data in Web-facing apps against attacks and, consequently, neither is sufficient to protect your company's reputation.
Critics of the PCI compliance standards point to the Hannaford breach, which was PCI-compliant when secret malware installed on servers compromised more than 4 million credit and debit cards.
The PCI rules are written as standards, not laws, but noncompliance may pose legal risks for retailers, nevertheless. David Navetta of InfoSecCompliance LLC, writing in SC Magazine, believes standards such as PCI, set by a private body, could pose more risk than traditional government regulations. He advises merchants to engage their legal teams on PCI compliance.
Still, security expert Joseph Miller, an engagement manager in the technology risk management practice at Jefferson Wells International Inc. in Milwaukee, said the 6.6 requirement is important, even "though it may or may not be enforced by the merchant banks or card brands." (Another hallmark of the PCI standards is that the group hasn't gone after offenders.)
"I think it is good to become PCI compliant, but you need to assure that you have your own best practices in place and test your own processes," Miller said.
He recommends to clients that they definitely take the PCI self-assessment questionnaire but also do their own internal testing. For example, restaurants would want to look at their process for accepting credit cards and use a data diagram that shows the actual path the cardholder data takes into the point-of-sale (POS) system, as well as the optimization of the transaction itself as it goes to the merchant bank or card company for processing, Miller said.
At the core of good practice is the protection of cardholder data, as well as the card's authentication data during the transaction, said Miller, who is a certified PCI assessor. He offers three recommendations for companies that accept payment card transactions for protecting cardholder data:
- Minimize storage time as much as possible. To do that, "you need to determine in the course of doing credit card transactions how long do I really need to keep the cardholder data," he said. In the hotel industry, where Miller has done considerable consulting, the data needs to be kept for the duration of a guest's stay. There are also regulatory considerations. Nevada, for example, requires retailers and casinos to keep credit transactions for as long as two years, in the event of disputes.
- Always store the primary account number in unreadable format (masked, except for the last four digits).
- Encrypt the data if it needs to be stored for any length of time. Encrypt the data while it is transit, using protocols like Secure Sockets Layer and IPsec.
Let us know what you think about the story; email: Linda Tucci, Senior News Writer