PCI Requirement 6.6 - The Clock is Ticking - Michael Sutton's Blog -
PCI Requirement 6.6 - The Clock is Ticking
Welcome to 2008. By now you have no doubt made and broken a number of New Year's resolutions. Not to worry if you've already wasted $50 bucks on a gym membership, there's always next year. I do however hope that taking PCI seriously was on the list and that it remains a top priority. Why this year? What's different about PCI in 2008?

On June 30, 2008, section 6.6 goes from being a best practice to a mandatory requirement. This section has often been debated as it isn't as clear as it could be. Therefore, it has yet to be implemented by many corporations. Unfortunately, procrastination time is over as you now have 5 months to interpret and take section 6.6 seriously. Let's start by taking a look at it:

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

Now I'm not a big fan of this section for two reasons. First I don't feel that it goes far enough. I believe in defense in depth and these choices are not mutually exclusive. An application review and an application firewall are two separate and complementary controls. Both should be implemented. They should not be presented as a la carte replacements for one another.  However, sometimes you can't change the rules and you've still gotta play the game. So let's dig deeper.

My second concern with section 6.6 relates to the wording used in the first option. It leaves a lot of grey area. First off, what is ‘custom application code'? If I take a packaged web application and add a custom style sheet, do I need a code review? In my opinion, canned web applications present significant risk themselves and should be treated no differently.

Beyond this, what constitutes a ‘review' of custom application code? As I've argued in the past, white box testing (aka static code review) is not a replacement for black box testing, or vice versa. They are separate and distinct methodologies with their own strengths and weaknesses. As with other controls, they should be used to complement one another, not compete for solo status. Why would the PCI Standards Council advocate one approach over the other? Fortunately, Dennis Hurst cleared up the confusion when he posted a response from the PCI council on his blog which addressed this very question. When asked if section 6.6 specifically require static code analysis, the council responded as follows:

Using specialized 3rd-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the 3rd-party tool also has the internal expertise to understand the findings and make appropriate changes.

The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects). The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for.

Thank you and regards,

The PCI Security Standards Council Response Team

There you have it, black box testing is acceptable. Unfortunately, at present this causes even more confusion as we're now left with three choices for satisfying section 6.6 - static code analysis, vulnerability scanning or an application firewall. Hopefully, the council will clarify t in the next iteration of the PCI DSS but in the meantime, if you are not adhering to section 6.6, you need to ASAP. Given the choices that you have for compliance this means either hiring a third party to conduct static code analysis/scanning or procuring and implementing an application firewall. The good news is that you have choices. The bad news is that you have five months to get it done.

- michael


Posted 01-31-2008 10:24 AM by erik.peterson

Comments

Blog: Michael Sutton's Blog | Bscopes Feeds wrote Blog: Michael Sutton's Blog | Bscopes Feeds
on 03-08-2009 1:50 PM

Pingback from  Blog: Michael Sutton's Blog | Bscopes Feeds