PCI newsletter #52 - Complying with 6.6 - Ensure public-facing web applications are protected against known attacks

4/7/2017

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:

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.

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:

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

So manual review of application source is perfectly acceptable to meet 6.6. Of course you will need to proof that:

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.

I drawn up a checklist specifically crafted for secure coding review against PCI 6.5.X vulnerabilities.

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:

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,

Resources

3 Comments

Patrick

4/20/2017 06:59:39 am

>Thanks for the article. In it you says that: "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). "

Why only prior to release to production? How would the fact that the application is in production affect the validity of the pentest to address this requirement?

Certainly a pentest combines :
1-Manual web application security vulnerability assessment
2-Proper use of automated web application security vulnerability assessment (scanning) tools

Didier link

5/6/2017 04:50:05 am

Patrick, Your remark is pertinent. A pen test could indeed be executed on Prod. However, in the mind of PCI this is already required by req 11.3. I'v seen auditor rejecting a pen test in prod as evidence of compliance with 6.6 just because of that.

5/8/2017 01:20:42 pm

Salut Didier,

QSA's blindly applying the notion of "one control cannot be used to address two requirements" is ridiculous.

Anyone who reads this and is still undecided about how to see this, consider the alternative:

1- Testing in a preprod, staging or test environment does not garanty that what is pentested is in fact what is exposed to hackers when put in production.
2- If by chance prod and preprod were exactly the same. What would an application level pentest to address 11.3 on production and an another application level pentest to adress 6.6 on pre-production provide in terms of added value? Nothing. The results would be the same.

Keep up the great posts!