 | Rough dilemma surrounds the compliance validation of req 6.6 among the QSA’s community. What is the real meaning behind 6.6 and how to validate compliance? My take about this polemic is that this requirement is wrongly expressed and localized in this standard. |
Statement
PCI DSS 3.2 - Req 6.6 states:
For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
- Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually
- Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic.
When questioned about the way to implement a control, the Council uses to pull a rabbit out of their hat through the following answer: Well you have to go back to the intend of the requirement. So let’s go back to the objective of req 6.6.
Objective
PCI SSC states that the intend of req 6.6 is to provide a good level of assurance that web applications exposed to Internet are protected against the most common types of malicious input. In other words: that the code is of good quality and absent of known coding vulnerabilities that could lead to data exfiltration.
Responding to 6.6
PCI SSC allows to respond to 6.6 through the following options:.
Option 1: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually
Option 2: Continually (meaning automatically) filter or block non-essential traffic at the application layer through the implementation of a technical solution (example Web application firewall) in front of the web applications.
And this is where people gets confused.
Option 1: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually
Option 2: Continually (meaning automatically) filter or block non-essential traffic at the application layer through the implementation of a technical solution (example Web application firewall) in front of the web applications.
And this is where people gets confused.
This newsletter addresses Option 1 « The Use of manual or automated application vulnerability security assessment tools or methods »
Many QSA’s expect the use of a manual or automated « tool" to identify and report secure coding vulnerabilities + the accompanying processes. But, reading carefully the statement, one notice the term « methods ». A method being a process, the requirement may perfectly be met through a manual code review for security vulnerabilities. This is reenforced by the following paragraph of the PCI SSC information supplement:
Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:
Many QSA’s expect the use of a manual or automated « tool" to identify and report secure coding vulnerabilities + the accompanying processes. But, reading carefully the statement, one notice the term « methods ». A method being a process, the requirement may perfectly be met through a manual code review for security vulnerabilities. This is reenforced by the following paragraph of the PCI SSC information supplement:
Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:
- Manual review of application source code
- Proper use of automated application source code analyzer (scanning) tools
- Manual web application security vulnerability assessment
- Proper use of automated web application security vulnerability assessment (scanning) tools
- This is part of the SDLC (secure Development Life Cycle) documented and applied processes
- The reviewers do not take part to the code writing (at least for the code they are reviewing)
- Reviewers (and the developers) are trained on secure coding annually.
There are also some confusions wafting around the three other mentioned alternatives
The use of automatic tools
PCI DSS allows the use of automated tools to meet 6.6. This is quite surprising as no automated tool ( source code analyzer or application vulnerability scanner) is able to detect the entire OWASP top-10 spectrum. Furthermore, the testing procedure associated to 6.6 do not require QSA's to validate that all 6.5.x are actually covered by these tools. If tools are used to meet 6.6 they should be used at least annually or after any code change release.
The use of pen test for 6.6
I’m always annoyed with the QSA blunt refusal for accepting a pen test as a response to req 6.6. The usual rational brought forth is « Pen test is required by 11.3 » And….? What is wrong with this? In the mouth of PCI SSC a pen test is a more effective than a vulnerability scanner as it goes further that the simple identification of vulnerabilities by actually attempting to exploit those. A pen test is a manual web application security vulnerability assessment which is required at least annually. For this reason pen test should be an acceptable response to meet 6.6 if and only if it is executed on application prior release into production (On pre-production or staging environment).
Bottom Line
Requirement 6.6 as stated in PCI DSS 3.2 brings confusion at different levels:
Requirement 6.6 may be met by any of the above mentioned options, including pen test although I would recommend the following:
- On the type of responses: mix of manual and automatic assessment. Mix of preventive and defensive response.
- On the location in the standard: The WAF part should be part of Requirement 1, The manual or automatic assessment should be party of req 11. Code review is well place under req 6.
- On the time of execution: Code review is definitely executed prior release to production, while automatic or manual assessment may be performed on production (certainly for annual testing).
- On the periodicity: WAF is ongoing, Automatic assessment is at least annual or upon change, code review is upon change.
- On the absence of test procedure for validating that all 6.5 are covered by the assessment
Requirement 6.6 may be met by any of the above mentioned options, including pen test although I would recommend the following:
- WAF (production)
- Secure code review after significant code change as part of the SDLC.
- Pen test after significant code change before release to production annually on production,
RSS Feed
