PCI DSS and PA-DSS 2.0 Are Here – Almost

Well the long wait is beginning to end as the PCI SSC let us see some more information on the new PCI DSS and PA-DSS.  On August 12, the PCI SSC drew back the curtain on PCI DSS 2.0 and PA-DSS 2.0 by issuing a Summary of Changes document.

My first surprise was that there is a new version of the PA-DSS being released with the PCI DSS.  I knew that the PA-DSS was also being worked on, but I did not think that it would be released with the new version of the PCI DSS.

Even though the two standards are only changing in a minor or, in the words of PCI SSC General Manager Bob Russo, an “evolutionary way,” the PCI SSC is versioning the standards as 2.0, not 1.3.  For those of us in the software business, that would seem to indicate a major revision, not something minor.  So, while we have a glimpse of what is coming and it does appear minor, it still may have some major impact.

According to the PCI SSC’s release, the updated versions of the standards have been designed to provide greater clarity to the requirements, improve flexibility for merchants, help manage risks and threats, and align with changes in best practices.  Unfortunately, the devil is in the details, so until we see the revised requirements, we will not know if the standards have met these objectives.

The changes will be discussed at the upcoming Community Meetings in Orlando and Barcelona.  The updated standards are to be issued in final form on Thursday, October 28, 2010, and are to be in effect on Tuesday, January 11, 2011.

So, what are the changes?  Here is my take on what they are saying regarding the PCI DSS 2.0.

  • The Introduction for the PCI DSS is being revised to clarify that requirements 3.3 and 3.4 apply only to the PAN.  The language in the Introduction is also being revised to align the language used with the PTS Secure Reading and Exchange of Data module.
  • The PCI DSS Scope of Assessment section is being revised to clarify that all locations and flows of cardholder data needs to be identified and documented to prove that the Report On Compliance has been properly scoped.  For traditional retailers, this will not likely be much of a big deal.  However, for my clients that have a variety of retail and hospitality, it will be interesting to see the impact this may create.
  • The PCI DSS Introduction and relevant requirements are being revised to take into account virtualization.  The Introduction will include definitions for virtual components.  Requirement 2.2.1 will be clarified to further define the “one primary function per server” as it relates to virtualization.  Since networks, servers and storage can all be virtualized, it will be interesting to see if they truly clarify this subject or if they just create more confusion.
  • In PCI DSS requirement 1, they intend to provide clarification on the DMZ by clarifying secure boundaries between the Internet and the cardholder data environment.  Like virtualization, it will be interesting to see if they truly clarify things or just increase the amount of confusion.  I have posted my thoughts on this topic, so I am also curious to see how close I am to the PCI SSC.
  • Requirement 3.2 will finally have a statement that Issuers need to retain Sensitive Authentication Data, aka track data, CAV2/CVC2/CVV2/CID and PIN block.  I know of a couple of instances where issuers were told by uninformed QSAs that they were not allowed to keep this information because the PCI DSS did not allow them to keep it.  This was even though in every QSA training session I have attended the trainers have always been very clear that Issuers are a very special case when it came to requirement 3.2.  However, I suppose since it was not in writing, there were QSAs that could not accept that fact.
  • In requirement 3.6, the key management processes will be further clarified to increase flexibility of key changes, retirement/replacement of keys and further define the use of split control and dual knowledge.  It is surprising that this is an issue since QSAs are required to have a relevant security or auditing certification and almost all of the security certifications have requirements that you understand encryption techniques and key management.
  • Requirement 6.2 is being adjusted to allow for a risk-based vulnerability assessment process so that those vulnerabilities with the highest ranking are addressed first versus just patching everything within a 30 day time period.  In my book this is just going to give organizations what they think is more wiggle room on patching.  It will also make testing this requirement more difficult for the QSA if they do not know what they are doing.  Most organizations have a horrible patching process and their systems are vulnerable as a result.  This will likely not help things get better.
  • Requirement 6.5 is being rewritten.  First, requirement 6.3.1 is being merged into 6.5 to get rid of any redundancies for secure coding of internal and Web-facing applications.  Then 6.5.a is having CWE and CERT being added to the OWASP standard so that QSAs are not just quoting the OWASP standard as the only secure coding standard.
  • Finally, requirement 12.3.10 is going to be updated to allow for the justification of copying, moving or storing cardholder data when being accessed remotely.  I can understand why this change is being made because of all of the people that are working from home or other remote locales.  Depending how this requirement is rewritten, this could be a problem for QSAs.  In particular if the PCI DSS allows the storage of cardholder data on remote systems.

