Deciphering the PCI Testing Requirements of PCI-DSS Requirement 11

PCI-DSS Requirement 11: Regularly test security systems and processes

As a Qualified Security Assessor (QSA) organization and a security analyst, we receive many questions about meeting the various testing controls outlined within the Payment Card Industry Data Security Standard (PCI-DSS) Requirement 11. This requirement is titled “Regularly test security systems and processes”. These tests include Wi-Fi, vulnerability, and penetration testing. In this blog post we will discuss the control objectives and what is required and recommended to meet compliance with each of them.

If you are performing a PCI Report on Compliance (ROC) or using SAQ-D (Self-Assessment Questionnaire) you must meet every control objective within Requirement 11. However, if you are using one of the other SAQs you may not need to perform every test.

11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis

The biggest question we typically get with this requirement concerns whether the wireless network tested must be part of the Cardholder Data Environment (CDE). In actuality, this test focuses on any wireless network, whether it is part of the CDE or not. The basis for this requirement is to identify and document all wireless networks operating within your environment. If you are using wireless networks within the CDE, additional requirements must be met. Specifically, Requirements 1.2.3, 2.1.1, and 4.1.1. Regardless of whether or not you have a wireless network, Requirement 11.1 must be conducted at least quarterly. As part of this test, you are required to catalog all wireless access points beacons, and networks that are detected and determine their origin. Of specific concern is the identification of any rogue or ad-hoc wireless networks that are connected to your production network. These unauthorized networks must be disabled to prevent unauthorized access to the CDE. There are several tools and techniques that can be employed to perform this testing. Alternatively, the use of a wireless intrusion detection system (WIDS) can be used in place of the quarterly manual testing.

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades)

As with all of the PCI-DSS requirements, vulnerability scanning must be performed on devices considered within the scope for PCI at a minimum. While it is a good recommendation to scan all devices within your network quarterly, compliance with this requirement can be isolated to the CDE. Any automated or manual solution can be used to scan for vulnerabilities provided it meets the standards for detecting vulnerabilities and can produce risk ratings that can be mapped to the Common Vulnerability Scoring System (CVSS) standard. For the internal scanning, the testing must be performed by qualified personnel which could include current staff or a third-party firm that specializes in vulnerability scanning. To achieve compliance with the internal scanning requirement, the tests must be performed quarterly and any high-level findings must be addressed within the span of the next quarterly testing cycle. A QSA will require four sets of reports that indicate scanning was completed and show high-level vulnerabilities have been addressed.

On the other hand, the external testing must be performed by an Authorized Scanning Vendor (ASV). This is a certified third party who meets the PCI Security Council’s requirements for performing external vulnerability scans. Unlike the internal scans, you must pass your external vulnerability scans in order to achieve compliance. ASV scans use an approved scanning profile and the reports must be delivered following the PCI Security Council’s recommended templates. Any vulnerability with a CVSS score above 4.0 or that is classified as an automatic fail, must be remediated and a complete re-scan must be performed in order to reach a passing scan. A QSA will expect to see four passing scans over a 12-month period.

If this is the first PCI assessment / audit that is being performed, the quarterly requirement is waived but at least one scan must be present for each test. One other important note regarding ASV scanning; the scanner IP address(es) must be white-listed through all external security layers, such as firewalls, IDS / IPS, and third-party network security providers.

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

• Is based on industry-accepted penetration testing approaches (e.g., NIST SP 800-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

This control includes several sub-requirements that must be addressed depending on the construction of the CDE. They include internal penetration testing and segmentation validation, external penetration testing, and web application penetration testing. For PCI considerations, only the systems / applications that are defined as part of the CDE are in scope for these requirements. These tests must be completed at least annually. Any critical findings must be remediated as soon as possible, and a re-test must be performed. Compass IT Compliance recommends performing external and web application penetration testing for all internet facing devices / applications at least annually. It is critical to understand the difference between a penetration test and a vulnerability scan as both are required to meet PCI compliance. We’ve written several blog posts that detail the differences if you would like further details.

11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment)

