PCI DSS and Regulatory Compliance Blog

PCI DSS Requirement 6.6

June 15th, 2008 Posted in Merchant, PCI DSS, PCI SSC, Service Provider, Web Applications

Many people know by now that PCI DSS Requirement 6.6 is going into effect (meaning you must be compliant) on June 30, 2008.  What these same people are asking is, how does this apply to me and my business?  And how can or should I comply with this requirement?  There have been a number of blog posts about this requirement and even more discussions about what it all really means.

What does it mean?

In order to understand this you have to take my Attack Vector based Risk Management (AVRM) approach towards the intent behind this requirement.  One could easily reference that the intent behind this requirement is to prevent Internet-facing web-application compromises and you would be correct, but also missing the deeper meaning and back story.

Although card-present (typically IPOS) systems account for a greater number of credit cards stolen, about half of all account compromises are a result of web-application data breaches.  Of this population, about 90%+ of the data compromises are a result of the top 5-10 web-application vulnerabilities.  These include, but are not limited to, SQL injection, cross-site scripting, cross-site request forgery (CSRF) and other input/output validation issues.  Knowing this you can now imagine that if we could mitigate the risk of these top attacks we could reduce the population of credit card data breaches by almost half!  (This does not reduce the number of credit cards stolen by half.)

The consideration here is not just to protect against the OWASP Top 10 but to consider those that apply to your web-application and understand those that cause the highest risk to your application.  Consider the risk you could mitigate simply by properly validating the input/output on your application.  Would this address all risk?  No, but it would get you significant progress towards that goal.

Also, remember there is a difference between compliance and validation.  If you validated your compliance prior to June 30 you do not need to re-validate for 12 months, but you do need to be compliant with the standard at all times.  Compliance is a state of being that you must maintain at all times; for this requirement it means on or after June 30, 2008.

How can I comply?

The best part about this (and other) requirements is the large number of ways to comply.  Remember, the goal is to meat the intent - so how can we do this?  Well the standard states two options, and the intent leaves it open to many others.  Let’s list the two given options first:

  • Have all custom application code reviewed for common vulnerabilities by an organization that specializes in application security.
  • Install an application-layer firewall in front of web-facing applications

First, remember that it is not comparing apples to apples here, but providing options that different enterprises can implement depending on their specific needs and abilities.  We are still aiming to meet the same intent.  Notice that, agnostic of technology, we can meet the intent using either of the prescribed methods.

Second, we should use the ‘intent’ defined above, via the AVRM model, to understand what “common vulnerabilities” means.  To clarify the meaning of “an organization that specializes in application security” they are saying you should use a company that can identify the “common vulnerabilities” and remediate them, rather than your 8 year old nephew who just took her first computer programming course.

Now people are always asking what is an “application-firewall”.  They know what it is, but want to know what you think it is.  We should no longer have to answer that question again, because agnostic of technology an “application-layer firewall” should satisfy the intent behind this requirement as outlined above.

Still not enough?  Well, the PCI SSC has released an Information Supplement that clarifies Requirement 6.6.  Among other things, this supplement offers four additional alternatives towards meeting the intent of this requirement:

  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

Still not enough to meet your business requirements?  Then document a compensating control and write up how it mitigates the risk, to meet the intent, that could not be accomplished due to a legitimate business or technical issue.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

  1. 8 Responses to “PCI DSS Requirement 6.6”

  2. By Dan Taminy on Jun 17, 2008

    Hi Michael,

    Could you recommend about solution that can answer both Code Review and web application firewall?

    Thanks,
    Dan

  3. By Michael Dahn on Jun 30, 2008

    When most people consider addressing this compliance requirement they look at the two options as the only approach. Instead they should look at whatever it takes to mitigate the risk in their environment.

    As you states one could create a series of controls or compensating control that involves one or more of the available options. For example, one may perform (1) a code review with automated tools and remediate any input validation, buffer overrun, and race vulnerabilities. They may also (2) implement a web-application firewall that blocks all other vulnerabilities and active attacks.

    For compliance all you need is a defense measure that will mitigate the risk of cardholder data loss or exposure. If you can accomplish this with only a code review or only a web-application firewall, then that’s your solution. If you use a combination of tools, then that is your solution.

    It’s a matter of how you measure risk within your environment and balance it against the business needs and capital available to secure the cardholder data.

  4. By Jeff Ewing on Jul 9, 2008

    Does this requirement only apply to Internet Facing applications processing, storing, or transmitting the Card Holder data? Or does it apply to any Internet Facing application as they could possibly be a point of access to the CHD environment?

  5. By Phi Cox on Jul 9, 2008

    As I understand it, 6.6 would apply to ANY externally facing Web Application that is determined to be part of the Cardholder Data Environment (CDE). This last part being THE key. That is why segmentation and limiting the CDE is critical to true compliance.

  6. By Michael Dahn on Jul 9, 2008

    @Phil, you are correct in that segmenting the CDE is critical to any audit and PCI scope.

  7. By Michael Dahn on Jul 9, 2008

    @Jeff, you are right in that it applies to any INTERNET-FACING WEB APPLICATION or one that could cause a negative impact on the cardholder data environment (CDE).

  8. By Jeff Ewing on Jul 11, 2008

    Then the million dollar question, what is viewed as an acceptable level of segmentation then? Applying this to any Internet Facing Appication on a Flat Network is not practical…

    Also, is segmenation achieveable when data is stored and accessed on a mainframe?

  9. By Michael Dahn on Jul 11, 2008

    @Jeff, I hate to say it but you’re correct. That is a potentially costly question. The answer to this is as detailed as each environment may be.

Post a Comment