The latest version of the Payment Card Industry Data Security Standard (PCI DSS v2.0) went into effect on January 1, 2011. If your work for an entity that stores, processes, or transmits credit card data in electronic form than your organization is required to comply with the standard or risk disciplinary action: being fined for lack of compliance by the acquiring bank or, in very extreme cases, no longer allowed to accept credit card payments.

If your company’s been in business a while, PCI and PCI compliance are nothing new. The standard has been around since December 2004 and the individual card brand compliance programs that form the basis of PCI have been in place even longer. Chances are your company has already been through a few PCI DSS assessment cycles and you have a few successful RoCs (report on compliance) under the belt. However, you may be wondering if the changes in the recently issued v2.0 of the standard will change your compliance process or require new controls or procedures in order for your organization to be compliant. In this short overview, we’ll take a look at the differences between v.1.2.1 and v2.0 of the PCI DSS and what, if anything, that will mean to your company.

Don’t Panic – Clarifications

First some good news: there is a year to comply with the new standard. If your company started a RoC assessment cycle in 2010 using v1.2.1, that cycle can be completed before the end of 2011 against v1.2.1. If you’re starting a new assessment in 2011, the RoC will be based on v2.0 but that doesn’t mean a significant change from previous assessments. The reason for this is that the overwhelming majority of changes between the previous and new version of the standard are clarifications.

The PCI Security Standards Council defines “Clarifications” to the PCI DSS as follows – “Clarifies intent of requirement. Ensure that concise wording in the standards portray the desired intent of requirements.” Of the 137 changes detailed in the Summary of Changes from PCI DSS Version 1.2.1 to 2.0, 119 of them are typed as clarifications. One common complaint with PCI DSS compliance is that covered entities and assessors often disagreed about the wording or intent of the requirements and testing procedures in the DSS, which led to contentious disagreements about what did and did not constitute compliance.

The purpose of the clarifications is to lower the points of contention during audit with better, more precise wording in the standard. To that end, many of the specific changes are relatively minor but do eliminate wording that could be considered vague. Some examples are below:


Section

Old Wording

New Wording

Change Explanation

1.3 – Testing Procedure

Examine firewall and router configurations, as detailed below, to determine that there is no direct access between the Internet and system components, including the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment.

Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—to determine that there is no direct access between the Internet and system components in the internal cardholder network segment, as detailed below.

Restructured to clarify intent of procedure.

3.2.1 Requirement and Testing Procedure

Do not store the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.

Replaced “contained in a chip” to “equivalent data on a chip” for consistency.

10.7.b Testing Procedures

Verify that audit logs are available for at least one year and processes are in place to restore at least the last three months’ logs for immediate analysis.

Verify that audit logs are available for at least one year and processes are in place to immediately restore at least the last three months’ logs for analysis.

Clarified that the test should confirm that audit log processes are in place to “immediately restore” log data, rather than that log data should be “immediately available” for analysis.

Sources: PCI DSS Requirements and Security Assessment Procedures, v1.2.1, July 2009 and Summary of Changes from PCI DSS Version 1.2.1 to 2.0, October 2010.

As this table shows, if a company has already prevented direct access between the Internet and system components in the cardholder network segment for testing procedure 1.3 in v1.2.1 of the DSS, the new wording should not require any immediate actions or changes in order to be compliant with v2.0. And if a company was able to restore 3 months of logs for immediate analysis (10.7.b), they should also be able to immediately restore those logs for analysis. While these are only three of the total 119 clarifications detailed in the Summary, they do provide a good level-set for the kind of wording clarifications throughout. And since all companies differ, do review all of the clarifications to make sure there is no impact to your company.

Page 2: Getting Ready for PCI 2.0 Compliance