PCI DSS and Code Reviews

Monday, August 02, 2010

PCI Guru

Fc152e73692bc3c934d248f639d9e963

Requirement 6.6 of the PCI DSS discusses the concept of code reviews or the implementation of an application firewall to protect Internet facing applications. 

For code reviews, requirement 6.6 states:

“Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes”

The confusion regarding code reviews is exacerbated by the fact that most organizations have only read the PCI DSS and not the information supplements that further clarify the PCI DSS requirements. 

In April 2008, the PCI SSC issued “Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified.”  Pages 2 and 3 go into detail regarding what the PCI SSC deems as appropriate for conducting code reviews.

The first thing that organizations get wrong about meeting 6.6 is conducting their application vulnerability assessment after the application is in production. 

Typically, this is done to save time and money as most organizations are already conducting vulnerability scans and penetration testing to meet requirements 11.2 and 11.3.  The supplement is very clear that this is not acceptable when it states:

“The reviews or assessments should be incorporated into the SDLC and performed prior to the application’s being deployed into the production environment. The SDLC must incorporate information security throughout, per Requirement 6.3.”

The supplement continues to state:

“… it is recommended that reviews and scans also be performed as early as possible in the development process.”

Further clarifications provided during QSA re-certification training indicates that the PCI SSC really believes that the reviews or assessments MUST be incorporated into the SDLC, not that they should be incorporated. 

As a result, the PCI SSC is instructing QSAs to ensure that application vulnerability assessments are done before the application is placed into production and that any critical, high or severe vulnerabilities are addressed prior to the application entering production. 

The idea being that applications should go into production

Code reviews can be done manually or using automated tools.  However, if an organization is using one or more automated tools, the code review is not all about the tool. 

There must be processes in place that address the vulnerabilities identified and those vulnerabilities that are critical, high or severe must be addressed prior to the application being placed into production.  Most organizations conduct this sort of testing as part of their quality assurance process.

Tools such as IBM/Rational AppScan have the ability to integrate into the developer’s workbench and conduct vulnerability testing while the code is developed.  However, while that ensures that specific code modules are secure, it does not ensure that all of the modules that make up the application are secure as a whole. 

So a vulnerability scan of the completed application should be performed to ensure that the application as a whole is secure.

The next misunderstanding is related to having an “independent organization” conduct the code review.  This has been interpreted as code reviews must be conducted by third party application assessors.  The PCI SSC did not help this interpretation by their statement in the supplement when they stated:

“While the final sign-off/approval of the review/scan results must be done by an independent organization …”

However, the PCI SSC has indicated in QSA training that independent is defined as anyone not associated with the development of the code being reviewed. 

A lot of organizations have a quality assurance group separate from their developers and so the quality assurance group is responsible for conducting the code reviews. 

In organizations with very small IT organizations, as long as you have a developer that was not involved in developing the code being reviewed, they can be the independent party that conducts the code review.

Finally, code reviews are only required on code developed by the organization, not PABP or PA-DSS certified purchased software.  However, if the purchased software is not PABP or PA-DSS certified, then the software must be assessed under PCI DSS requirements 6.3 through 6.6. 

If the software vendor will not cooperate with such an assessment or provide a copy of their own PCI DSS assessment under requirements 6.3 through 6.6, those requirements must be judged as not in place on the organization’s PCI assessment.

Cross-posted from PCI Guru

Possibly Related Articles:
5600
PCI DSS
PCI DSS Code Review
Post Rating I Like this!
A6f6ba95b73de19f947cf4eceecb2bed
Ryan Dewhurst Further clarification on the capabilities of automated black box scanners is needed.

Does just scanning for SQL injection and XSS make me pass PCI? or what about just scanning for the OWASP Top 10 vulnerabilities?

Even if the black box scanner is comprehensive in the types of vulnerabilities it tries to identify, who is monitoring the quality of checks it does?

I think PCI DSS really need to clarify this point. Also on manual black box assessments, if I get my buddy who knows HTML to asses the application, does this mean I have passed the PCI requirements?
1280850079
Fc152e73692bc3c934d248f639d9e963
PCI Guru Unfortunately, people get confused between requirements 6.5 and 6.6. Requirement 6.5 is the one that goes through essentially the OWASP Top 10 circa 2008. However, requirement 6.6 states that automated scanning can be performed to satisfy the requirement. But no restriction on just scanning for the OWASP Top 10 is stated. It expects you to scan for any and all vulnerabilities. What does need clarification is that the PCI SSC in their QSA training tells us that application vulnerability scanning needs to be performed BEFORE the application goes into production and that any critical, high or severe vulnerabilities must be corrected or mitigated BEFORE the application is placed in production.
1283090008
A6f6ba95b73de19f947cf4eceecb2bed
Ryan Dewhurst It may expect you to scan for any and all vulnerabilities but it does not state this, as far as I could tell.

My point is, there is no quality control on the black box scanners themselves. Every scanner varies in the types of vulnerabilities they look for and how they accomplish the detection of such vulnerabilities.

One scanners results may vastly differ from the other, missing critical vulnerabilities.

I could write a script that only detected XSS vulnerabilities, does this make it a valid PCI black box web app scanner?

I may be mistaken here, but from what I've read there is nothing that states the minimum a black box web app scanner should detect. There may be suggestions but nothing concrete.

Even if a scanner ONLY detected the OWASP Top 10 this is far from a comprehensive list of checks and just because your web application is not vulnerable to the OWASP Top 10 vulnerabilities does not necessarily mean that its secure.

1283090711
Fc152e73692bc3c934d248f639d9e963
PCI Guru First, you are correct. Scanning for just the OWASP Top 10 does not cut it and I do not accept that for requirement 6.6. That said, the PCI SSC has indicated that the PCI DSS is only a starting point and that companies should go beyond the DSS. This is just one of those areas where an organization needs to go beyond and scan for more than just the OWASP Top 10.
1283095871
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.