PCI DSS version 1.1 and 1.2 differences and updates

On October 1, 2008 the PCI SSC released version 1.2 of the PCI DSS requirements.  There are a number of changes as outlined previously in the update document.  The PCI SSC has established a life cycle process that will ensure the PCI DSS standard is revised and updated on a two year cycle.  What follows is a detailed outline of the differences between version 1.1 and 1.2 (some that have not been discussed previously) and the implications of those changes. (Unless otherwise noted, those items in quotations are taken directly from the PCI DSS or the update document linked above.)

Requirement 1

• In version 1.1 : 1.1.5-1.1.7 discussed similar areas.  In version 1.2 : these requirements are combined into 1.1.5 – business justification and documentation of secure service implementation.
• In version 1.1 : “quarterly review of firewall and router rule sets.”  In version 1.2 : “Requirement to review firewall and router rule sets at least every six months“.  “Now the control can be better customized to the organization’s risk management policies.”

Requirement 2

• In version 1.1 : Requirement 2.1.1 said to “disable SSID broadcast”.  In version 1.2 : this sub-requirement has been removed.  Although it is still something you should do if you can, it’s no longer a show stopper.

Requirement 3

• In version 1.1 : Requirement 3.4 said you could use, “Strong one-way hash functions (hashed indexes)”.  In version 1.2 : “One-way hashes based on strong cryptography.”  This may seem like a minor wording change but the emphasis is on “strong cryptography”, implying the system should repel attacks.  Although it does not say so specifically, one might imagine this means salting the hash value.
• One will also notice the removal of mentions to SHA-1, Triple-DES, and AES or any specific key length.  The emphasis is on strong encryption, something you can read about on the NIST website.
• Requirement 3.4.1 – Disk Encryption – references to “Active Directory” are removed, putting the focus on “local user account databases.”  This reminds us that if we choose to use technologies such as Encrypting File System (EFS), they cannot be reliant on the security of local user accounts.

Requirement 4

• Requirement 4.1.1 – Removes discussion of WEP vs WPA and simply states that cardholder data must be security encrypted over wireless networks, and to “implement strong encryption for authentication and transmission.”  This is the first reference to ‘authentication’ implying that not only must the data be secure, but the authentication to that network must also be protected.
• New implementations of WEP are not allowed after March 31, 2009
• Current implementations must discontinue use of WEP after June 30, 2010

Requirement 5

• At first glance it appears that version 1.2 reverts to an older form of the standard by mandating “anti-virus software applies to all operating system types” but it quickly clarifies the intent still as those systems “commonly affected by malicious software.”  Although the reference to UNIX is removed, it does state that companies should deploy on such systems “if applicable anti-virus technology exists.”

Requirement 6

• Version 1.2 clarified the intent around 6.1 which states security patches must be installed within 30 days of release from the vendor.  “An organization may consider applying a risk-based approach to prioritize their patch installations.”  For example, companies might “ensure high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.”
• Version 1.2 has updated Requirement 6.5 with the latest OWASP Top 10 list!  Furthermore the PCI DSS future-proofs itself by saying, “However, if and when the OWASP guide is updated, the current version must be used for these requirements.”
• Version 1.2 makes Requirement 6.6 mandatory and rewrites the requirement to include many of the items outlined in the Information Supplement released previously.  It states, “public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks.”
• The big change is in the wording of the first option in Requirement 6.6, which states, “Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.”  The mention of code-review is removed and the emphasis is more on tools or methods that will identify vulnerabilities within the application.  I’m certainsome individuals will appreciate this.

Requirement 7

• In version 1.2, the sub-requirements are clarified and flushed out.  Many of the bullet points in the audit procedures of version 1.1 are now their own requirement.  This is a great move to list the requirements as their own section in the “PCI DSS Requirements” section and not as “Testing Procedures”.

Requirement 8

• Minor edits for clarification.  “Clarified that testing procedures must verify that passwords are unreadable in storage and transmission.”

Requirement 9

