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.
PCI Guru 
In a flat network with PCI and non-PCI applications, do we need to conduct code review for non-PCI applications also?
I would say vulnerability scanning, patching and remediation would cover those applications.
That said, best practice would to always do code reviews regardless of PCI.
My application code is Java and one more is VB.net. I scanned with automated tools found from OWASP recommended open-source application and found many weak of code such as poor user input validation etc.
Could you please guide me to generate any report template for its vulnerability which comply with PCI?
Best Regards,
I would love to help you, but report templates vary by tools used and the like. That said, you want a report that clearly identifies the vulnerabilities and the risk they represent so that they can be remediated or mitigated.
Does code review is applicable to a static html page with CSS?
Code is code whether it is PHP, CGI, .NET, ASP, HyperText, etc., regardless of whether the pages are static or active. So yes, code review is required regardless.
We are using scripts and C compiled code for back office work. This is NOT an application, DOES NOT receive any input from user and only executed by internal user or executed by cron jobs.
Do we need to carry out code review? If required, what is the basis? OWASP Top10 or SANS Top25. Kindly advise
I am assuming because of your question that this application processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD) even though you did not state that explicitly.
That being the case, yes, you must conduct code reviews any time the code for that application changes. Forget about the OWASP/SANS lists as it appears that this application is not browser-based and that is what those lists focus on. For this instance, the code review needs to look at the code from a standpoint of risk that the SAD/CHD could be compromised and how/if that could occur. If the code can be fixed to reduce/remove the risk, then that needs to be done BEFORE the application is placed in production. If the code cannot be fixed, then you will need to come up with and implement other controls such as additional monitoring, restrictive firewall rules, etc. that will mitigate the risks in the application BEFORE you put the application into production.
The script is used to store, process and transmit credit card information. For the pure shell scripts, what kind of code review is applicable?
Document the review of the scripts, any security/vulnerability issues that might were discovered, what changes will be made to address those issues or what will be done to mitigate those issues. IF changes are made to address issues, make sure that those changes are documented and the results of testing that prove the changes address the earlier issues are also documented.
Our company carried out code review last year. Through there is no changes in the application and no new vulnerabilities released by OWASP top 10, the consultant is asking us to do code review again.
Consultant is not ready to accept the pass report of Nessus web application vulnerability tests.
I don’t understand the objective of repeating code review again. Can anyone kindly explain?
I’m with you.
Code reviews only need to be performed when changes occur that affect the card processing logic of an application. No changes, no need to review.
This is why a lot of developers are isolating their card processing logic in separate modules so that they are away from the rest of the application that might change on a more frequent basis.
That said, you do need to be able to provide the change management records to prove there are no changes that affect the card processing logic, but that should be the end of it.
“The reviews or assessments should be incorporated into the SDLC……” Agree with this point.
How to carry out this annually?
Already, per 6.3, security need to be incorporated throughput SDLC. Then what is new with 6.6?
Hmmm … You seem to be missing the point of code reviews integrated into the SDLC if you are thinking of doing this only annually.
The PCI SSC through the DSS wants companies developing code to review the code BEFORE it is placed into production. That way if the code review identifies any vulnerabilities or issues, they can be corrected or mitigated before the code is placed into production. This is NOT an annual event, but done as part of the development process whenever changes are made. If adhered to, then a company can comply with the requirements in 6.3 as well as 6.6.
As an aside, a good source of how to develop PCI in-scope applications is to follow the requirements specified in the PA-DSS. Even if the application will not be officially certified, following the PA-DSS is a good way to ensure that it is being developed properly and securely.
We do code scans using Crucible and Sonar. Are you aware of a plugin in these tools or any tool that does PCI-DSS compliant checks. Such tools would dramatically increase the productivity of PCI compliant development. It will be very useful when we have a legacy product that has to be made PCI- DSS conformant.
There are a variety of commercial and open-source tools that have PCI compliance testing suites. IBM AppScan has a PCI compliance set of rules. The OWASP has a number of open-source tools that have PCI compliance implications. Tenable Nessus can perform some application related PCI testing as long as you provide Nessus with administrative rights to the platform being assessed. However, for Crucible and Sonar, I am not sure what is available. A lot of time when you go to a tool vendor’s official forum pages, users of the tools have created their own PCI compliance testing suites and are sharing them.
I’ve posted this here as well as on infosec island where I originally saw the post.
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?
Good points. The PCI SSC has addressed the issues somewhat, although probably only through their training of the QSAs.
As I think I eluded to in my post, code reviews must be more than just running a tool against code and addressing vulnerabilities. There needs to be a process that is part of the system development life cycle (SDLC) that deals with security, secure coding and the like to minimize the number of vulnerabilities in the final piece of software. I say minimize because, in some cases, vulnerabilities must exist in order for the software to function.
In regards to scanning for just the OWASP Top 10. That is just the bare minimum that you can get away with. The PCI DSS is only a baseline. While you can pass by scanning only for the OWASP Top 10, any good security person knows that the bare minimum is not going to cut it and that full vulnerability scans need to be done and the results need to be addressed.
“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.”
Do u have a clarification of this from payments brands or PCI SSC?
Just to clarify. Any ‘clarification’ is from the PCI SSC which is a “front” for all of the card brands. Clarifications are developed and reviewed by all of the card brands. The PCI SSC then works with the card brands to develop common clarification language and publish the clarifications.
Originally PABP or PA-DSS certification of payment applications was only suggested, not required of purchased applications. However, if a purchased application is not PABP or PA-DSS certified, then it must be assessed as though it was custom developed. That means assessing all of the requirements in 6.3 through 6.6 at the application developer’s location just like you would assess an internally developed application.
6.6 requires a LOT more than just a vulnerability scan as you perhaps imply – it’s about conducting a web application security vulnerability assessment. The PCI SSC’s use of the word vulnerability is a little unwise, but as you say, their follow up interpretation is good and helps set the record straight.
6.6 doesn’t cover code reviews – this is a 6.3.7 function. 😉
Agreed. However, this is not a “how to do it all” type of blog. This is more of a get people headed in the right direction.