Posts Tagged ‘code review

06
Jun
10

Code Review

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.

Advertisements



Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

October 2017
M T W T F S S
« Sep    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,884 other followers