News, Education and Events Decoding Digital Payments & Fraud

News, Education and Events Decoding Digital Payments & Fraud

CNP Series Report – PCI Part 1: New Penetration Testing Requirements

By Jeff Man, Security Strategist and Evangelist, Tenable Network Security, exclusively for CardNotPresent.com

PCI Part 1: New Penetration Testing Requirements When the PCI Security Standards Council (PCI SSC) published version 3.0 of the Payment Card Industry Data Security Standard (PCI DSS) in November 2013, there were several changes the organization felt were significant enough to warrant a grace period.  That reprieve came to an end June 30, 2015, when those changes morphed from “best practice” to “requirement.” There are five new requirements found in PCI DSS v3.0/3.1 that go into effect on this date. This article will focus on the new penetration testing methodology requirement.

Write This Down

Version 3.0/3.1 is a significant overhaul of the previous PCI. Perhaps the most significant change is the expansion of the PCI DSS 11.3, requiring a documented penetration testing methodology that:

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

The implication, in case you missed it, is that you need to [hide for=”!logged”]have this penetration methodology written down and of course you must have a qualified third party or internal resource actually conduct the penetration test(s) according to the requirements set forth in the methodology and by the PCI DSS. The new rules also explicitly state that the penetration testing should not just be “internal” and “external” but should be employed to demonstrate proper network segmentation (segmentation is relied upon to reduce scope), to test applications (particularly web-based applications) and to ensure you provide coverage for your entire cardholder data environment.

Guidance Helps

In PCI DSS v3, the Council added a “guidance” column to the detailed requirements matrix that explains how to meet each specific requirement. For PCI DSS 11.3, the guidance provides some much needed context, stating that a penetration test attempts to “simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment.” The guidance also stipulates that a vulnerability scan does not constitute a qualifying penetration test but must be part of a methodology that includes attempts at exploitation of known or discovered vulnerabilities.

To clarify: network vulnerability scanning (PCI DSS 11.2) is all about discovering vulnerabilities while penetration testing (PCI DSS 11.3) is all about imitating and protecting against threats . This requires manual exploitation attempts or at least a human behind the scenes making decisions based on available data as to what exploitation methods to attempt.

‘Real-World’ Test

Another required element of the penetration testing methodology is to incorporate lessons learned from threats and vulnerabilities experienced in the prior twelve months (since the last pen test). It’s a great idea—but incorporating threats and vulnerabilities experienced by the entire industry in the previous twelve months (e.g., targeted malware attacks against POS systems) would be even more effective.

The overall goal of penetration testing is to provide as “real world” a scenario as possible; a live-fire test not only of all the efforts you’ve made to secure your cardholder data environment, but also to test how well your security countermeasures and detection capabilities are working (i.e., how well your organization responds to malicious activities).

Small Merchants Not Exempt

For those thinking, “I’m a small merchant, this doesn’t apply to me,” think again. Smaller merchants that rely on the Self-Assessment Questionnaire (SAQ) to demonstrate compliance with the PCI DSS are covered by the penetration methodology testing requirements, too. There were several new SAQs released for PCI DSS v3.0 as well as expansion and revision of the existing ones. Most notably, merchants that qualify to complete the new SAQ A-EP “Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing” are now required to conduct penetration testing of their own Website/Web presence. Merchants that complete SAQ C “Merchants with Payment Application Systems Connected to the Internet – No Electronic Cardholder Data Storage” are now required to have and execute a methodology for conducting a penetration test to demonstrate the assertion that their cardholder data environment is properly segmented away from the rest of the corporate network. Of course, merchants and service providers that complete SAQ D are also required to employ a documented penetration testing methodology.

Think about it: if you have met the other 10 requirements, then all that is left is to provide a safety net with a network vulnerability scanning program and, finally, conduct a penetration test to see how well you’ve done.

Do the Work

Too often, the penetration testing done for PCI customers is a bare-minimum, low-cost, glorified vulnerability scan or assessment. For example, if the penetration test indicates some compromise or access based on a missing patch, the vulnerability is not the missing patch. It is the deficiency of the process that led to the patch not being applied to the target system . Another example: let’s say the penetration test was successful due to a misconfiguration or the presence of a default setting. The vulnerability, then, is the failure of the build process that put the vulnerable system into production in the first place.

The penetration testing exercise should be a way to measure the effectiveness of your processes and procedures, serve as a deeper “safety net” to root out things that have been missed, and ultimately provide evidence that the investments you’ve made in employee training, secure systems administration, and secure technologies is paying off. No results are good results.

A solid, basic-level penetration testing methodology should:

  • Include a stated purpose or goal (or target)
  • Mimic threats and threat agents (the bad guys)
  • Test the security defenses such as IDS/IPS, alerts, response
  • Account for all attack vectors and destinations
  • Document what is attempted and indicate success and failure
  • Present findings in an informative, educational, and actionable manner

Hopefully, the new requirement for implementing a penetration methodology will lead to more secure environments, fewer breaches, less cardholder data compromised and, ultimately, less fraud. If you are searching for a good place to start in developing a sound penetration methodology, try NIST Special Publication 800-115 Technical Guide to Information Security Testing and Assessment or the SANS publications such as Conducting a Penetration Test on an Organization .

Jeff Man has compiled a rich knowledge base in cryptography, information security, and most recently PCI. With PCI impacting nearly every business vertical, he has served as a QSA and trusted advisor for both VeriSign and AT&T Consulting. As an NSA cryptographer, he oversaw completion of some of the first software-based cryptosystems ever produced for the high-profile government agency. Currently, he is Tenable’s PCI SME and a Security Strategist.

Read PCI Part 2: Card-Not-Present vs. Card-Present Requirements

Read PCI Part 3: Third-Party Crashers

[/hide]

  • Share this Article:

Daniel Leibovitch