Source code scanning - PCI Requirement - Service Provider

Question

I've been doing a lot of research regarding the requirements for source code scanning but haven't found anything conclusive when it comes to my question below. So I need some guidance from PCI Experts here in StackExchange's Info Sec community.

Is a service provider using an in-house custom built payment application (not PA DSS) required to use a tool like HP Fortify SCA to scan it's source code? Or can they comply by simply doing manual code reviews for any and all codebases they have? If they can get away by doing manual code reviews, how does OWASP Top 10 comes in to play?

Keep in mind, they do not have WAF in place.

Ref: https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf

Answer 1

Scanning versus Manual Code Reviews

Custom built, in-house software is in-scope for PCI compliance if it deals with PAN data. The PCI DSS, Requirement 6.6 expresses two options for in-house developers of software that handles PAN data: You can either do code reviews, or implement a web application firewall (WAF). Of course, it specifies the nature of the options for code reviews or WAF and the minimum standards for compliance when using either option.

So, one can elect to utilize either the code review route, or do the web application firewall route in order to achieve compliance.

Code Reviews

The PCI DSS states that four options are available for compliant code reviews:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

Therefore, a 'manual' review process (that you describe) is sufficient so long as that it covers the requirements mentioned further in the PCI DSS Section 6.6., notably that it is done by someone qualified and incorporated into the SDLC.

Of course, one may elect to use an automated tool as well; so long as that tool also works to satisfy the requirements. Many organizations will choose to use a mixture of both automated and manual reviews, which will provide more real-world security than simply being good enough for compliance.

OWASP Top 10

The mention of OWASP Top 10 is geared towards the second option, Application Level Firewalls. The PCI DSS states that as one of the requirements for a web application firewall to be considered compliant, it must:

React appropriately (defined by active policy or rules) to threats against relevant vulnerabilities as identified, at a minimum, in the OWASP Top Ten and/or PCI DSS Requirement 6.5.

If you are doing the "Option 1" code review route, then you need not concern yourself with the WAF material to maintain compliance.

However, many organizations will choose to use both "Option 1" code reviews and implement a web application firewall, which will increase the organization's security considerably -- so the options are not mutually exclusive. It's just that selection of one option is good enough, for now, to achieve compliance.

Compliant Doesn't Always Mean Secure

It is up to you to determine whether or not "compliant" is enough to be "secure" and what the risks of a breach are in your software, and as such, how much resources should be invested into securing it properly.

Answer 2

It is a PCI DSS requirement to have a secure software development lifecycle. Requirement 6.3.2 states:

6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following:

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.
• Code reviews ensure code is developed according to secure coding guidelines
• Appropriate corrections are implemented prior to release.
• Code-review results are reviewed and approved by management prior to release.

Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6.

and 6.6 states either WAF (which they don't have) or:

Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

One of the options within 6.6 is

Requirement 6.6 Option 1 – Application Code Reviews

...

1. Manual review of application source code

So to meet both requirements they can carry out manual code reviews.

How does the OWASP Top 10 come into play?

Back to 6.3.2, em me:

Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.

6.5 follows up on this (em me):

6.5 Address common coding vulnerabilities in software-development processes as follows:

• Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.

  • Develop applications based on secure coding guidelines.

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

Therefore they must carry out their code reviews with industry guidelines such as OWASP in mind. Their PCI policies should state which set of guidelines are followed during development and code reviews.

_{Standard disclaimer: I am not a QSA, nor more importantly, your QSA}