Code Review or Web Application Firewall

[utknuclear]

This is also a requirement that we know very little about. Can anybody tell me how to suffice for this PCI Requirement? We have a custom built SaaS application? thanks,

[derra]

https://www.pcisecuritystandards.org/security_standards/docs/information_supplement_6.6.pdf

[jbhall56]

Also check out http://pciguru.wordpress.com

There's a three part series of entries on requirement 6.6.

[jonassono]

Requirement 6.6 in Ver. 1.2 provided three choices for a custom web-facing application, namely: i.) a code review; ii.) a web application firewall that blocks unwanted traffic; and iii.) a web application vulnerability scan, either manual or automated.

However, their most recent publication "The Prioritized Approach to Pursue PCI DSS Compliance" which arrived this week on their web site, has removed the "code review" choice altogether.

Unless there is a compelling reason not to do so, the web application vulnerability scan is generally the quickest, simplest and lowest cost solution. Web application firewalls are expensive to acquire and more importantly, require highly skilled network specialists as they are technically complex to configure and maintain.

[derra]

Abit OT but I think the "The Prioritized Approach to Pursue PCI DSS Compliance" is kinda crappy.

I dont agree in the prioritization several cases and it could differ ALOT depending on what kind of merchant/gateway/acquirer/xxx it is and how they are working with cardholder data.

[jbhall56]

Requirement 6.6 in Ver. 1.2 provided three choices for a custom web-facing application, namely: i.) a code review; ii.) a web application firewall that blocks unwanted traffic; and iii.) a web application vulnerability scan, either manual or automated.

You better go back and re-read v1.2 of requirement 6.6. The PCI SSC changed the language from 'Web facing' to 'public facing'. Based on discussions with them, they further defined 'public facing' as any application that processes, stores or transmits cardholder data (CHD) that is used by external users your organization does not have complete control. That includes business partners so some internal applications will come into scope. Their rationale is that if your application is susceptible to a SQL injection or cross-site scripting attack on the Internet, it's also susceptible from the inside as well.

We are recommending to clients to just conduct application vulnerability and pen testing on all PCI in-scope applications, external or internal, just to ensure that they are as secure as they can be. With all of the attacks lately being conducted from the inside of networks and against applications, it's only a matter of time before the PCI SSC codifies this change in requirements into the PCI DSS.

[newdle]

This week's "Prioritized Approach" document from the SSC doesn't explicitly list "code review" (as jonassono mentioned) because the requirement 6.6 language is straight out of PCI DSS 1.2, and it's not there. If you check the PCI DSS 1.2, the requirement now describes two options. The second is a WAF. The first is: "Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes."

Related to that, the "Application Reviews and Web Application Firewalls Clarified" information supplement was updated (apparently in October 2008) and is listed as a supporting document on the PCI SSC site (as derra mentioned). Notably, this supplement cites NIST's "Web Application Vulnerability Scanners" which, as near as I can tell, means:

http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html

In turn, NIST cites OWASP's tool list:

http://www.owasp.org/index.php/Phoenix/Tools

I would posit that this is a slight correction to an earlier note about PCI DSS 1.2's requirement 6.6; it offers two choices rather than three. But, it seems like a reasonable interpretation to say that code review is a "manual web application vulnerability security assessment method" and that code review app's are "automated web application vulnerability security assessment tools". Simply put, code review is (now) included within the first option.

The NIST and OWASP tool lists give a lot of options for testing, even from open source. That should be good news to anyone trying to determine what meets the 6.6 requirement. But you should understand that a combination of tools might be the right fit for you. For example, I talked to someone recently about Pixy, a source code analysis tool (listed on the OWASP site). It's a smart choice for testing XSS and SQL injection in PHP code, but it doesn't test header injection, for example. So, if you use it, it probably shouldn't be the only tool you use.

Requirement 6.6 also gives the option for WAFs. I'll post on that separately.

[newdle]

You better go back and re-read v1.2 of requirement 6.6. The PCI SSC changed the language from 'Web facing' to 'public facing'.

The language of PCI DSS 1.2's requirement 6.6 is "public-facing web applications" as opposed to "web-facing applications" in 1.1. I believe that, in the case of the current 6.6, the scope of the requirement really is limited to web applications. Pen-testing and other testing requirements are addressed under requirement 11 but it appears that the intent of 6.6 is really to focus (only) on web applications which, for lack of a better authority, fit this definition:

