PCI DSS and Code Reviews
Contributed By:
PCI Guru
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.
Contributed By:
PCI Guru
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.
No comments:
Post a Comment