Contact us
PCI-GO
  • Dashboards
  • PCI eBook
  • Library
  • Blog

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

4/7/2017

3 Comments

 
Picture
​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.
Picture
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. 
Picture
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:
  1. Manual review of application source code
  2. Proper use of automated application source code analyzer (scanning) tools
  3. Manual web application security vulnerability assessment
  4. 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: 
  1. WAF (production)
  2. Secure code review after significant code change as part of the SDLC. 
  3. Pen test after significant code change before release to production annually on production,

Resources

Picture
  • EBook: PCI DSS 3.2 - That’s the Way It Is.
  • PCI DSS V3.2 Compliance Dashboard
  • PCI Calendar App - Never miss a milestone again
  • Ready to use PCI Procedures & Templates
  • ​Secure coding checklist for Code Reviewers
3 Comments

    Archives

    March 2023
    February 2023
    April 2020
    July 2019
    February 2019
    January 2019
    August 2018
    May 2018
    February 2018
    January 2018
    December 2017
    October 2017
    July 2017
    June 2017
    April 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    February 2016
    January 2016
    October 2015
    August 2015
    January 2015
    July 2014

    RSS Feed

Provided by DGOZONE SPRL.
Proudly powered by Weebly