More On PCI DSS 2.0

Just attended the PCI SSC’s Webcast with Bob Russo describing the coming changes to the PCI DSS.  For those of you that missed it, there is a re-broadcast of it on Thursday, August 26, if you want to hear things straight from the horse’s mouth, so to speak.  Just go to the PCI SSC’s Web site and register under Education, Webinars and you will see the link to register.

The first piece of trivia was in regards to calling the standards 2.0 versus 1.3.  Mr. Russo explained that the 2.0 designation was to acknowledge that they were moving from a two year to a three year standard lifecycle for the PCI DSS and PA-DSS.  Later on in the presentation, he explained that any additional clarifications or enhancements within the lifecycle would be numbered 2.1, 2.2, etc., indicating that we can expect tweaks to the standards throughout the three years.

The biggest news out of this presentation is that requirement 6.5 will now apply to all in-scope applications, not just Internet-facing or browser-based applications.  Based on all of the breach research that has been conducted, they have finally realized that any application in the cardholder data environment (CDE) is a potential hazard, not just those on the big, bad Internet.  However, this is likely to cause problems for all of those legacy systems on HP (DEC) VAX, IBM iSeries and zSeries as well as other “antique” platforms.  It is hard to apply a lot of the OWASP/CWE/CERT/etc. secure coding standards to applications that are not written in Java, PHP, .NET and the like.  Some of these standards will apply, but the majority will not.  Since a lot of QSAs have almost zero experience with these sorts of old platforms, it will be interesting to see if merchants and service providers start complaining more about their QSAs lack of experience.  This change will have a major impact on organizations that are running custom software that does not face the Internet and were getting a pass in prior years on requirement 6.5 because of that fact.

Another interesting tidbit is that there will be more guidance forthcoming on issuers and the pass they are being given on meeting requirement 3.2.  As you may recall, issuers are required to retain chip/track data and other sensitive information which violates requirement 3.2 although one could argue it is pre-authorization data.  In prior QSA training sessions we had been instructed to handle issuers with care because of this and to essentially state that requirement 3.2 was ‘not applicable’ because the organization being assessed was an issuer.   We were not given an actual date that this guidance will be issued, just that it is coming in the future.  I will be anxious to see the additional guidance when it is issued.

The pre-release of PCI DSS 2.0 and PA-DSS 2.0 will happen sometime in early September, before the first Community Meeting in Orlando.  However, the pre-release will only be to Participating Organizations, so not even QSAs will see the standard until likely the Community Meeting and possibly not until their release on October 28.  He recommitted to the standards being released on October 28 and the effective date of January 1, 2011.  The other piece of interesting news is that the old standards will be sunset later on in 2011 meaning that there will be a cut off for the previous PCI DSS and PA-DSS standards.

I am sure we will hear more about this in the coming weeks.

7 Responses to “More On PCI DSS 2.0”

  1. 1 spaaceyankee
    August 26, 2010 at 10:09 AM

    I wonder with that 6.5 change, are they going to require internal web apps to be pen tested also?

    “Things That Make You Go Hmmmmmmmmm”

    • August 26, 2010 at 4:13 PM

      The PCI DSS already requires internal pen testing, so your question is moot. See requirement 11.3 in the PCI DSS.

      • 3 spaaceyankee
        August 27, 2010 at 7:10 AM

        Let me clarify, I know we have to do internal pen test, I meant to say internal web-application pen test part.

      • August 27, 2010 at 3:13 PM

        Based on my understanding, the new PCI DSS version is going to basically require that everything you do for application security for externally facing applications is now relevant for ANY application that is in-scope for PCI compliance, internal or external. As I said in my post, where it will get tricky is with applications such as middleware that really have no users (but might have a browser-based management interface) and with applications that do not execute through a browser.

  2. 5 scott
    August 24, 2010 at 3:26 PM

    Issuers can never be compliant with the DSS since they store sensitive card holder information, including track data, in the clear. Every issuer does this. There are a number of other areas most are not compliant, but the DSS it clear.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

August 2010

%d bloggers like this: