What’s Missing In The New PCI Regs?
Written by Evan SchumanAugust 22nd, 2008
When the PCI Security Council this week detailed a bunch of changes it will include in PCI 1.2, what might be more worthy of note is what they didn’t address.
There were technical issues—such as segmentation and tokenization—that didn’t get referenced, but also policy issues. Why isn’t there a more clear-cut appeal process, for retailers who believe their assessor is improperly interpreting the rules? Today, the council will try and address technical questions, but that rarely involves overruling an assessor. Visa has been known to get involved with a retailer who has an assessor complaint, but that’s a very rare occurrence. Read more.
August 22nd, 2008 at 10:16 am
Good points on QSA conflicts of interest — all of them. Right now, the best way to respond is to make sure to send in the “QSA feedback form” to the PCI Council detailing your experience. Didn’t get one from your QSA (or ASV, for that matter)? They must have forgotten to give it to you… No problem: download the form from the Council’s website (https://www.pcisecuritystandards.org/) and send it in. The Council has been talking about their quality assurance program for QSAs, but if merchants don’t send in their experiences nothing can be done to get rid of the ethically-challenged or simply incompetent ones. And to be fair, there are a lot of pretty good QSAs out there who share your opinions.
August 22nd, 2008 at 6:17 pm
I fully agree that some QSA’s are pushing wares that they have some sort of vested interest in pushing. I would go one further. I suspect that some conflicts of interest start in the committees that are creating the PCI requirements. Case in point, PCI 6.6:
6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:
• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.
A few discrepancies here that throw up a red flag in my mind: 1) Code reviews and application layer firewalls (ALF) or web application firewalls (WAF) address different aspects of security. 2) Organizations and individuals that specialize in application security are not governed or certified by any controlling body, so therefore there is no consistency or confidence level in their offering. 3) Since these organizations are not governed, does PCI-SSC accept any liability for zero day (or zero hour) exploits attributed to a less then ethical organization? (watch how many Russian and Chinese startups pop up in the near future that “specialize” in application security) 4) Does PCI-SSC accept any liability for loss of trade secrets from these same unethical organizations? 5) To my knowledge, ALF/WAF’s do not re-encrypt on the application side so this forces cardholder data (CHD) to be transmitted in the clear within the DMZ – to me, this opens a larger hole than it plugs. 6) Lastly, what happens when PCI 1.3 comes out requiring CHD transport encryption on both public and private networks to plug the Hannaford exploit? Are people purchasing ALF/WAF’s today going to have to fork out upgrade fees or repurchase in the near future or will they be grandfathered in leaving a long term security hole?
Numbers 3 & 4 above are referring to the thin grey line that separates white hatters from black hatters (ethical vs. unethical hackers). I’ve ranted enough on 6.6. Other sections have similar discrepancies, though not as glaring. IMHO, this tells me that whoever added this language was dabbling in something beyond their expertise or multiple parties with different agendas threw this section together.
While I believe that PCI has been a great benefit to the point of sale industry, I also believe that more thought and oversight needs to be put into the development of the program. One idea that I think would help, a thorough intentions document; one that states the goal and risk that this requirement is litigating. The intent must go beyond “annual key changes – this is a best practice.” If the thorough intent was a prerequisite to rule additions, changes, or the existing requirements, this would help point out conflicts and discrepancies to whomever was overseeing the program.
Steve Sommers
VP Applications Development
Shift4 Corporation — http://www.shift4.com