COMPLIANCE AND GOVERNANCE DIGEST
The PCI compliance case for source code review
Michael Cobb, Contributor
04.29.2009
Rating: -4.00- (out of 5)
|
If you already have the in-house expertise, a Web application firewall (WAF) may seem like a straightforward choice to meet your PCI compliance obligations. But there's never 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.
The are four types of code review which the Payment Card Industry Data Security Standard (PCI DSS), a common compliance challenge for organizations that deal with credit card data, deems acceptable:
Manual review of application source code
Automated source code analyzer tools
Manual Web application security vulnerability assessments
Automated Web application security vulnerability assessment tools
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 ...
To continue reading for free, register below or login
To read more you must become a member of SearchFinancialSecurity.com
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, making them a more affordable option.
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 Open Web Application Security Project.
When you start looking at this market sector, you will find that some automated tools you buy actually blend into service offerings which can make for simplicity and cost savings. Outsourcing your testing to specialists such as Veracode or WhiteHat Security can make sense from several perspectives. You off-load the burden of installing and learning an application and you get the benefit of input from people who live and breathe testing.
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.
For more information:
PCI management: The case for Web application firewalls
The PCI compliance case for source code review
How to choose between source code reviews or Web application firewalls
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.
|
|
|
|
|
|
