PCI Penetration Testing & Vulnerability Requirements

The Payment Card Industry Standards Security Council (PCI) requires several different penetration testing and vulnerability management activities, which are commonly a source of confusion for those pursuing PCI compliance. Some activities must be performed by third parties, whereas others are best performed internally. This blog post seeks to distill out all relevant PCI Data Security Standard (PCI DSS) requirements as of version 3.2.1, including requirements in the often-overlooked PCI Penetration Testing Guidance supplement version 1.1. The intent is to create a clear view of what is required, what is optional, and how best to address each item from vulnerability identification through remediation.

Terms

First, let’s clarify some key terms:

• Vulnerability Scanning: enumeration and verification of all hosts, services, and vulnerabilities, without exploitation of any kind.
• Penetration Testing: exploitation of vulnerabilities or system configuration specifics.
• Segmentation Testing: validation of the ingress and egress network filtering techniques used to limit systems in scope for PCI

Scoping

There are two types of systems in scope for PCI DSS:

• The Cardholder Data Environment (CDE). These are systems that store, process, and transmit cardholder data.
• Systems that support PCI DSS controls (e.g., Active Directory, asset management tools, and administrative access products).

Requirement 1: Vulnerability Scanning

Vulnerability requirements include uncredentialled scanning of all nodes that are in scope for PCI DSS on private and public IP address ranges. Perform scans monthly and establish a remediation process for all high and critical vulnerabilities where a ticket is created and worked toward remediation.

A PCI assessor should be able to audit your vulnerability management process, including date and scope of scan, tickets resulting from scan, and remediation activities performed. In cases where there are false positives or accepted vulnerabilities, a change ticket capturing this information and rationale should be created. Vulnerability scans are best performed by your IT or Information Security team using a commercial tool such as Tenable.IO, Nessus, Rapid7, or Qualys. Schedule your tool to run at least monthly right after your patch cycle.

Requirement 2: ASV Scanning

PCI DSS requires that you use an Approved Scanning Vendor (ASV) for externally-facing IP addresses that comprise the edge of your CDE. Even if you are not listening on any services and there are no open ports, these IP addresses must receive an ASV scan monthly. This is not a scan that you can perform yourself and most penetration testing service providers do not offer this service.

Any findings that rate as a Common Vulnerability Scoring System (CVSS) 4.0 or higher severity rating must be remediated. You can submit a request for a remediation exception with the ASV, and it will be reviewed to ensure that the circumstances preventing remediation meet the spirit and intent of all PCI DSS controls.

Requirement 3: Network Penetration Testing

This is a black-box test (no prior knowledge of architecture, systems, services, or vulnerabilities) of internal and external network ranges. The external network testing range should be the same as the ASV scans. The internal penetration testing scope must be performed from a network location just outside the inside perimeter of the CDE. You do not need to test from within the CDE, although this is recommended.

You must also test against systems that support your PCI DSS controls. In cases where you have a data center, virtual switch, or a cloud-based virtual network (e.g., AWS VPC), it is common to test from these locations in order to cover all of the in-scope network.

Your PCI Qualified Security Assessor will help define the scope of PCI DSS systems and the scope of internal penetration testing. Network penetration testing is best performed by an objective third party.

Requirement 4: Application Penetration Testing

Testing of applications includes the use of a representative set of credentials to test application logic, session management, user authentication, and user authorization.

Testing for OWASP Top 10 is a minimum requirement. However, the full gamut of testing methods included in the OWASP Testing Guide v4 is recommended.

In multi-tenant environments, create testing accounts in different tenants.

If your system has an administrative web portal that uses the same backend systems but has a separate frontend, all application interfaces are in scope.

If you are taking cards over a web interface and using a third-party API for card authorization and/or tokenization, your web application is still in scope. Depending on what the application does, additional review of your code and code deployment methods may be needed to ensure that malicious code or developer access to production systems is effectively handled. Web applications, private and public APIs, and mobile applications may be in scope if payment is handled over these platforms.

Secure coding methods and static/dynamic code analysis do not satisfy the penetration testing requirements.

Application penetration testing is best performed by a third party with application testing knowledge and experience.

Findings that may affect the security of CDE must be remediated prior to the successful conclusion of your PCI assessment however determination of “must-fix” findings is left to the discretion of the PCI QSA.

Segmentation Testing

Every segmentation method must be validated annually during the penetration test. You do not have to test every instance of each segmentation method; a representative sample can be used.

Service providers must do an additional segmentation-only test six months after the penetration test.

Segmentation is not a PCI DSS requirement but it can be used to limit the in-scope PCI DSS systems.

Segmentation does not necessarily mean that there is no communication between networks. Ingress and egress traffic between networks is allowed if it is mutually well-defined based on business needs and is as restrictive as possible.

During PCI assessments, it is common to review segmentation methods for subsequent testing by a third party. For example:

• Network A has no access to Network B.
• Network B can access Network C on TCP port 22 only.
• Network C has no egress network access.
• Testing – ensure that:
  • A cannot reach B or C or open internet.
  • B can reach C on TCP 22.
  • C cannot reach A or B or open internet.

Social Engineering

Phishing, spear-phishing, and phone pretexting are not currently PCI DSS requirements. However, the supplemental PCI Penetration Testing Guidance version 1.1 recommends that “an entity can incorporate [social engineering] into its penetration testing methodology as an ongoing method to determine the effectiveness of the security awareness program.”

In cases where ransomware could greatly affect cardholder data security, it is recommended that social engineering testing take place. It can also be considered where credential theft through phishing could lead to a significant security breach.

Requirements Snapshot

Here’s a summary of the requirements we’ve covered.

References

• Penetration Testing Guidance supplement version 1.1 published September 2017
• PCI Data Security Standard 3.2.1

We Can Help

If you have questions about the penetration testing and vulnerability scanning requirements covered in this blog post or would like help implementing this type of testing and scanning in your environment, Tevora’s team of PCI security specialists can help. Just give us a call at (833) 292-1609 or email us at sales@tevora.com.

About the Author

Clayton Riness is a Principal Consultant at Tevora.