×
We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.

Getting Ready for PCI 2.0 Compliance

Download our in-depth report: The Ultimate Guide to IT Security Vendors

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

Some Welcome Additions – Additional Guidance

Sixteen of the changes are typed as “Additional Guidance” which the Summary document defines as “Explanations and/or definitions to increase understanding or provide further information on a particular topic.” As with the clarifications, many of these are a direct result of feedback from community members and assessors and do a nice job of shining the light of detail into areas that were rather dark before. A couple of notable examples are below:

Section

Old Wording

New Wording

Change Explanation

1.1.5 – Requirement

Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.

Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.

Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP.

Added examples of insecure services, protocols, or ports.

2.2.1 - Requirement

Implement only one primary function per server.

Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server.

(For example, web servers, database servers, and DNS should be implemented on separate servers.)

Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

Updated requirement to clarify intent of “one primary function per server” and use of virtualization.

12.1.2 - Requirement and Testing Procedure

Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.

Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.

(Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and

NIST SP 800-30.)

Added examples of risk assessment methodologies

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.

One very welcome addition here is the mention of virtualization technologies in Requirement 2.2.1. There has been a lot of discussion over whether or not virtualization is allowed under PCI and this requirement specifies that it is - as long as there is only one primary function per virtual system component. Unfortunately, this one requirement does not cover the full gamut of questions related to implementation of virtualization technologies in a CDE. For even more additional guidance, watch for a separate document on virtualization that is being completed by a Security Standard Council Special Interest Group and is scheduled to be formally released by the Council sometime in 2011.

Proceed with Caution – Evolving Technologies

The final change type is “Evolving Technologies.” There are only two of these in the Summary document but they carry a fairly important weight with them because they represent new requirements that take effect on June 30, 2012. Again, there’s some good news, that’s well over a year away so there’s time to plan, but companies should take a close look at these now to ensure there is a plan in place for implementation ahead of the implementation deadline. The two evolving requirements (both taken from the Summary document) are:

6.2 – Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.

  • Risk rankings should be based on industry best practices. For example, criteria for ranking “High” risk vulnerabilities may include a CVSS base score of 4.0 or above, and/or a vendor-supplied patch classified by the vendor as “critical,” and/or a vulnerability affecting a critical system component.

In v1.2.1, Requirement 6.2 called for the establishment of a process to identify newly discovered security vulnerabilities but did not mention risk rankings. While risk rankings are a new requirement (as of June 30, 2012), the standard allows companies to use the freely available CVSS scoring and vendor classifications as part of the ranking system. Additional information on CVSS and how to use it can be found at NIST andFIRST.

6.5.6 – [From 6.5: Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include] All “High” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).

The previous version of the DSS listed a modified version of the OWASP Top Ten in the 6.5 secure coding guidelines for applications in the CDE. The new version provides updated guidance on secure coding and now includes other industry examples from organizations like SANS and CERT. It also introduces this new requirement, which specifically indicates that “High” vulnerabilities must be identified and prevented in the development process. Companies that already have a robust secure application lifecycle in place may be in compliance with this new requirement already. But for companies that aren’t, additional controls and testing in the development lifecycle will need to be put in place before June 30, 2012.

Diana Kelley is a partner at IT research and consultancy firm SecurityCurve and a frequent contributor to eSecurityPlanet.com.

Submit a Comment

Loading Comments...