PCI DSS Blog Series – Requirement 11

The Payment Card Industry Data Security Standard (PCI DSS) consists of nearly 400 individual controls and is a critical part of staying in business for any merchant, service provider, or subservice provider who is involved in handling cardholder data. We find that companies considering PCI are often caught off guard by how comprehensive the PCI DSS is. So, we thought we would help!

CompliancePoint’s PCI blog series will analyze each of the 12 Requirement families. We will outline common challenges our customers face with each requirement, answer some frequently asked questions, and provide some pro tips on becoming PCI certified.

This week’s entry into the PCI Series is Requirement 11: Regularly test security systems and processes

Requirement 11: Regularly Test Security Systems and Processes

Why is compliance with this requirement important (beyond getting certified)?

While designing and implementing security controls to protect your environment and sensitive assets are crucial to maintaining an adequate cybersecurity posture, testing the systems under the protection of these controls is imperative to ensure they are operating effectively. Vulnerabilities are being discovered continually by malicious individuals and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security personnel understands potential risks in a changing environment.

What does this requirement require at a high level?

Testing your systems regularly helps identify potential vulnerabilities or exploits that could negatively impact your environment. Scanning, testing, and monitoring of in-scope systems can alert your organization to findings that may or may not have the ability to impact the security of these systems. It is imperative that as an organization, you have a process defined to internally evaluate and mitigate findings that may be identified as a result of security testing.

A common metric in evaluating these findings is known as the Common Vulnerability Scoring System, or CVSS. CVSS scores are used to rank vulnerabilities on a scale of 1-10 depending on the potential risk or impact they might pose to a particular system. However, even vulnerabilities with the same CVSS score and for the same system might not have the same risk or impact on your environment, depending on other systems or security controls that might be implemented. It is important to have the knowledge and resources internally to not only perform but also adequately review and respond to potential findings from the various security tests outlined in PCI Requirement 11.

When assessing against PCI Requirement 11, there are five sub-requirements and controls which need to be reviewed:

• 11.1 – Wireless scanning
• 11.2 – Vulnerability scanning
• 11.3 – Penetration testing
• 11.4 – Intrusion detection/prevention systems (IDS/IPS)
• 11.5 – File-integrity monitoring

Each of these controls is not only vital for achieving PCI compliance but also for maintaining an adequate cybersecurity posture, as the processes and procedures outlined in Requirement 11 can help ensure the effectiveness of various security controls over time as new vulnerabilities and exploits are discovered.

Common Challenges:

11.1 – Wireless Scanning

PCI sub-requirement 11.1 deals with wireless access point (WAP/AP) scanning procedures. In order to meet and maintain compliance with this control, your organization should implement a quarterly process to identify unauthorized or rogue wireless access points in your physical environment and then respond appropriately. This requires an accurate and up-to-date inventory of authorized access points in use so that rogue or unauthorized APs can easily be identified. Scanning for wireless access points can be achieved through automated tools, or through manual methods such as performing a physical inspection of the in-scope location or environment. Even though a manual inspection for access points is appropriate for PCI compliance, an automated tool that can detect wireless networks in the area would strengthen your cybersecurity defenses even more.

11.2 – Vulnerability Scanning

Vulnerability scans are an essential process in identifying and exposing potential vulnerabilities that could be found and exploited by malicious actors. According to PCI DSS Requirement 11.2, there are three types of vulnerability scanning required:

• Quarterly Internal Vulnerability Scanning
• Quarterly External Vulnerability Scanning by an Approved Scanning Vendor (ASV)
• Internal and External Scanning following a Significant Change

Each of these is critical in ensuring all systems and devices within your environment remain secure as changes are made, and new vulnerabilities and exploits are discovered.

Equally as important as running the scans, is remediating the vulnerabilities that pose the greatest potential risk to the security of these systems or data within. If vulnerabilities are discovered, there needs to be processes in place to patch or remediate them, followed by additional scanning to ensure they are closed. Typically, assessors prefer to see evidence of “clean” quarterly scans, which not only show they are being performed but that any potential vulnerabilities identified have also been remediated.

Quarterly Internal Vulnerability Scanning

