I welcome the clarifications and hope to see more in future.

One thing about 6.6, the wording of the clarification, specifically “Proper use of automated web application security vulnerability assessment tools” would appear to say that the web application security penetration test could count towards this. Now I would think that the intent is to do more. I can’t help think that this wording will cause confusion.

The details of the clarification on penetration testing appear to include a reversal from earlier positions. Previously there was some appetite for testing that did not actually exploit vulnerabilities. However, simple scans would not have been sufficient. The methodology would have to have provided a comparable analysis in order to meet the intent. The clarification seems to have come down solidly on the side of exploitive pen testing.

So does 6.6 Option #1 -Code Review #4 bullet point = 11.2b?

Rob, In my opinion, no. They are different animals. The code review is looking for vulnerabilities to OWASP 10. The network scans are establishing patches and AV are in place.

But, if you look at the ASV scanning procedures and the requirements to scan web servers, I would say yes. ASV must scan as part of their procedures any of the OWASP 10 that do not perform DoS attacks or the potential to bring down the server. To add one more point, I believe the combination of 11.2b and 11.3 for application layer pen test definitely covers the OWASP 10 and in turn meets the new 6.6 clarification.

I believe the PCI Co definitely open the door. Plus, in the end, I would prefer to see companies use some manual processes.

Web pen tests and ASV scanning are intended to comlimentary controls.

Part of the reason for application pen testing is that effectively integrating testing of custom web applications with quarterly scanning has been difficult, increases testing time, and requires some training of the tools. It’s maturing but not yet there. Also, ASV scanning is required to be non-intrusive whereas pen tests have no such restriction. So these tests are complimentary by design in at least two significant ways.

My take on 6.6 was that this was intended to prevent attacks that these other tests would not find. So the original wording of a code review or a device to block the kinds of attacks that might get through seemed like another complimentary control.

The clarification does seem to open the door to not doing this. But why?

Partially this may be a reaction to expense and industry impact, but I would expect this would be only a secondary or tertiary driver. It may be: a nod to the technology in the web testing tools getting better; or that organizations are having challenges successfully implementing WAFs; or that forensic analysis. Just perphaps the breach experience may be showing that vulnerable sites are full of holes and that bar need not be so high to be effective. And of course it may be something else or a combination of these.

I think the key difference here is likely the “proper use”. The detail of the clarification speaks to integrating the use of tools into the SDLC and change management. That goes beyond the once a year requirement for web application testing.

[...] 11.3 Penetration Testing‘ on the PCI SSC’s website. I will also be paraphrasing Michael Dahn’s post over at pcianswers.com, and related posts in that forum. I will compare/contrast the implications [...]

Mastercard sent a letter to all scan vendors in March 2006 stating that 2 of the OWASP top ten needed to be checked during an ASV scan. These were XSS and SQL injection. Any issues in these categories constitute a failed scan.

If I recall correct, to be compliant, you should perform pentest (e.g. try to exploit holes) of all internal and external systems which are in scope of the audit. But what about crashing systems (real production systems) for any reason during active pentest (exploit fails, etc)? What PCI DSS says about such situations?
Should pentest be performed on test system which are close to the real one? It’s unsafe to allow a pentester (hacker) access to your production environment, isn’t it?

PCI includes a series of complementary tests.

1) ASV (quarterly) scans are required to fail any detected XSS and SQL failures as well as any vulnerabilities with CVSS scores of 4 or more (that are not denial of service). ASV scans also must be non-intrusive.

2) Pen Tests (less frequent) are intented to look in more depth. These would cover aspects of custom web applications that may not be caught in ASV scans. There is also no restriction on being intrusive.

Certainly pen testing on production has risks. One risk mitigation approach would be to test the acceptance test environment first and then production.

So, again I will ask the group. Does ASV (Qtrly) scans plus Pen Test (App Layer) on a web based application equal 6.6 clarification under code review bullet point #4?

My opinion, Yes it does.

PCI SSC should remove the #4 bullet point and then they would have the true intent of 6.6.

I ran across an interesting article that highlights this very problem. Hackers have upped the ante on SQL injections in recent days and we are currently seeing massing across the ‘net SQL injections happening. Hopefully nobody minds that I’m about to reference a different web site:

http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1311815,00.html?track=sy160&asrc=RSS_RSS-10_160

Rob,

I agree, that at first the addition of 6.6 option 1.4 was surprising. It seemed confusing and possibly weakened 6.6. My initial reaction was to question if this could have been a mistake. Others have told me that they felt the same. However, knowing how much work and debate goes into these clarifications, there had to be more to it. When I read the entire clarification I concluded that the key was the “proper use” aspect.

Using and ASV and conducting annual web application pen tests is not sufficient to meet 6.6. The use of this technique must be properly integrated into the entire SDLC. Only then can it meet 6.6.

I don’t know the details of the debates behind this clarification. I’m sure they reflected the public debates and included aspects such as costs, effectiveness, reliability, solution maturity, solution coverage, availability of skills, feedback from early adopters, etc. I’ve been in infosec long enough to know that none of these solutions is perfect and many just won’t work for some organizations. The council must have considered all of this.

So to answer your question, yes - provided there is proper use within an SDLC framework.

Hi,
I would like to ask if we were installing for example the dotDefender - would we be ready for the PCI 6.6 compliance?
I noticed this link:
http://www.squidoo.com/PCICOMPLIANT
Could you please comment on that?
Recommendation on the solution and product if we are handling 20,000 cards per month.

Regards,
Ann