Because an application firewall is not an option for every application or every organization, the PCI DSS allows for code reviews conducted either manually or using automated tools. Where I see most trouble with this is that people treat their applications like their networks and use their application vulnerability assessment tool after the application is put into production. But that is not what the PCI SSC stated in their April 15, 2008 Information Supplement.
“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. Change control processes must ensure that software developers are not able to bypass the code review/application assessment step and deploy new software directly into the production environment. Change control processes must also enforce the correction and retesting of vulnerabilities before implementation.”
The reason the PCI DSS wants code reviews or application vulnerability testing done before an application is put into production is that, unlike the network, application changes can take significant time to implement. If you do your code reviews or vulnerability testing after the fact, it could be quite a while before a fix is implemented to close a security hole.
So, to ensure that code reviews and vulnerability testing gets done at the appropriate time, these activities need to be an integrated part of your organization’s system development lifecycle (SDLC). Most organizations conduct code reviews or application vulnerability testing as part of the quality assurance (QA) process before the application goes into production. If any issues are discovered during the QA process, they can be sent back to the developers for remediation before the application goes into production.
Some application vulnerability tools provide integration with developer platforms such as Microsoft’s Visual Studio. And, while these tools will notify the developer of potential security issues, it’s just good practice to fully assess the completed application during the QA process to be safe.
And speaking of application vulnerability assessment tools, remember, they are typically only useful against browser-based applications. These tools typically have nothing to do with middleware or applications that do not interact through a browser. This is where vulnerability tools that integrate with the developer’s platform can have a role as well as the use of code reviews. And don’t forget the use of network vulnerability scanners and penetration testing tools for testing non-browser-based applications. Even these non-browser-based applications still communicate over the network, so the use of vulnerability scanners and penetration testing tools can assist in identifying any security issues with these applications.
Hopefully this three part series has described the importance of requirement 6.6 and what you need to do to comply.
PCI Guru 