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.
Responding to 6.6
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.
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.
The use of automatic tools
The use of pen test for 6.6
- 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,