• In order to meet compliance requirements for PCI Requirement 11.2, vulnerability scanning must be performed for ALL internal systems, at least quarterly. Internal scans may be run by internal personnel or a third party and can be done with tools.
• As for remediation of findings, any “high risk” vulnerabilities must be remediated or resolved. The definition of “high risk” is up to the individual organization and the PCI DSS guidance for it is in section 6.1.
• One common issue we see with vulnerability scanning is clients who are unable to produce evidence of four “clean,” quarterly scans. If scans are run for all systems at the minimum frequency required and one is missed, you may find yourself lacking the appropriate evidence for next year’s PCI assessment. One recommendation we have is that you run scans on a higher frequency than once per quarter. If scans are run monthly, or even weekly if it suits the size of your environment, this not only gives you time to remediate vulnerabilities to ensure at least one clean scan per quarter, but it also provides better security posture overall. Additionally, it is not required that one vulnerability scan is run for all systems at once. If you find it more appropriate for your organization, scans can be performed in batches. You only need to ensure that each system in-scope is scanned at a minimum once per quarter.

Quarterly External Scanning by an Approved Scanning Vendor

• As external networks are at greater risk of compromise than internal networks, quarterly external vulnerability scanning must be performed by a PCI Approved Scanning Vendor (ASV). ASVs have already been certified by the PCI Security Standards Council to perform external vulnerability scans for the purposes of PCI assessments.
• With external scans, the DSS specifically requires that vulnerabilities with a CVSS score higher than a 4.0 be remediated. There are also particular vulnerabilities that are identified as “compliance impacting” which result in automatic failures, such as outdated versions of TLS being used. While these vulnerabilities may not have a CVSS score of at least 4.0, they are identified by the PCI Council as potentially posing a great risk or having a great adverse impact on the security of cardholder data. In fact, an ASV will not provide an attested, passing scan if any failing vulnerabilities present themselves. Typically, these vulnerabilities need to be remediated and then another scan will be run in order to obtain a “clean” report.

Internal and External Scanning following a Significant Change

• After a Significant Change is performed, all systems “affected by the change” must be scanned to ensure that any modifications or upgrades to in-scope systems did not adversely impact the security of the Cardholder Data Environment. That does not mean that only those systems changed need to be scanned – the standard states “affected by the change.” While for some changes, this might mean that only the systems on which the actual upgrade or modification was performed need to be scanned, for other changes, systems or devices connected to or integrated with those changed might also be impacted and would need to be scanned
• Regarding procedures for scanning following a Significant Change, they should follow the same scanning procedures as either the regular internal or external vulnerability scans, depending on the type of system that is changed. Significant Changes to internal systems can be followed by an internal vulnerability scan and can be performed by either an internal or external resource. Changes to external systems should be followed up with an external scan from an ASV.

11.3 – Penetration Testing

Penetration testing, like vulnerability scanning, must be performed for internal systems, external systems, and after any Significant Change. Barring Significant Changes to your environment, penetration tests, both internal and external, should be performed at least yearly for all in-scope systems. The purpose of a penetration test is to simulate a real-world scenario in which an attacker might attempt to gain access and penetrate into an environment. While vulnerability scanning might be included as a step in a penetration test, penetration testing is a more manual process. Vulnerability scanning only identifies potential vulnerabilities, while penetration testing typically involves chaining several exploits together in an attempt to break through network defenses. According to PCI DSS Requirement 11.3, there are four types of penetration testing-related controls:

• Annual Internal Penetration Testing
• Annual External Penetration Testing
• Internal and External Penetration Testing following a Significant Change
• Segmentation Testing

Each of these penetration tests is important for understanding the exploitable vulnerabilities and the attack vectors in which a real threat actor could compromise the Cardholder Data Environment. Remediation efforts must also be conducted for findings resulting from a penetration test and if necessary, re-testing to confirm the mitigation of risk or impact.

Annual Internal Penetration Testing

Penetration testing must be completed for internal systems at least annually. Like internal vulnerability scanning, internal penetration testing can be performed by a qualified internal resource: an internal employee who has the skills and knowledge to perform the test but also retains a certain level of organizational independence from their typical duties or responsibilities. For example, the owner of a device or system should not be the one to perform scanning or testing on that system.