This test equates to what everyone thinks of as network hacking. This is a network-layer penetration test against all identified externally facing IP addresses / systems that are considered as part of the CDE. The goal of the testing is to attempt to exploit weaknesses within the security, configuration, or operating system to gain unauthorized access to the CDE. Denial-of-Service (DoS) attacks are out-of-scope, however social engineering (e.g. phishing) could be employed (and probably should) if allowed by the client. Unlike ASV scanning, the penetration testing source IP addresses do not need to be white-listed.

This requirement may also include application-layer testing if you have deployed any web-applications that are considered in-scope for PCI. These tests would be run against the OWASP top 10 controls. The goal of the web application testing is to attempt to compromise the design or performance of the application in order to reveal sensitive information that an attacker would not otherwise be authorized to view, or to gain access to the PCI data stored within the application or the attached database / file store.

11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment)

This requirement, along with 11.3.4 generates quite a bit of confusion regarding the scope and targets of the testing. The PCI Council’s goal for this test is to prove that no unauthorized networks can gain access to the CDE. This means that the penetration testing (again, network layer penetration) is performed from a network segment that is not authorized to access the PCI CDE. The actual targets of the test would be any devices that are found in the path between this network segment and the CDE, including routers, switches, firewalls, SSH / VPN jump hosts, etc. To perform this testing, Compass IT Compliance usually brings a testing laptop on-site to the client, configures it in a non-PCI VLAN, and maps out the devices between the network and the CDE. Those devices are then subjected to penetration testing procedures in an attempt to gain access to the CDE. The goal of this test is to compromise a device that would allow a non-authorized agent to gain access to the CDE. In many cases today, company’s CDEs are hosted in cloud-based environments. In these cases, admin-level workstations with permissions to access these cloud networks are also included in the penetration testing. Compromising any of these admin devices could allow unauthorized access to the CDE and / or disclosure of PCI data.

If there are applications used only by internal resources, application-layer testing may also be required as part of the internal penetration testing.

11.3.4 If segmentation is used to isolate the CDE 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 systems in the CDE

In conjunction with 11.3.2, this testing is used to validate that no non-PCI authorized networks can access the CDE. Unlike other PCI-DSS requirements, there is no specified allowance for sampling as part of the DSS. However, in many cases, a client’s network could have hundreds of separate VLANs that would need to be tested. In recent months, several clarifications have been published addressing this dilemma. These clarifications allow for a sample of VLANs based on the configuration and segmentation solution used. If the method of segmentation is the same across a set of VLANs (ACLs, firewalls, physical, NAC, etc.), then a sample of these VLANs may be tested provided the security analyst can verify and provide evidence that the segmentation configuration is the same across those segments. This can help reduce the scope of the testing significantly.

11.3.4.1 Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls / methods

If you provide PCI related services to multiple merchants / consumers, you must perform Requirement 11.3.4 at least twice a year.

11.4 Use intrusion-detection and / or intrusion-prevention techniques to detect and / or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines, baselines, and signatures up to date

This requirement expects an always-on solution that is used to monitor and detect possible dangerous traffic attempting to flow into or out of the CDE. You must provide a sample of the IDS / IPS logs along with records that confirm that the system(s) is updated regularly to your QSA for compliance.

11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files, and configure the software to perform critical file comparisons at least weekly

This is another always-on control that monitors critical systems, configuration, or content files for unauthorized changes. Your QSA will likely review this system’s configuration to ensure all relevant files are monitored and logs are functioning properly. The QSA may also request samples of any alerts that have been produced.

11.6 Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties

As of the PCI-DSS v3.2, every requirement contains this sub-control. You must have documented policies and procedures for each control objective within this requirement. For example, a vulnerability and patch management program, a penetration testing procedure, and a wireless network policy would be a good place to begin. Part of the wireless testing also requires specific language be added to your incident response plan. Your QSA will require copies of all relevant policies and procedures as part of each requirement and specifically for Requirement 12. Ensure that these policies are reviewed, updated as needed, and approved on an annual basis or any time a significant change occurs.

Compass IT Compliance is a PCI-DSS QSA organization with several highly experienced Qualified Security Assessors on staff who would be happy to answer any questions you may have regarding any of the requirements within the PCI-DSS. We also employ a full team of qualified Security Analysts and Testers who can help you design testing programs to comply with the PCI-DSS and many other cybersecurity frameworks. Contact us today to learn more!