What’s new in PCI DSS v3.0 for Penetration Testing?

May 15, 2014

The PCI (Payment Card Industry) Security Standard Council releases a mandated PCI Data Security Standard (DSS) with the goal of securing cardholder data that is stored, processed or transmitted by merchants and other organizations. PCI DSS follows a 36 month lifecycle at the end of which a new version of the standard is released.

The latest version, PCI DSS v3.0 released in November 2013, enhances its prior version from various perspectives; to name a few: by providing more focus on areas of greatest risk, adding more flexibility for assessing and implementing the requirements, and providing more details per requirement for better understanding the intent and application of the requirements. As a main area of our interest, PCI v3.0 enhances the Penetration Testing requirement (i.e., Requirement 11.3) by adding guidelines that help both the organizations and the auditors to better show and understand two important areas of concern in every PCI compliance effort (as mentioned in the PCI v3.0 change highlights):

  • Understanding details of the proper penetration testing method to use; and
  • Verification of the network segmentation used for the scoping.

Both of the above additions, address long-lived challenges that organizations experience during scoping and running penetration testing for the purpose of PCI compliance. Segmentation plays a determining role when it comes to scoping a PCI audit, and without proper verification of the segmentation, drawing the scope lines could become a painstaking task that typically leaves gray areas that need extra resources spent on precise scope determination. Testing and verifying the segmentation on an annual basis will help organization to determine their PCI scope more accurately and confidently.

Additionally, developing or adopting a widely accepted and industry-approved penetration testing methodology, saves the organizations a lot of time analyzing their penetration testing strategy, and assures them that their budget and effort is spent in the right direction, towards satisfying the PCI requirements.

Last but not least, following the new guidelines will make it much easier for the QSAs to verify the penetration testing scope and output, which in turn translates to a smoother audit and saved time and money for their clients. The following are the details of the new requirements introduced in PCI v3.0 under Requirement 11.3, as listed in its official document:

Requirement for Penetration Testing Methodology

Requirement 11.3: Implement a methodology for penetration testing that includes the following:

  • Is based on industry- accepted penetration testing approaches (for example, NIST SP800–115)
  • Includes coverage for the entire CDE 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
  • 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 for Verification of Segmentation

Requirement 11.3.4: If segmentation is used to isolate the CDE (Cardholder Data Environment) from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems.

Note that these updates to Requirement 11.3 are treated as a best practice until June 30, 2015, after which it becomes a requirement. PCI DSS v2.0 requirements for penetration testing must be followed until v3.0 is in place.

Previous Article
Women in Tech: Rossana Ludena
Women in Tech: Rossana Ludena

Finally: a blog featuring Security Compass’s amazing, vibrant and IT proficient women. I will be writing ab...

Next Article
Making the Business Case for a Software Security Requirements Program
Making the Business Case for a Software Security Requirements Program

Most of our customers need to justify the costs of implementing a software security requirements program wh...

Learn how you can use SD Elements to integrate security into software development.

Watch Video