advertisement
advertisement

Full Text Of The Proposed PCI 1.2

Written by Evan Schuman
August 22nd, 2008

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."


    advertisement

    Comments are closed.

    Newsletters

    StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!
    advertisement

    Most Recent Comments

    Why Did Gonzales Hackers Like European Cards So Much Better?

    I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
    Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
    A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
    The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
    @David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

    StorefrontBacktalk
    Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.