Comply with Section 6.6 of PCI DSS with code reviews and get more

By Paladion

March 25, 2008

The PCI section 6.6 is fairly clear in what it wants from merchants.

Ensure that Web-facing applications are protected against known attacks by applying either of the following methods:

  • Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
  • Installing an application layer firewall in front of Web-facing applications

The investments involved in placing application layer firewalls or doing a code reviews are not insignificant and it is essential to get value beyond the compliance tick. Coming from the code reviews corner, let me share what code reviews involve and how to get the most of your investment while complying with section 6.6 of PCI DSS.

Separating the meat balls and the gravy in your code

If we compare a typical application to meat ball gravy, we first need to figure which code is meat ball and which code is gravy. Consider a small app with 15 to 30 thousand lines of code. At 50-100 lines per class, this application has roughly 300 classes. Using scripts that scan the code for certain signatures (authentication, encryption, input validation, authorization, credit card data and more), we can identify the right 50 or so classes which are the meat balls in this code. The rest of the code is the gravy. The meat balls are the parts of the code that are most likely to have security vulnerabilities or intentional back doors. These classes should be reviewed most intensely - scanning with proprietary tools, commercial tools and most importantly manual reviews. The balance of the ‘gravy’ classes should be scanned by both proprietary and commercial tools to complete a baseline review. Experienced application security teams can review apps with <150,000 lines in 1-2 weeks.

Larger apps (with million plus lines of code) use more technologies, and usually interface with other applications. Code reviews of such apps can be completed in 2-4 weeks usually.

Getting more bang from your code review bucks

  1. Do rapid risk assessments to determine which ‘money’ application should be code reviewed (Choose the right apps)
  2. Use tools / processes that easily finds the meat balls (vulnerable code classes) in your thousands or millions of lines of code (Choose the right code)
  3. Analyze vulnerabilities across applications, vendors to identify recurring issues, across the board solutions and effective developer training modules (Address root causes)
  4. Look at trends like software-as-a-service, outsourcing & offshore centers to reduce your code review costs (Find a good deal).

Update: Roshen writes about how we do PCI Code Reviews - this is a more technical piece.

Tags: code review, Uncategorized, compliance, pci