http://en.wikipedia.org/wiki/Web_application

[newdle]

Requirement 6.6 also gives the option for WAFs. I'll post on that separately.

What's a web application firewall (WAF)? Merchants, service providers, and QSAs all want clarity yet the SSC doesn't want to limit or endorse. In the supplement for 6.6, here's how they start:

"A web application firewall (WAF) is a security policy enforcement point positioned between a web application and the client end point. This functionality can be implemented in software or hardware, running in an appliance device, or in a typical server running a common operating system. It may be a stand-alone device or integrated into other network components."

There's more in the supplement, so you should read the capabilities that they list to understand what a WAF might be. The SSC has its reasons for not listing what might or might not be a WAF, but they cite OWASP's site once again. Here's a relevant link:

http://www.owasp.org/index.php/Web_Application_Firewall

OWASP defines a WAF this way:

"A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation."

Why follow these links and definitions? Again, the SSC won't say what constitutes a WAF so it's up to QSAs, acquirers, merchants, and service providers to figure it out.

Suppose someone asks if ModSecurity is a WAF? Well, it's a "security policy enforcement point positioned between a web application and the client end point... implemented in software... [and] integrated into other... components." No product fits everything in the supplement's description (before of the or's), so you can't come down too hard on me about the ...'s! Or you could check OWASP, because it's cited in the supplement... sure enough, ModSecurity is a WAF! I have heard that ModSecurity doesn't fit the SSC's intent for a WAF. If it wasn't the intent of the DSS authors to allow an WAF built as an Apache module, why say a WAF could be implemented in software and integrated into other components, as ModSecurity is?

[jonassono]

Here is the explicit requirement copied from Navigating the PCI DSS Document Ver. 1.2 dated October, 2008

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

 Installing a web-application firewall in front of
public-facing web applications.

My argument remains - "an automated web application vulnerability scan is far simpler, less costly and complex than acquiring and installing a Web Application Firewall'. Insofar as a "code review" is concerned, this would be the absolute last choice. Web apps are typically built with C# .NET, VB .NET or Java. The last public-facing web application I had to review had about 70,000 lines of java code and SQL calls housed inside JBOSS. Finding an expert who knew this web development environments, had the security expertise to know what precisely to look for, where to look exactly and how to test the vulnerability and remedy the code.

IMHO code reviews for PCI DSS compliance are like taking your car engine apart to check the oil.

[jbhall56]

IMHO, a Web Application Firewall (WAF) is any firewall that operates in ISO layers 4 through 7 and conducts stateful inspection at those layers. Network firewalls like Cisco ASA, Checkpoint and the like operate on ISO layers 2 through 4.

And yes, before I get flamed, Checkpoint and other network firewalls offer application firewall modules for their network firewalls. However, my experience with these add-ons has indicated that they take too much horsepower away from the network firewall and are better served being on their own device.

In regards to using application vulnerability scanning tools, they are the only way to go if you use the right languages. Otherwise, you're going to have to do code review the old fashioned way - line by line.

IMHO, the key to complying to requirement 6.6 is to make sure that your processes are part and parcel of your development processes. Application remediation can take a lot of time sometimes, so vulnerability scanning or code reviews should be conducted BEFORE an application goes into production, not after.

[jonassono]

Not sure what is meant by "if you use the right languages".

Web application vulnerability scanners are 'language or code independent' as they are looking for functional vulnerabilities such as a buffer overflow, SQL injection or a cross site scripting vulnerability. - that's the beauty of this option.

Regardless of whether the app. is written in C#, VB, Java or COBOL, the scanner tests for the vulnerability and if the web application fails the functional test, BINGO.

The last set of web application vulnerability scans I performed, I had no access to the source code, no idea what the language might be or what the SQL database engine was, i.e. SQL Server, Oracle, MySQL.

The first error message that came up for a SQL injection test using a single quote was Error 500 "server failure" which demonstrated that the application was not sanitizing the input. The underpinning language and database technology was irrelevant.

[jbhall56]

If you use scripting languages like HTML, Java, ASP and the like, a lot of application scanners will look at the code itself and do a much better job assessing the application. Otherwise, all you get is an application vulnerability scan.

Tools like AppScan can actually integrate into Microsoft VisualStudio and a few other development platforms to do application vulnerability assessments while the code is being developed versus after the fact. In those cases, it can assess certain compiled languages as well as the scripting languages.