• In version 1.2 there is a note of clarification for Requirement 9.1.1 stating that video cameras should monitor, “any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes the areas where only point-of-sale terminals are present, such as the cashier areas in a retail store.”  This brings us closer to the implication that “wiring closets” may need a video camera.  Where does the server room and and the wiring closet begin?  As always one should take a risk based approach when answering this question.
• The one benefit to the above clarification is that it expands the scope of video monitoring into areas that contain paper files.  Many companies contain warehouses full of paper files, which under this clarification may require video monitoring as well.  The question will now be, how far does one take this?  Do you need video monitoring in an office environment with only a few papers?  The answer is that, like many thing in the standard, one should take a risk based approach toward answering the question.
• Version 1.2 “Specified that offsite storage locations must be visited at least annually.”  This is only required when data is actually stored off-site, an item that is suggested but not required.

Requirement 10

• In version 1.1 : the standard mandated that companies retain audit logs for “a minimum of three months available online.”  In version 1.2 : this is changed to, “Retain audit trail history for at least one year, with a minimum of three monthsimmediately available for analysis.”  This is to imply that the data need only be maintained for easy access in the event of a forensic investigation.  The options include: “online, archived, or restorable from back-up.”

Requirement 11

• In version 1.2 : the focus on wireless is expanded to recommend the use of a wireless IDS/IPS, “Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use.”  For more information on our analysis of wireless under PCI DSS v1.1, read the wireless FAQ.
• In version 1.2 : Requirement 11.1 has more detailed audit procedures outlining criteria for escalating alerts from a wireless IDS/IPS and integrating the alerts into the required incident response plan.
• The requirement (11.2) for external or Internet vulnerability scanning never explicitly stated an ASV must be used, even though we all knew it.  Version 1.2 clarifies that point where it, “Outlined that ASVs must be used for quarterly external vulnerability scans.”
• Requirement 11.3 explicitly states in version 1.2 that both “internal and external” penetration testing is required.  This includes the Information Supplement released previously on this topic.

Requirement 12

• In version 1.2 : the acceptable use policy for employees-facing technologies now includes, “remote access technologies, wireless technologies, removable electronic media, email usage, internet usage, laptops, and Personal Data Assistants (PDAs)”.  I don’t think the list will ever end, so simply make sure employees understand their role in protecting any technologies part of the cardholder data environment.
• Requirement 12.6.2 changes the statement that employees must sign saying they have read and accept the requirements.  Version 1.2 states this must be done “at least annually”.
• Another important change is that version 1.2 merges Requirement 12.10 into 12.8, changing the requirement for a vendor management program from just ’service providers and processors’ to all organizations including merchants.  The benefit is that instead of saying “ensure the entity is PCI DSS compliant” the standard (12.8.4) now says, “Maintain a program to monitor service providers’ PCI DSS compliance status.”  This basically means all companies must now work with their service providers to not only have a legal contract between them, but also push them towards validating their compliance status.

Appendix

• The Compensating Controls section has been partially rewritten.  The criteria for using compensating controls now includes, “Provide a similar level of defense as the original PCI DSS requirement”, which if you ask me is all you really need in the first place.  If you can provide a similar level of defense then you do so by meeting the intent and rigor of the original requirement.
• Also, the Compensating Controls Worksheet now includes two new sections titled: “Validation of Compensating Controls” and “Maintenance”.  This goes right to the heart of the matter, that auditors must evaluate and validate their compensating controls and maintenance behind securing the  environment on an ongoing basis.

Attestation of Compliance

• In version 1.2 of the standard, the Appendices show both an Attestation of Compliance letter for Merchants and Service Providers.  This simply codifies the required items previously requested in this letter.  We now have a template that everyone can use in a uniform manner.

Scoping and Sampling

• Finally, there is even a flow-chart Appendix on “Determining PCI DSS Scope” and “Determining PCI DSS Samples”.  The scope here only refers to how an assessor might reduce the scope of the cardholder data environment (CDE) with respect to sufficient segmentation.  The sampling chart shows how one might go about sampling an environment.

PCI Blog – Compliance Demystified » Blog Archive » PCI DSS version 1.2 differences and updates.

---

Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically each day to your feed reader. If you don't have a feed reader, you can always have these articles delivered to your email inbox every day. Click here to sign up.