In a recent post by Jeremiah Grossman, he comments on how the PCI DSS Requirement 6.5 mentions the OWASP Top 10 from 2004 when the latest version is from 2007.  Yes, we all know that this to be true, as he notes in his post, but to say that these differences matter is a statement of taxonomical nuance and not one of practical application.

Before I go further I’d like to say that I met with Jeremiah only once (at RSA this year) but from all accounts (Trey Ford) he is a nice guy and technically empowered.  Also, I have a high respect for Andrew van der Stock and the difficult job he has in codifying the OWASP list.  I’ve had conversations with Andrew over the years about the history behind OWASP and PCI and believe I know the reasons things are they way they are.  So let’s go…

To say that the PCI DSS should keep pace with another standard is unjustified.  The PCI DSS requirements have evolved over the years to remove any reference to an outside group or body and genericized its language over things such as file-integrity monitoring and web-application firewalls to accommodate a variety of business processes.  The Council updated the document in 2006 to version 1.1 and virtually eliminated the use of the word “periodically” in place of concrete terms such as quarterly, weekly, or annually.  I understand why this was done as I too thought that periodically meant every 10-20 years (*joke*).

Jeremiah says that due to this usage and reference to prior days we now are in a situation where:

That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF).

Dare I propose that Cross Site Request Forgery (CSRF) (more info here) and Remote File Execution (RFI) are really both simply “Injection Flaws”?  While trying to understand the OWASP list, a friend of mine, Rnast, gave me this bit of wisdom (and humor).  In fact A1, A2, A3, and A5 are all similar in one form or another and exist due to poorly coded web-applications, which in themselves are exploited via the injection flaws that exist in these applications.  Taxonomicaly these are listed as different vulnerabilities due to the initiation of their attack vector and how or what they exploit, but they have many similarities as well.  (Many thanks to Rnast for walking me through some of the more technical parts.)

So, taken literally, even using the 2004 data, which could not have been in the standard (v1.1) due to it being released in 2006 - one would still have to address Injection Flaws, which I would claim is almost 40% of the OWASP Top 10 in 2007!  To make a change, everyone should submit their feedback directly to the Council and propose they make changes for the next version of the standard.

Popularity: 3% [?]

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.

Popularity: 20% [?]

Today the PCI SSC issued a press release about their clarification to PCI DSS Requirements 6.6 (web-application firewall vs. secure code review) and 11.3 (penetration testing).  If you check the supporting documents section of the website you will find the PDFs that the Council released at ETA this year.  The paper copies created immediate conversation in the blogging world, but now they are available online for everyone to read and enjoy.

Requirement 6.6 Code Reviews and Application Firewalls Clarified - Requirement 6.6 was really put in place to address the high level of web-application compromises occurring the in industry.  The wording implies there are two options, but one can imagine any compensating control that protects these Internet facing web-applications from compromise may be sufficient.  The information supplement clarifies each of the two options.

Option 1 - Application Code Review - Properly implemented either of the following would be acceptable:

• Manual review of application source code
• Proper use of automated application source code analyzer (scanning) tools
• Manual web application security vulnerability assessment
• Proper use of automated web application security vulnerability assessment
  (scanning) tools

Option 2 - Application Firewalls - This information supplement defines what a web-application firewall (WAF) is and how it should be implemented and the capabilities it should have or leverage.  Again, I would not read too closely into any one word, but instead understand that such a device should prevent the compromise of cardholder data via the Internet facing web-application.

Requirement 11.3 Penetration Testing - This information supplement provides some important insight into the various aspects on penetration testing, especially the scope.  The scope for such testing is in-line with the scope for the rest of the PCI DSS audit.  We state the scope to be anything that “stores, processes, or transmits cardholder data … or connected systems [that could lead to the compromise of cardholder data]“.  The supplement states the penetration testing scope to be:

The scope of penetration testing is the cardholder data environment and all systems and networks connected to it. If network segmentation is in place such that the cardholder data environment is isolated from other systems, and such segmentation has been verified as part of the PCI DSS assessment, the scope of the penetration test can be limited to the cardholder data environment.

This is rather important because the debate continues over if this implies an Internet only testing or if internal testing is required.  Many people have called for internal penetration testing, and they have a point, but it may not be required.

Remember that penetration testing is a VERIFICATION step and as such anything you can do to verify the internal segmentation is sufficient should be sufficient to preclude the need for internal penetration testing.  Tread lightly.

Popularity: 30% [?]

As we enter 2008 and June 30th approaches we come closer to the day when PCI DSS requirement 6.6 will change from recommendation to a requirement.  The addition of this requirement has sparked serious conversation about the wording nuances, alternatives and definitions.

I’m happy to see these conversations happening as people explore options and alternatives to securing cardholder data.  But we should remember the intent behind this requirement, “either option you chose for 6.6 has to result in prevention of attacks.”  The goal is always to protect cardholder data, so regardless of the method you deploy make sure that it accomplishes this.

