If you already have the in-house expertise, a Web application firewall (WAF) may seem like a straightforward choice to meet your compliance obligations. But there's never ever a silver bullet when it comes to IT security. WAFs, for example won't protect against application logic flaws, which can easily occur given the complexities of today's Web 2.0 applications that run a lot of dynamic code.
This is where the benefits of a code review kick in. By solving the problem at the code level, you reduce the number of security-related design and coding defects and the severity of any defects that make it through to the release version, thus improving the overall security of the application dramatically.
There are four types of code review which the PCI DSS deems acceptable:
A source code review is probably the most thorough single option. Nothing is hidden from the analyst, who can examine exactly how data flows through the program. Specific attributes of the application domain, such as credit card numbers and personal data, can be taken into account, allowing the full range of security vulnerabilities to be identified.
The main drawback is that it's a lengthy and expensive way to find security flaws in all but the most basic Web applications. It requires skilled and experienced engineers with both extensive application development experience and security expertise. You are probably looking at tens of thousands of dollars in cost, although the exact figure will obviously depend upon application complexity. Bear in mind though that a code review doesn't require the same level of ongoing care and maintenance as a firewall (although future code revisions will need reviewing, and your developers will of course need the skills to correct any discovered vulnerabilities.).
PCI requires that internal code reviews are acceptable if the reviewers are trained and specialize in application-code assessments and are not the same people who developed the application.
However, having dedicated code reviewers is only going to be economical for large enterprises that are constantly developing their own applications.
PCI also approves the "proper use of automated application source code analyzer (scanning) tools" and the "proper use of automated Web application security vulnerability assessment (scanning) tools." Although static analysis tools can't test adherence to security policy or identify backdoors in an application in the way a manual code review can, they can shorten the time to review large, complex applications.
Top of the range products use sophisticated functions such as data flow analysis, control flow analysis, and pattern recognition to identify potential security vulnerabilities. I say potential, as the results tend to include a high number of false positives. The advantage is that they can analyze highly complex reams of code and identify issues the analyst needs to concentrate on. This can make them quite cost-effective.
Code review is cost-effective
Leaving aside whether calling a vulnerability assessment a code review is correct, it can provide a more cost-effective way of meeting compliance requirements. Many would argue that it's a more practical approach than a code review, as applications are becoming so complex. Vulnerability assessments will reveal vulnerabilities and holes. They can be executed from both the perspective of an untrusted outsider and a trusted user. Again, issues such as sensitive data not being encrypted are likely to go undetected, since the application user interface is the sole attack vector. Also, the application needs to be set up in a production-like test environment, which is not always possible and can be expensive.
A middle-ground between roll-your-own hacking code and a commercial package might be to use open source Web security testing tools. Many of these can be found through the
When you start looking at this market sector you will find that some automated tools you buy to run yourself blend into service offerings which can make for simplicity and cost savings. Outsourcing your testing to specialists such as
What you need to bear in mind when using either an outsourced tester or an internally managed test is that both are limited in ways that attackers are not. Your supplier, for example, might not appreciate you hacking into his network just to see if you can use it to break into your network. But an attacker won't think twice.