Web application vulnerabilities put critical business applications and back-end databases at risk from attack, theft and fraud. The Payment Card Industry Data Security Standard (PCI DSS, or PCI), which recognizes the threat Web application vulnerabilities pose to credit card data, allows organizations to choose between two mitigation techniques.
Requirement 6.6 of PCI DSS specifies the means for protecting Web-facing applications, either by “Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security” or by “installing an application layer firewall in front of Web-facing applications.”
This short-worded requirement has raised one of the largest PCI debates: Which method should be put in place — a code review or a Web application firewall (WAF)?
Ideal Is Seldom Realistic
When asked to choose between code review or application firewall, real security experts take a Zen approach. Rather than making a choice between these two artificially opposed options, they answer simply “both.” This is because a layered approach, employing multiple techniques and including both source code review and application firewall, is the most effective approach.
In the real world, however, security professionals rarely are able to take an ideal approach. Technology deployment and consulting work both cost money, and most organizations try to minimize both. This is ultimately the reason PCI offers the choice. Most organizations eventually implement both code review and application firewalls. The real choice they have to make isn’t “which?” but rather “which first?”
Answering this question requires an understanding of how each approach helps to improve security.
Obstacles for Code Review
The code review approach to application security involves inspection of the code by an expert in security to identify and presumably correct programming flaws that result in security issues. Proponents of code review will claim that since the vulnerabilities are due to errors in programming, the only way to address them is to understand and fix the application code itself. Code review does in fact provide a strong theoretical capability to remove vulnerabilities from an application. However, the reality of applications and deployments significantly reduce the actual effectiveness of code review. The real-world impediments to code review include the following:
- For many applications, the source code is not readily available or understood. This could be either because the application is a third-party application or because the original developers of a legacy application are no longer available to explain what they did.
- Applications, and especially Web applications, change frequently, so the target of code review is a moving target, and new vulnerabilities can be introduced at any time. In many cases the application can change before a full review cycle has been completed.
- Attacks, (again, especially Web attacks), also change frequently. Prior to three years ago, no code review would have found response splitting problematic. Then a paper describing response splitting attack techniques required developers to send the same code back to review.
- Finally, any code review is only as good as the reviewer. Skill sets for code review vary widely … and can be very expensive.
Obstacles for WAFs
Web application firewalls (WAFs) take a different approach. WAFs inspect inbound and outbound traffic to an application and enforce a security policy meant to prevent attackers from compromising the site. Security techniques implemented by WAFs vary, but most WAFs will include positive security (allow only that which is known to be good usage) and negative security (block usage that is known to be malicious).
Advanced WAFs combine these two types of security rules as well as correlate multiple user behaviors to increase accuracy. Proponents of WAFs (and I am one of them) will argue that WAFs provide the most effective mechanism to immediately address security issues, as the security rule set can be adjusted to prevent new attack types without the time required to change application code. The common objections to WAF technology are:
- Some issues can only be corrected in code. The most commonly cited example is logical flaws in the application, meaning that if the application was intentionally built to do something insecure, only rewriting the application can fix this issue. This is true to some extent, but a good WAF will provide ongoing monitoring information that helps to identify when logical flaws are being exploited.
- WAFs can’t understand enough about the application to be effective and accurate. The answer to this is that some WAFs indeed can’t. As with any technology product, it’s important to pick a good one.
What to Do?
Given these differences, how is someone faced with PCI’s dilemma, false or not, to choose?
For those only concerned with compliance, the answer is simple: WAF. Because a WAF can be deployed without affecting the application and without engaging outside consultants to review application code, WAF is a faster and more cost-effective approach to meeting the letter of the law.
For those concerned with actually doing the right thing and asking “which first?” rather than “which?” the answer is actually the same: WAF. That’s because a WAF can be deployed to provide immediate protection, and a WAF can be quickly configured to adjust as applications and application attacks change. WAFs not only provide the most cost-effective first step, but a sound building block for the second step. Once a WAF is in place, code review projects can proceed at a controlled pace, reducing the risk of errors. WAFs also provide critical information on usage patterns and changes in usage patterns that can guide code review teams and point out obvious problems.
An instructive analogy can be found in application performance tuning. Re-coding slow parts of an application is a great way to improve system performance. However, finding those slow parts requires a performance measurement tool and sometimes a little extra help — in the form of content acceleration techniques like caching and compression — is warranted. WAFs serve a similar function for application vulnerability assessment by providing a roadmap that code reviewers can follow to find and fix underlying logical issues.
Regardless of how one feels about PCI compliance, the significant and growing threat of application attacks means that application security should be a high priority for any organization with Web applications. Likewise, regardless of the false choice created by PCI between performing a code review and deploying an application firewall, a sound approach to application security includes both.
Amichai Shulman is CTO of application data security vendor Imperva and director of the Imperva Application Defense Center, an application and database security research organization.
Loading ...
See also http://blog.imperva.com/2008/05/reviewing-the-code-review.html