PCI DSS v3.0

This November has been realised the third version of PCI DSS. The amendments include a few changes from the previous version in both the introductory paragraphs and in requirements and test procedures.

Most of the changes are aimed to clarify issues in the previous version were open to misinterpretation or had raised important questions for organizations or even QSAs.

However, we also find some more fundamental changes, such as new requirements, modified to make requirements more stringent, or also (in less cases) modified to provide greater flexibility in compliance.

We will analyse all these major changes including the new version:

• We found a new section called "Implementing PCI DSS into Business-as-Usual" in which a series of best practices and recommendations on how it should be implemented so that PCI DSS is integrated into the processes of organizations are presented. Note that this is just a series of good practice and therefore are not binding or supersede any of the requirements of PCI DSS.
• Modified the table in which the requirements, so that now a column in which the motivation of each requirement. I think it is a very positive change, and that this explanation will often understand more fully exactly is being requested in each standard requirement without going to see any additional document.
• Requirement 2.4 which states that the organization must maintain an inventory of the components included in the scope of PCI DSS to assist in the use of configuration standards.
• As is known, the PCI DSS Requirement 5 requires the use of anti-virus on all systems except reach those who are deemed unaffected by malware (Mainframe, AS400, UNIX, etc.). The new version 5.1.2 requirement stablish the need to follow the evolution of risks due to malware on systems that are not normally affected by malware and remove them from this category if it is necessary.
• Another new requirement included in the sub-requirement 5.3 has been requesting anti-virus solutions remain activated and can not be disabled or altered by users.
• 6.5.10 requirement is considered good practice not mandatory until June 1, 2015. This requirement states that the procedures and policies should include measures to prevent attacks against authentication frameworks and web management sessions, including the following:
  • Bookmark session tokens (eg cookies) with the flag "secure".
  • Do not expose the session ID in the URL.
  • Incorporate appropriate timeouts and rotation for the session ID after successful login.
• Changed the requirement 8.2.3 so now that this requirement sets minimum in complexity and size of the password but allows greater flexibility in compliance. Although still requires you to use a password of 7 or more characters and include both numeric and alphabetic characters, is given the possibility to use other sizes or complexities whatever remains the same or greater strength in the password to use.
• New requirement (8.5.1) apply only to service providers and requiring these to use different credentials for remote access to systems of each of its customers. This requirement will be considered a good practice not mandatory until July 1, 2015.
• The new requirement 8.6 mandates that, when using authentication mechanisms other than username / password, these mechanisms are univocally linked to individual user accounts and ensure that only the appropriate users can make use of these mechanisms.
• Requirement 9.3 is also new in this release and appearance establishes the need to control physical access to sensitive areas by onsite personal. Also, it must have procedures for authorizing access and revoke such access immediately in termination.
• Other new requirements in this release are ranging from 9.9 to 9.9.3. These requirements require to protect devices that capture the card data directly through physical interaction with them (card readers, etc. ..). Specifically, the requirements asking for a list of existing devices, which were visually inspected periodically to detect anomalies in the same and that is to train staff to detect if devices have been replaced or tampered keeps.
• Requirement 10.5.2 reinforces the generation and review of logs by recording changes in identification and authentication mechanisms, including the creation of new accounts or privilege scalation, such as use the "su" command.
• The 10.2.6 has also been amended to require that the events corresponding to the stop or pause the audit logs are included, in addition to resetting or deleting the logs that already required in the previous version.
• Requirement 11.1.1 now requests that the inventory of authorized wireless access points and their corresponding business justification is documented. Meanwhile, the newly created requirement 11.1.2 establishes the need for incident response procedures detailing the course of action to follow in case of detecting unauthorized wireless networks in the quarterly reviews.
• Requirement 11.3 is one of the most significant changes in this new version. Considered just a good practice until next July 1, 2015 date on which shall be considered mandatory. The requirement mandates that organizations have an annual pentest methodology. This methodology must to consider, almost, the next topics:
• Based on industry-accepted penetration testing approaches.
• Includes coverage for the entire Cardholder data Enviroment perimeter and critical systems.
• Includes testing from both inside and outside the network.
• Includes testing to validate any segmentation and scope-reduction controls.
• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5 of PCI DSS.
• Defines network-layer penetration tests to include components that support network functions as well as operating systems.
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
• Specifies retention of penetration testing results and remediation activities results.
• Requirement 11.5 has also been modified to provide greater flexibility in compliance. Now, instead of requiring you install a FIM, it is requested that any mechanism that allows change detection to alert personnel of unauthorized critical system files, configuration files or content files modifications.
• Changed the requirement 12.2 (old 12.1.2) so that now not only the execution of an annual risk analysis is required, but also after any significant change in the environment (eg, acquisitions, mergers, relocations, etc. ..).
• New 12.8.5 requires to maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
• And finally, the new requirement 12.9 apply only to service providers and will be considered a best practice until July 1, 2015. This requirement will force service providers to provide their customers and sign specific clauses which explicitly recognize their responsibility in managing the security of cardholder data from their customers. 

In conclusion, I think all the changes included in the new version of the standard are positive and that we have a clear standard, with less indefined areas and that permits those organizations that implements PCI DSS not just be compliant but also highly increment the security of card-holder data that is stored, transmitted or processed by the organization.

PCI_DSS_v3_Summary_of_Changes.pdf
PCI_DSS_v3.pdf

Twitter: @omarbenjumea

Linkedin: http://www.linkedin.com/in/omarbenjumea