Before you decide whether a source code review or Web application firewalls best meet your PCI DSS compliance needs, I recommend taking time to fully understand PCI's Web application requirements, including the clarification documents, and consider how the approved options mesh with your architecture and resources. It is now clear that enterprises have multiple paths to compliance and, if executed properly, any of the options will not only help achieve compliance, but also improve Web application security.
Of course, there is no one-size-fits-all approach to application security. Unless you are in the fortunate position to be able to both conduct code reviews and run a WAF, it looks like the choice may simply come down to people. Does the enterprise have staff that can:
Another approach is to use threat modeling to identify and evaluate the risks to an application. Take the top three critical risks and decide how best to remediate them: code review, vulnerability assessment or WAF. Be aware, though, that implementing a WAF will not eliminate the need for you to have a secure software development process in place (Requirement 6.3)! Application vulnerability assessments and code reviews both strengthen the development and quality assurance cycle.
Many of these choices are likely to be too costly for the small e-commerce site, so my recommendation here would be to outsource the payments to a third-party payment provider, which affectively outsources all of the expensive security requirements, including Web security, as well as the actual PCI DSS compliance. As long as you don't handle any of the card payments anywhere else, you don't need to be PCI DSS compliant.
Compliance vs. security
No matter what choices you make, many would debate whether PCI compliance equates to acceptable levels of security. Those responsible for security need to understand the limitations and capabilities of each option. Source code analysis alone may deliver compliance, but it's not the answer to application security. No one thing is. PCI DSS focuses on payment card applications and components related to PCI. It doesn't look at an organization and its entire networked operations in a holistic manner, requiring security to be implemented across the board.
The PCI DSS, however, does give organizations the foundation for creating a secure architecture and business model they can operate on. It has also put security on the board room agenda. If you're concerned with security, getting PCI compliance will be a byproduct. Until your developers program securely, a layered security solution will always be the best approach for mitigating risks, in this case, one that includes code review, vulnerability assessment and a WAF. The WAF will be more effective once results from a vulnerability scan have been integrated into its configuration. This will provide protection while the source code is analyzed and corrected to eliminate the vulnerabilities.
Will vulnerabilities still come to light even after a PCI review? Sure, but not as many and hopefully not as serious. Costs and business drivers may result in lower levels of assessment and protection, but those are the real world business decisions that have to be taken.
For more information:
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.
This was first published in April 2009