CRV2 CodeRevCompliance

Code review and compliance Many organizations with responsibilities such as safeguarding the integrity, confidentiality and availability of their software and data need to meet compliance.Compliance is most of the time a mandatory subject instead of a free-will decision taken by the organization. It comes in many forms and flavors such as PCI (Payment Card Industry), Central Bank regulations and HIPPA among others.

Compliance is an integral part of software security development life-cycle and Code review is an important piece in this constellation. Many compliance rules involves an execution of Code reviews in order to comply with certain regulations.

To execute proper code reviews that meet compliance rules it is imperative to use an approved methodology. This guide, for example, is mentioned in many compliance requirements such as PCI, specifically on Requirement 6: "Develop and maintain secure systems". PCI 3.0 which is available since November 2013, exposes a series of requirements which apply to development of software and identifying vulnerabilities in code. An important requirement which relates to Code review is 6.3.2 "Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability." The Payment Card Industry Data Security Standard (referred to as PCI from now on) became a mandatory compliance step for companies processing credit card payments in June 2005.

Performing code reviews on custom code has been a requirement since the first version of the standard. This section will discuss what needs to be done with regards to code reviews to be compliant with the relevant PCI requirements.

Code Review Requirements
The PCI standard contains several points relating to secure application development, but we will focus solely on the points which mandate code reviews here. All of the points relating to code reviews can be found in requirement 6: Develop and maintain secure systems and applications. Specifically requirement 6.3.7 mandates a code review of custom code:

6.3.7 - Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.

This requirement could be interpreted to mean that the code review must consider other PCI requirements, namely:

6.3.5 - Removal of custom application accounts, usernames, and passwords before applications become active or are released to customers

6.5 - Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:

6.5.1 Unvalidated input 6.5.2 Broken access control (for example, malicious use of user IDs) 6.5.3 Broken authentication and session management (use of account credentials and session cookies) 6.5.4 Cross-site scripting (XSS) attacks 6.5.5 Buffer overflows 6.5.6 Injection flaws (for example, structured query language (SQL) injection) 6.5.7 Improper error handling 6.5.8 Insecure storage 6.5.9 Denial of service 6.5.10 Insecure configuration management OWASP guidelines are mentioned in the PCI requirements as one of the advised methodologies to be followed."Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements". (PCI-DSS, pg 55)

The current version of the standard (version 3.0 at the time of writing) contains requirement 6.6. This requirement gave companies two options:

1) Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security

2) Installing an application layer firewall in front of web-facing applications

The PCI Council expanded option one to include internal resources performing code reviews. This added weight to an internal code review and should provide an additional reason to ensure this process is performed correctly.

This Code Review guideline offers an approved methodology for these requirements.As mentioned in the Official Guide to the CISSP CBK "“Several organizations have developed frameworks for secure web development. One of the most common is the Open Web Application Security Project (OWASP)14 OWASP has several guides available for web application development including: ” (Excerpt From: Hernandez. “Official (ISC)2  Guide to the CISSP CBK.” iBooks. https://itun.es/us/mFXoL.l)
 * Development Guide
 * Code Review Guide
 * Testing Guide
 * Top Ten web application security vulnerabilities

This guide is definitely part of any security practitioner library and it supports an approved methodology to review code.