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.

Keep up with security news; Follow eSecurityPlanet on Twitter: @eSecurityP.