I’m going to aggregate several PCI related things here in one post as it has been a busy week in PCI Land! I have other things I want to write about, so stay tuned for more stuff later today and throughout the week.

First off, the Council has released the Payment Application Data Security Standard (PA-DSS). This replaces Visa’s Payment Application Best Practices program, and your Point Of Sale application should comply by July 2010, or your customers may not be able to accept Visa cards! Nothing we did not already know, but it is now finally released.

Next, the Council also released clarifications on Requirements 6.6 and 11.3 (apparently a very hotly debated topic in a recent QSA Requalification class). There are two very important issues to pull out of the clarification.

On Requirement 11.3 (annual penetration test), the clarification makes mention that the penetration test should also include an on-site (or internal) penetration attempt. This will drive the cost of these assessments up a bit, but I think there is some room for innovation. Just depends how risk-averse a company really is.

The real doozy is on Requirement 6.6 (periodic code review or web application firewall on all web-facing apps). There really appears to be overlap here now. In lieu of a code review or web app firewall, the Council has elaborated on how the intent of a code review can be carried out. They say that a “Manual web application security vulnerability assessment and/or proper use of automated web application security vulnerability assessment (scanning) tools” can be used in lieu of an actual code review.

In a normal application penetration test that VeriSign performs, we already would perform the above. Does that mean if you get a Penetration Test by VeriSign that you automatically comply with both 11.3 and 6.6? If we take the guidance of the Council, it does.

I was disappointed by the 6.6 clarification as it does not seem to have legs any more. VeriSign typically recommends that a code review be performed as part of your PCI strategy. We believe that you should fix the problem at the source (pun intended) instead of trying to put another filter in-line. Passive web application firewalls have their place in any sound security strategy, but the fact remains that the most effective way to remove the threat of these vulnerabilities is to fix the problem in the code.

As an example, during a recent code review we performed, we found several vulnerabilities that could be exploited that would not be caught through an automated tool, and yet could be exploited remotely. When you are working with the code, you don’t need to manage the mask of the interface.

In other news, Visa released a bulletin on packet sniffing cardholder data, no doubt in response to a recent breach. VeriSign has often recommended using encryption over the wire to help reduce insider threats. Visa echoes that strategy in the recommended mitigation section.

OK, enough PCI for today!

This post originally appeared on BrandenWilliams.com.