I found the changes to the PA-DSS to be the more interesting of those announced.

  • The most interesting change in my opinion is the fact that the PA-DSS may now be applicable to hardware terminals.  I have always felt that this was a big hole in the PCI standards.  The fact that card terminals have software and applications, but those applications were not covered by the PA-DSS was just wrong.  Hopefully the PCI SSC and the card brands have agreed with my position.
  • Requirement 4.4 of the PA-DSS will be aligned with requirement 10.5.3 of the PCI DSS so that applications are required to facilitate centralized logging.  One of the biggest problems with logging is that applications typically do not do enough of it.  Hopefully this change will address that situation.
  • Requirements 10 and 11 will be merged to reduce redundancies.  Since these requirements deal with remote access and remote updating, this should make things a lot clearer and easier to assess.  However, I am fearful that this combination could result in unintended consequences and make things less secure.

Until we all get to see the actual detail behind the changes, all of the consequences are just scientific wild guesses.  So we shall see what it is the PCI SSC delivers in the way of details.


6 Responses to “PCI DSS and PA-DSS 2.0 Are Here – Almost”

  1. March 28, 2011 at 2:36 PM


    Are there any specific ‘suggestions/recommendations’ about implementing the centralized logging requirement? I seem to find the same text in most of my search results, but no one saying that using implementation xyz will cover the requirement.

    • March 30, 2011 at 8:18 PM

      There are many SIEM solutions (commercial and open source) running around that will meet the PCI requirements as long as they are properly implemented. It is that implementation process that is the trick. We find that if an organization was not doing a good job of log management and review before implementing the SIEM solution, the SIEM solution does not usually improve their log review and management processes. In order for any SIEM solution to be effective, an organization typically needs to start over on their log management and review processes so that they get the right processes put in place and the culture is focused on log management and review. However, what you will find is that open source solutions come with less functions/features out of the box. It is not that those capabilities cannot be added, but it is up to you and other users to come up with those features/functions by developing your own queries, scripts, reports, etc.

  2. September 14, 2010 at 7:56 PM

    Hi, to begin…Great posts. This is a very confusing and misunderstood topic and you are doing a good job delivering a little real life application to the standard. Keep it up! That said, I do have a question.

    We are looking at building an iphone app for a high volume large retailer who wishes to trade online. Architecturally we had an idea to build an app and inbed a third party hosted “PCI compliant I-frame” into the app. So when a users enters their Credit Card details they will effectively be entering their details not into the app but rather into the hosted solution…all within the application..kind of. I was subsequently informed that apple does not allow this. Do you have an opinion on this course of strategy and do you know if Apple, or Android and Windows 7 has a solution that meets this requirements?

    Thanks for your time


  3. 4 T. Anne
    August 13, 2010 at 9:40 AM

    In regards to the naming choice, while I do think there will be some changes – I do not believe they will be overly complicated to enforce. The PCI SSC said that with each new life-cycle the new version would be a _.0 one and that any updates made during the life-cycle would be a _.1, _.2, _.3, etc ones. I see the choice in naming a result of a new life-cycle, not an indication of the content within it. However, we won’t truly know the full impact until all the details are out.

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 )

Google+ photo

You are commenting using your Google+ 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


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


August 2010
« Jul   Sep »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,997 other followers


%d bloggers like this: