PCI DSS 1.2 CHANGES SUMMARY
FINAL
INTRODUCTION AND PURPOSE
The PCI Security Standards Council has announced that version 1.2 of the PCI Data Security Standards will be available for general use October 1, 2008. The purpose of this document is to provide high level guidance on the changes to be brought about with this key milestone standard revision. Version 1.2 is an update to the current version 1.1 and follows the established approved lifecycle process, which provides for revisions or new versions on a 24 month cycle. While version 1.2 will not introduce any major new requirements, it will include clarifying items designed to fulfill the following goals inherent to the PCI Data
Security Standard:
Provide greater clarity on PCI DSS requirements
Offer improved flexibility
Manage any evolving risks and threats
Incorporate best practices
Clarify scoping and reporting
Eliminate redundant sub-requirements
Consolidate documentation
SUMMARY OF CHANGES
As noted above, the revisions to version 1.2 do not incorporate any new major requirements. Therefore the changes summarized below reflect the same six guiding principles and 12 requirements currently in force under version 1.1. Note that this summary of changes does not include all changes made in version 1.2. The PCI Security Standards Council reserves the right to make final revisions to version 1.2 prior to publication; this summary is for initial preview purposes only, and does not supersede PCI DSS v1.1. Once PCI DSS v1.2 is publicly released, PCI DSS v1.2 will be the official version and further guidance will be provided about effective and sunset dates.
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Clarified requirement to illustrate that all sub-requirements apply to both routers and firewalls
Combined requirements and sub-requirements to clarify requirement 1
Added flexibility in the time frame for review of firewall rules, from quarterly to every 6 months, based on Participating Organization feedback. Now the control can be better customized to the organization’s risk management policies.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Clarified that the requirement applies to wireless environments "attached to cardholder environment or transmitting cardholder data.
Removed references to WEP in order to emphasize using strong encryption technologies for wireless networks, for both authentication and encryption
Removed requirement to disable SSID broadcast since disabling SSID broadcast does not prevent a malicious user from determining the SSID, as the SSID is broadcast over numerous other messaging/communication channels.
Protect Cardholder Data
Requirement 3: Protect stored cardholder data
Emphasized use of consistent terms throughout, such as "PAN" and "strong
cryptography"
Clarified requirement for disk encryption to emphasize local user account databases
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Wireless must now be implemented according to industry best practices (e.g., IEEE 802.11x) using strong encryption for authentication and transmission.
New implementations of WEP are not allowed after March 31, 2009.
Current implementations must discontinue use of WEP after June 30, 2010 Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software
Clarified that requirement for use of anti-virus software applies to all operating system types
Clarified that anti-virus software must address all known types of malicious software
Requirement 6: Develop and maintain secure systems and applications
Added flexibility to the patching requirement by specifying that a risk-based approach may be used to prioritize patch installation
Requirement 6.6 is now mandatory. All public-facing web applications are subject to either 1) reviews of applications via manual or automated vulnerability assessment tools or methods, or 2) installing an application-layer firewall in front of public-facing web applications.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know
Clarified language around testing procedures
Requirement 8: Assign a unique ID to each person with computer access
Clarified that testing procedures must verify that passwords are unreadable in storage and transmission
Clarified user authentication by allowing both passwords and passphrases, and by combining previous bullets under "two-factor authentication" and providing examples
Requirement 9: Restrict physical access to cardholder data
Specified that offsite storage locations must be visited at least annually
Provided flexibility in the requirement for cameras to allow organizations to select other appropriate access control mechanisms
Clarified that the requirement to secure media applies to electronic and paper media that contains cardholder data
Clarified destruction requirements for media containing cardholder data Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Clarified that logs for external facing technologies (for example, for wireless, firewalls, DNS and mail) must be copied to an internal log server
Provided flexibility and clarified that three months of audit trail history must be immediately available for analysis" or quickly accessible (online, archived or restorable from backup)
Requirement 11: Regularly test security systems and processes
Provided more guidance on use of wireless analyzers and/or wireless intrusion detection or prevention systems
Outlined that ASVs must be used for quarterly external vulnerability scans
Specified that both internal and external penetration tests are required and clarified that it is not required to use a QSA or ASV for penetration tests
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security
Expanded list of examples of critical employee-facing technologies to include "remote access technologies, wireless technologies, removable electronic media, email usage, internet usage, laptops, and Personal Data Assistants (PDAs)"
Updated timeframe that requires employees to acknowledge that they have read and understood the company’s security policy and procedures to "at least annually"
Updated former "contract" and "connected entities" language to clarify that organizations must have policies and processes implemented to manage and monitor service providers.
VERSION 1.2 RELEASE SCHEDULE
The entire PCI DSS version 1.2 (or "Security Assessment Procedures" version 1.2 that comprise the standard) along with supporting documentation will be made available to Participating Organizations the first week of September 2008. It will be discussed in further detail at the Council’s Community Meeting in Orlando, Fla. September 23-25, 2008. Release of the standard will be made public October 1, 2008 and follow on discussions will take place at the Council’s second Community Meeting, in Brussels, Belgium, October 22- 23, 2008. Please note that only representatives from Participating Organizations, QSAs,
ASVs, and PED labs can attend the Council’s Community Meetings and organizations interested in learning more about PCI DSS version 1.2 and related security standards are encouraged to join as a Participating Organization. Information can be found on the Council’s Web site (www.pcisecuritystandards.org) or by emailing the Council at participation@pcisecuirtystandards.org."