:: extra ::

According the Visa, the most common violations leading to merchants flunking audits include:
-un-patched systems
-poor password policies/enforcement
-unnecessary and vulnerable services on servers
-using insecure default settings, such as unencrypting wireless connections
-poorly coded web-facing applications resulting in SQL injections and other vulnerabilities
-finding and the storage of prohibited data (such as account numbers, CVV2, PINs)

PCI is widely praised for its specificity. Compared to omnibus mandates such as FISMA or SOX, this is definitely true. However, do PCI's prescriptions set merchants up for failure before they even try to comply? In the case of the last 2 bullets, this is clearly the case.

First, "Poorly coded web-facing applications resulting in SQL injections and other vulnerabilities". PCI mandates pen testing--yet try to find anypen test who can confidently say, "Yep, my test or pen testing tool was 100% thorough." Pen testing will always fail to miss issues. So when a PCI auditor comes around and finds a flaw then--poof--you're on the PCI black list. Merchants, auditors and regulators should note what Gary McGraw has said, "Black box testing is a 'badnessometer.' Everyone should buy a badnessometer to find out that they're in trouble and use static analysis to fix it."

Second: "finding and the storage of prohibited data (such as account numbers, CVV2, PINs)"
Why the difficulty? Many merchants have so systems including transaction processing, loyalty tracking, custom applications and so forth. Sniffing out all of the potential places, such as log files, is not easy in complex environments. Yet PCI only requires manual code audits to sift through the code.

I don't mean to knock PCI. On the contrary, it's a good idea and I'm always in favor of industry self-regulation. PCI has several components that help stop cyber fraud. But PCI technology prescriptions should be designed to help merchants pass their audits.