Annual External Penetration Testing

Penetration testing of external systems must also be performed at least once per year. However, unlike external vulnerability scanning, an external penetration test CAN be performed by an internal resource. Again, they should have the knowledge and skills to perform penetration testing and should also maintain organizational independence.

Internal and External Penetration Testing following a Significant Change

The standard procedures for penetration testing internal and external systems should also be done after a Significant Change is performed in the environment. This ensures that any upgrades or modifications do not adversely impact the security of the in-scope systems or cardholder data environment.

Segmentation Testing

Segmentation testing is an aspect of penetration testing that is performed on environments that are segmented for the purpose of reducing the scope of a PCI assessment. While networks may be segmented for other reasons, the purpose of performing a segmentation test for PCI is to ensure that the segmentation controls have been properly implemented to isolate the Cardholder Data Environment from other in-scope or out-of-scope networks. This typically includes a review and testing of Access Control Lists or firewall rules to verify the absence of unnecessary connections between the CDE and other internal networks. Many times, segmentation controls are tested during an internal penetration test and must also be conducted at least yearly and after Significant Changes. Additionally, organizations designated as PCI Service Providers (meaning they are providing a product or service to other PCI-compliant entities) must test their segmentation controls an additional time per year, thus making the requirement for segmentation testing at least every 6 months for Service Providers.

11.4 Intrusion Detection/Prevention Systems (IDS/IPS)

Intrusion detection and/or prevention tools are important methods for monitoring and responding to potential intrusions on your network. Typically, this occurs as the IDS/IPS will compare network traffic to known signatures or behaviors and then either alert appropriate personnel (IDS) or stop the attempt as it happens (IPS). It is important to note that while a fully automated IPS may actually attempt to stop an intrusion, alerts should still be generated, and personnel notified so an internal resource may follow up on potential causes or lessons learned. For PCI Compliance, an IDS/IPS solution should be implemented at the perimeter and at critical points in the cardholder data environment, alert personnel of suspected compromises, and be regularly updated, maintained, and configured per vendor instructions to ensure optimal protection.

11.5 File-Integrity Monitoring (FIM)

PCI Requirement 11.5 deals with change detection. A change detection solution is important for PCI compliance, and good cybersecurity posture in general. It allows personnel to be informed and alerted to modifications of critical system, configuration, or content files. Unauthorized changes, such as those to configuration file contents, operating system programs, or application executable files, if undetected, could result in a compromise of cardholder data security without any noticeable impact on normal operations. It is imperative to implement a solution that not only monitors and compares critical files but also alerts personnel to potential unauthorized changes.

Common Questions

Our PCI environment is entirely hosted within the cloud or within a third-party data center. We have no physical locations in-scope for PCI, do we need to perform wireless scanning?

The requirements and controls regarding wireless access point scanning may not be applicable to every organization. For example, for entities hosting their entire PCI environment in a cloud service provider, such as AWS or Azure, this control is usually the responsibility of the cloud hosting provider. Even in a shared responsibility model, it is always an organization’s responsibility to ensure compliance is maintained for all controls. In order to do that, your respective service provider’s Attestation of Compliance (AOC) and/or Matrix of Responsibility (MOR) should be reviewed to verify that the controls regarding wireless scanning were covered under their assessment and are under their responsibility. With on-prem data centers, Requirement 11.1 might be the responsibility of the hosting organization, but they may also still place the responsibility on their customer to perform a wireless access point check for their systems within the data center. Again, it is imperative that their PCI documentation is reviewed to ensure the responsibilities for each control are fully understood by each party. If you are the owner, operator, or maintainer of the physical locations in-scope for PCI, then this requirement almost certainly falls under your responsibility.

What constitutes a “Significant Change”?

