PCI DSS Requirements Expanded

On October 1, 2008, PCI DSS 1.2 will go into effect. Since 2004, PCI DSS (the Payment Card Industry Data Security Standard) has provided guidelines for companies to process credit card payments and prevent security threats. Companies that can’t demonstrate PCI DSS compliance face fines and risk losing their ability to process credit card payments—effectively putting them out of business. Although PCI DSS’s requirements seem straightforward enough at first glance, many companies have had a hard time meeting them. PCI DSS 1.2 seeks to clarify and expand upon the existing requirements; no additional requirements are included.


The following is a summary of the changes in PCI DSS 1.2. I wonder: Will these guidelines make it easier for your company to comply with PCI DSS, or more difficult?


PCI DSS Requirements

PCI DSS 1.2 Changes

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 (e.g., 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 time frame 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.


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.