Remember that application firewalls are required for Internet facing web applications to prevent against things such as SQL injection (SQLi) and cross-site scripting (XSS).  The industry sees these as high-risk methods of web application compromise and thus must be prevented.  If you have another method of preventing data compromises then suggest it and leverage a compensating control.

Popularity: 19% [?]

For some reason, I’ve run into an inordinate number of questions this week regarding vulnerabilities that weren’t addressed directly in the PCI-DSS — or at least only addressed in a cursory fashion. The document that contains many of these gems is one that most may gloss over; the Technical and Operational Requirements for Approved Scanning Vendors.

Some specific entries of note:

On IDS/IPSs:

Under no circumstance should an intrusion detection system/intrusion prevention system (IDS/IPS) be permitted to interfere with the results of a vulnerability assessment.

On unsupported software:

The ASV must report and determine as non-compliant any identified obsolete software (for example, application software or operating systems (OSs) no longer supported by the respective manufacturers.

On CVSS:

Generally, to be considered compliant, a component must not contain any vulnerability that has been assigned a CVSS base score equal to or higher than 4.0.

On web-application vulnerabilities:

The presence of application vulnerabilities on a component that
may lead to SQL injection attacks and cross-site scripting flaws
must result in a non-compliant status for that component

On denial-of-service:

Vulnerabilities or mis-configurations that may lead to DoS should not be taken into consideration by the ASV when determining component compliance

The quarterly perimeter scan is only a small part of PCI compliance, but it’s rife with idiosyncrasies and requirements for all parties involved.

Popularity: 48% [?]

Several people have written in to ask me about the different web application scanners and their applicability to PCI. One should remember that there are several requirements that a web application scanner could use used for, mainly 6.5, 6.6, and 11.3. This is not to say that a web application scanner will meet these requirements, but that it could be leveraged to assist compliance in these areas.

Liquid Information has a blog post referencing a paper on ha.ckers.org comparing the top tools.

He chose three scanners for the test, less known NTOSpider and two major players that are WebInspect and AppScan. He then ran these in default configurations against different kind of web applications and collected statistics/metrics on coverage and accuracy (e.g. amount of false positives, found vulnerabilities etc).

It looks like NTOSpider came our ahead, but read the results and let me know what you think.

Popularity: 33% [?]

First, let me reiterate how I agree with Kenneth on his views about compliance.

It seems the PCI SSC Community Meeting in Toronto went very well. Some people blogged about it. There is a great post about the future inclusion of PA-DSS into the PCI standard. This is a long planned event that will take time to test and roll-out.

But people have known about the PA-DSS under the name PABP for a long time and many companies (globally) have adopted it.

Not everyone was satisfied with the amount of information at the meeting, but one of the core messages was the need for increased consistency and clarity. This meeting was a major move forward with the players from all parts of the industry meeting to get answers to their questions and make relationships that can help them in the future.

Popularity: 34% [?]

From Jeremiah Grossman’s blog:

How about that! PCI only requires 2 out of the OWASP Top 10 remain, 2 out of the 24 classes of according to the WASC Web Security Threat Classification, and absolutely no mention that the scanner has to be logged in during the scan. Great. So “technically”, the PCI standard itself has NOT been watered down, that much remains the same. What has been lowered is web application security PCI compliance enforcement, which is down to virtually nothing…[full article]

It’s a little-kept secret that ASVs are scrambling to come up to speed in web-app security. Most ASVs come from a network security background and don’t do a great job with the web-app stuff.  Rapid7 is one of the few that has a web-app component; though at Qualys‘ May security conference it was announced that Mike Shema was running the development of their web-app component, which we’d be seeing by the end of this year.

Popularity: 21% [?]

The newest revision to NIST 800-44 was released on June 1st. While it’s not the complete answer, it’s certainly a useful document in the battle for web-application security.

Popularity: 36% [?]

Just a quick post to let everyone know that there’s an interesting thread regarding PCI-DSS 6.6 on the WASC WebAppSec mailing-list.

Here’s the original post:

I have a couple of questions about PCI section 6.6. It states that companies will need to do one of the following two things:

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

or

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

I have the following questions about this requirement:

1. Assuming a company only has enough resources to do one or the other, which would you recommend, and why? Which option is the easier/cheaper route to compliance? Which is likely to lead to the most real improvement in security?

2. Would hiring a company to do black-box scanning and testing of our websites satisfy the first option? Or would we actually need to have the company go through our code line by line and review it for security defects?

3. Does “all custom application code” mean all of our credit card processing code, or every line of code behind every one of our Internet-facing websites?

4. If we go with the code review option and the company that we hire finds a bunch of issues with our code, are we required by PCI to fix all of the issues, just certain types of issues, or none of the issues?

Thanks,
Bubba

Popularity: 27% [?]