I read with interest the recent column by Eric Ogren, Hacker charges also an indictment on PCI, and wanted to respond to negative suggestions aimed at the PCI Data Security Standards inferred.
First, Eric's analogy that there is "fraud conducted by PCI" when speaking about retailer and processor responsibility for keeping payment data safe is misguided. This type of hyperbole is great blog fodder, but does nothing to address the problems facing the industry. Does Eric believe that those who handle payment card data should have no responsibility in keeping that data secure? Is he really advocating a "get out of jail free" card to every Heartland, TJX or other organization that fails to adequately protect their data because of a perceived burden for businesses to accept their responsibility? Let's look at this as another analogy: If your house gets burglarized, it is a shame. If it got broken into because you forgot to lock the doors, or left all the windows open, it is still a shame, but part of the shame falls on you for not taking the necessary steps to protect your home.
Compliance does not equal security, experts say:
External attacks start with unintentional mistakes, survey finds: More control over user rights and access privileges could help mitigate the risk of employee errors that lead to costly data breaches.
Hacker charges also an indictment on PCI, expert says: PCI places the burden of security costs onto retailers and card processors instead of on the card payment brands, says security columnist Eric Ogren.
It has always been the PCI Security Standards Council's assertion that everyone in the payment chain, from (point-of-sale) POS manufacturers to e-shopping cart vendors, merchants to financial institutions, should play a role to keep payment information secure. There are many links in this chain -- and each link must do their part to remain strong.
Eric also cites the "burden of security costs" placed on merchants, then goes on to suggest an additional expenditure for "cash-constrained SMBs" by mandating a certain piece of equipment/software on their POS systems. This dichotomy demonstrates the complexity of the issue at hand and the oversimplification of potential solutions. Chip and PIN has not eradicated card fraud in the U.K., and encryption won't stop it single-handedly either. Simply put, there is no silver bullet to payment security and no single technology will make everyone secure.
The council is in a truly unique position, with relationships with every facet of the payment chain and is using this insight and feedback from hundreds of voices globally to help revise the standards in a manner that takes into account the varied deployments, legacy systems and infrastructures involved from everyone from a large, multinational retailer, to the bodega around the corner. In September, we will host all of these stakeholders at our community meeting, and hope to come away with a vast amount of feedback to incorporate into the next iteration of the data security standard.
This is very similar to what occurred that allowed us to update the standard from DSS 1.1 to DSS 1.2. I bring this up to address another element from Eric's article, where he describes the prevalence of SQL injection as a popular attack methodology. Here, the PCI SSC couldn't agree more. In fact, for years we have been pushing organizations to shore up their defenses against this common form of attack. As a matter of fact, one of the biggest changes from DSS 1.1 to 1.2 was the update of requirement 6.6, which looks critically at application code to test for the presence of Web application vulnerabilities. In fact, if you search this very website you can find many examples of interviews in which I draw attention to this change in the standard and illustrate the potential danger of SQL injection attacks. This danger is challenged throughout the standard with various requirements around secure application development and the use of scanning products that can highlight vulnerabilities to this type of attack.
With high-profile breaches still resulting from this form of attack, IT departments remain challenged. For anyone interested in learning how to better protect from these attacks, the council has created informational supplements that deal with code reviews, application firewalls and penetration testing.
Above anything else, we share Eric's frustration at the recent spate of data breaches. However, we will only be able to improve the security of the overall payment environment if we work together, globally. It is only by working together that we can combat data compromise and escape the blame game that is perpetuated post breach. The council is excited about the next phase in the development of PCI Standards and encourages breached entities and other stakeholders alike to actively and constructively participate in the evolution of the standards.
Bob Russo is general manager of the PCI Security Standards Council