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.
