Dennis Hurst posted the interesting response he got from the PCI Council on the same question many people had about this section. I'm going to have to copy/paste large sections of his original post to keep the flow somewhat linear.
Section 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
Does this mean an an organization must hire an outside firm to do a source code review, black box pen-test or what? Can this same process be satisfactorily performed by internal staff with a commercial scanner? What scanner?
The "official" response Dennis received:
The answer to your inquiry is as follows.
Using specialized 3rd-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the 3rd-party tool also has the internal expertise to understand the findings and make appropriate changes.
The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects). The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for.
Thank you and regards,
The PCI Security Standards Council Response Team
Here is Dennis's conclusion:
Hold on there pilgrim. (Always wanted to say that) That's not exactly accurate and advice that could get an organization is some hot water. TWICE the PCI Council stipulated that internal staff have the appropriate skills and expertise:
"also has the internal expertise to understand the findings and make appropriate changes"
"when internal staff have the skills to use the tool and fix defects"
My question now is how the heck is that going to be checked for? What would be the minimum bar? Will every brand X scanner start giving away user certification with each proof of purchase? Talk about a serious conflict of interest. The problem is there's no industry standard certification for web application security proficiency. I've talked about the need for a Web Application Security Professional Certification in the past.
Anyway, I'm glad we got even a little bit of clarity so now that we can move onto new bits of ambiguity. It keeps things fresh. :) Plus it'll be nice when PCI eventually documents what scanners should be able to identify and what web application firewalls should be able to block. Won't that be nice.
4 comments:
Ah, but the not so big secret is that the specification/standard is only sort of improving security. It is really about having a set of minimum standards we seek to enforce, whether they really improve security or not. We can easily find a number of the items in the standard that don't as much increase security as they baseline what you ought to do if you don't have a good security program to begin with.
App Vuln scanning, just like network vuln scanning isn't sufficient to demonstrate a problem. Finding an issue tells me I have a problem, not finding and issue doesn't tell me I don't have a problem.
Alas.
Jeremiah: This pilgrim is holding :) You make a good point. People absolutely need to be trained before they start using a tool for PCI testing, or any other web app testing for that matter. I should have made that point MUCH more obvious but I was only commenting on the ambiguity in section 6.6 as it related to acceptable techniques for testing, not a relative level of skill someone should have. I started asking this questions because that section is not very clear on what specific technique is acceptable to meet the 2008 requirement. I completely agree that whatever technique someone decides to use the person that is doing it needs to be properly trained and have appropriate experience in web application testing. How we define “properly trained” and “appropriate experience” is an entirely different can of worms we can open in another post :)
I think you bring up a much larger issue. There are all sorts of people running around doing manual testing and/or using tools to test web apps that have not taken the time to learn the fundamental skills they need to do a proper application assessment. Thanks for catching my error, you pointed out a very important point.
Have a great day,
Dennis Hurst
@Security Retentive
"App Vuln scanning, just like network vuln scanning isn't sufficient to demonstrate a problem. Finding an issue tells me I have a problem, not finding and issue doesn't tell me I don't have a problem."
I like that phrase. Always the conundrum in VA, how do you know when to stop looking? :)
@Dennis
Yah, I figured we were on the same page, just had to be spelled out.
"There are all sorts of people running around doing manual testing and/or using tools to test web apps that have not taken the time to learn the fundamental skills they need to do a proper application assessment."
What tools? *just kidding* :)
"Thanks for catching my error, you pointed out a very important point."
No error, just one of those things. Thanks for posting the councils email. That was good stuff!
I believe an important issue that is being forgotten when people think of "source code review" is that the review is only one portion of the overall process. Most people do not factor in the remediation portion of the process. I could probably be convinced that a manual source code review vs. review with a source code analysis tool vs. running web vuln scanner could all yield roughly similar results - they identify what the problems are. What about fixing the actual issue?
This is the core issue in 6.6 - to prevent successful web attacks. If you refer to the PCI DSS Security Audit Procedures document here - https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf - section 6.6 Testing Procedures state the following:
6.6 For web-based applications, ensure that one of the following methods are in place as follows:
- Verify that custom application code is periodically reviewed by an organization that specializes in application security; that all coding vulnerabilities were corrected; and that the application was re-evaluated after the corrections
So whether or not the vulns were identified by source code review or a scanner is not the main issue but was the vuln actually fixed??? It is the process of actually remediating the vulns that is really taking a long time, if it happens at all. I mean, how many times does an ASV find the exact same vulns showing up in scan after scan?
If you look at the 2nd party of the 6.6 testing procedures, it states this for WAFs –
- Verify that an application-layer firewall is in place in front of web-facing applications to detect and prevent web-based attacks.
Notice that the WAF has to be in block mode. So, just because an organization deploys a WAF is not enough either. You need to be blocking stuff (mainly SQL Injection and XSS as they are the only 2 that are considered HIGH severity). It is for these reasons that I believe that 6.6 is geared towards remediation efforts and not just identification tasks.
Post a Comment