Tuesday, March 31, 2009

On PCI DSS Compliance


Data security best practices for PCI DSS compliance

David Mortman, Contributor 03.31.2009

PCI is not perfect, but the point isn't perfection.


Every time a company that is compliant with the Payment Card Industry Data Security Standard (PCI DSS) is breached, the masses form with their torches and pitchforks and declare that PCI doesn't work. This was the case with two recent high-profile data breaches: the March 2008 Hannaford Bros. Co. data breach and January's Heartland Payment Systems Inc. breach.

The problem isn't that PCI doesn't work. The problem is the perception that if a company is PCI compliant, it is secure and will never suffer a data breach. The reality is that PCI, like any other regulation -- be it HIPAA, GLBA, etc. -- merely sets a baseline for what needs to happen in order to handle certain kinds of data securely and to avoid fines, loss of services or license to operate. In the case of PCI, it means that when (yes when, not if) a merchant or other company involved in the payment-processing life cycle faces a security problem, it won't be fined by Visa, Mastercard or one of the other members of the PCI Security Standards Council.

PCI is not perfect, but the point isn't perfection. Rather, the idea is to raise the bar to a reasonable level. PCI DSS version 1.2 has corrected several issues from earlier iterations, and the standard will surely continue to evolve as the PCI SSC identifies portions that don't work well or issues that were missed in the past. Case in point: in both the Hannaford and Heartland breaches, the miscreants were using Trojans to pass personally identifiable information (PII) to external servers over the Internet. It would be surprising if the next version of the PCI standard did not mandate some sort of monitoring of outbound data flows for PII.

Continue Reading at SearchSecurity





Reblog this post [with Zemanta]

Disqus for ePayment News