tssci security

PCI DSS questions left unanswered

Chris Eng of Veracode, attended the first PCI Community Meeting in Toronto, an organized panel that brings QSAs, ASVs and those subject to PCI together with the PCI DSS council, and lives toblog about it. Several days ago, I posted some thoughts on the PCI DSS and several of it's ambiguous requirements. Chris is left with some of the same unanswered questions and more after attending two panel discussions -- one covering the Payment Application Data Security Standard (PA-DSS) and Requirement 6.6 of the PCI Data Security Standard (PCI-DSS).

On PA-DSS and Visa's Payment Application Best Practices (PABP):

The panel outlined the changes to PABP as follows:

Unfortunately, this was the extent of the detail. I wanted more information on the enhancements but didn't get a chance to ask a question due to time constraints. Specifically, it would be nice to understand whether code analysis would be an alternate option for the penetration test requirement. Or what exactly they meant by using forensic tools to examine the application's output.

Interesting... I'd like to know more about "using forensic tools to examine the application's output" as well. In my previous post, I specifically wrote in regards to PCI DSS Requirement 6.6:

*6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:*

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.

So which method is it? One or the other or both? Installing a WAF lets you skimp on code review? What about maintaining the WAF after installation? This requirement should be reviewed and changed to specify what is required and like Requirement 1.1.6/7, should have an extra clause.

Well, the panel did not answer much about that either, and Chris had other question's regarding automated source code analysis and whether it would satisfy the requirement for code review. Due to false positives/negatives, an automated source code analysis would not satisfy it and would still require a security professional to do the review. Chris brings up a point on benchmarking WAFs for false positives/negatives -- since as it's written, Requirement 6.6 is an either-or and a security compromise to take.

So there are a lot of questions left unanswered, and unfortunately the questions asked were ones that any QSA/ASV should be able to answer. The technical meat behind PCI was left on the backburner. doh!

Posted by Marcin on Friday, September 21, 2007 in Security.

blog comments powered by Disqus
blog comments powered by Disqus