There is no specific metric or definition for a Significant Change that comes from the PCI Council or Standard. Sometimes, it can be a subjective decision based on the environment under assessment. In fact, the guidance for this control specifically says, “The determination of what constitutes a Significant Change is highly dependent on the configuration of a given environment. If an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment, then it could be considered significant.” For example, regular patching of systems and applications typically does not constitute a Significant Change. However, if you are performing an entire OS upgrade for a large number of servers, like updating web servers from Windows 2012R2 to 2016, or upgrading administrative workstations from Windows 10 to Windows 11, these could be considered Significant Changes. As another example, typically, replacing a server with one of the same OS, type, configurations, etc. may not be considered a Significant Change, but adding a new server that changes the data flow (which might involve new connections or routing rules to be established) may be considered a Significant Change. It is important to discuss modifications or upgrades to the environment with your assessor, so it can be ensured that you have all appropriate documentation and perform any necessary testing after Significant Changes.

How do I ensure my penetration testing methodology is appropriate?

When discussing vulnerability scanning and penetration testing, there are two types of testing: non-authenticated vs. authenticated testing. In a non-authenticated test, the tester does not have credentials to the target systems and performs either scanning or testing as a non-authenticated user. Vulnerability scans are typically a form of non-authenticated testing. The purpose of penetration testing is to simulate what a threat actor might be able to accomplish, should they gain access to any in-scope systems. Because of this, penetration testing should include authenticated testing methods, in which the tester gains credentials and is able to authenticate to a system or application within the environment.

What would I typically need to provide for Requirement 11 in a PCI assessment?

• Your organization should have policies and procedures implemented that outline security scanning and testing. They should accurately reflect your organization’s actual methods and standards and should be reviewed and updated at least annually.
• If wireless scanning falls under your responsibility, a list of authorized access points and documentation of actual efforts to identify rogue APs need to be kept (at least quarterly).
• You should have at least four internal vulnerability scans and four external ASV scans, as well as any documented remediation efforts (usually in the form of tickets) related to vulnerability mitigation.
• At least yearly penetration test reports are required to be reviewed for PCI compliance, so ensure those are conducted and remediation efforts documented. This includes annual (or bi-annual for Service Providers) segmentation testing results as well. The typical evidence for IDS/IPS and FIM is usually similar. As assessors, we would like to see various configurations for each of these solutions, including how it is deployed, monitoring rules or configurations, and evidence of alerts being generated to notify personnel. This is some of the documentation you should be thinking about and gathering for Requirement 11, should you consider undergoing a PCI assessment in the future.

Conclusion

Adequate security testing is crucial for not only maintaining compliance with PCI Requirement 11 but also for ensuring a good cybersecurity posture as systems and vulnerabilities change. Equally as important, is knowing what to do and how to respond to the valuable information that can come from regular security testing and monitoring. Having knowledgeable personnel with the appropriate tools and resources is imperative to the success of your organization’s security testing program. Implementing the controls in Requirement 11 regarding wireless and vulnerability scanning, penetration testing, and automatic monitoring tools can set you on the path toward PCI compliance and better overall security. While there may be many other security controls, tools, and/or processes in place, the regular testing of these methods is vital for ensuring the effectiveness of your cybersecurity program and identifying holes where more efforts might be needed.

CompliancePoint is a Qualified Security Assessor Company (QSAC). Our consultants have decades of experience as practitioners and auditors. Please reach out to us at connect@compliancepoint.com if you have any questions about this requirement or how CompliancePoint can assist your organization with preparing for your PCI DSS Certification. 

Check Out Other Posts in this Series

• PCI DSS Requirement 1: Install and maintain a firewall configuration to protect cardholder data
• PCI DSS Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• PCI DSS Requirement 3: Protect stored cardholder data
• PCI DSS Requirement 4: Encrypt transmission of cardholder data across open, public networks
• PCI DSS Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
• PCI DSS Requirement 6: Develop and maintain secure systems and applications
• PCI DSS Requirement 7: Restrict access to cardholder data by business need to know
• PCI DSS Requirement 8: Identify and authenticate access to system components
• PCI DSS Requirement 9: Restrict physical access to cardholder data
• PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data
• PCI DSS Requirement 11: Regularly Test Security Systems of Processes
• older data
• PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data
• PCI DSS Requirement 11: Regularly test security systems and processes
• PCI DSS Requirement 12: Maintain a policy that addresses information security for all personnel