PCI DSS 2.0 – Which Are Actionable Changes?


The release of PCI DSS version 2.0 brings new requirements and changes that will have a lasting effect on those who must comply with the standard starting January 1, 2010. Which are actionable changes for your organization?

The full spectrum of changes is covered in three documents released by the PCI Security Standards Council:

1) PCI DSS Summary of Changes for PCI DSS 1.2.1 to 2.0

2) PCI DSS Navigating the PCI DSS: Understanding the Intent of the Requirements

3) PCI DSS Requirements and Assessment Procedures

Using the documents each by itself may provide the reader of a false sense of security that PCI DSS 2.0 does not change very much from v1.2.1. Only by using all three of these documents together do the full spectrum of changes, clarifications, and new requirements reveal themselves.

The first class of changes is new and clarified definitions of terms. For example, the introductory paragraph of Section 9, “onsite personnel” is defined as “full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity’s premises;” then this new definition is used in Section 9.2. There is little to no impact between v1.2.1 and v 2.0 for this change.

An example of a clarified term that may have impact to operations is found in Section 2.2.2. Examples of insecure services, protocols or daemons are provided, such as NetBIOS, file share sharing, Telnet and FTP. These are helpful examples missing from v1.2.1. However, the requirement goes on to provide examples of how these services, protocols, and daemons are to be protected if they are required by the organization: encrypted protocol tunnels such as Secure Shell (SSH), Secure FTP (S-FTP), Secure Socket Layer (SSL) or IPSec VPN are to be used. We now have a clarification that may have an impact on daily operations — the deployment of encrypted protocol tunnels between systems using NetBIOS, file share sharing, Telnet and FTP. As NetBIOS and file sharing are common operations on Microsoft Windows platforms, daily operations may be impacted if encrypted tunnels are not already used within the restricted Cardholder Data Environment (CDE).

The next class of changes are risk assessments. Annual risk assessment is required in Section 12.1.2. Now v2.0, Section 6.2, mandates a formal risk assessment to classify High Risk Vulnerabilities that apply within the organization’s CDE. This specific risk ranking becomes a mandated requirement as of July 1, 2012; prior to that date it is an optional Best Practice. The 18 month time frame between the October 28, 2010 release of v2.0 and when the risk assessment becomes mandatory allows organizations sufficient time to research and implement vulnerability ranking systems, such as the Common Vulnerability Scoring System (CVSS), or the US National Institute of Standards (NIST) Publication 800-30 (pdf). Sections 2.2.b, 6.5.6, 10.4.a, 11.2.1.b, 11.2.3.b all reference the risk ranking process. This process must be implemented in order to satisfy its usage in other sections of the DSS. Organizations should not mislead themselves to believe that they can arbitrarily classify a vulnerability as High, as the QSA performing the PCI assessment will be reviewing and validating their processes and the QSA will need to sign-off that the process meets the intent of the requirement. In this case, QSA’s can provide a value-added service by assisting organizations with research and implementation of the risk ranking process.

The final major area of change is the use of virtualization for data center efficiency. Payment Brand compliance programs have allowed virtualization for quite some time. The terse wording of Section 2.2.1, “Implement only one primary function per server”, has created many hours of spirited debate as to how this could be applied to virtual environments. Finally, a clear direction is provided in both the Requirements and Security Assessment Procedures and Navigating the PCI DSS: Understanding the Intent of the Requirements. Each virtual component (machine) must support only one primary function per virtual system component. In addition, it appears that risk levels of the virtual environment should be well understood by the organization. How is that done? By performing a risk assessment of the hypervisor and all the components it controls on a given physical system. Depending on the size and complexity of the environment, it may make sense, for risk management purposes, to separate critical server components between different physical hypervisors. Again, a good risk assessment of the virtualization environment will uncover these details.

PCI DSS Summary of Changes for PCI DSS 1.2.1 to 2.0 provides 20 pages of changes, each with approximately 8 rows, some rows with more than one change. This amounts to approximately over 200 changes. Which of these have no effect on your organization? Which changes will require updates to your existing operations? Which of these will require risk assessment in order to fully understand, accept, and justify usage? More than you might think. Which of these changes are new requirements that go into effect January 1, 2011 and which can be phased in over time? A structured review of the PCI DSS v2.0 standards with all the organization stakeholders in the same room will provide the most efficient method to determine which changes are actionable and who will be accountable for implementation and operation.

Source by Paul Caloca

· · · · ·

Related Articles & Comments

Menu Title