PCI DSS Requirement 11: Test security systems and processes regularly.
Malicious people and security researchers are continually discovering vulnerabilities. Vulnerabilities exist in both old and new software.
System components, processes, and proprietary software should be tested frequently to ensure that security audits continue to reflect a changing and evolving environment.
The PCI DSS Requirement 11 relates to the regular testing of all system components that make up the cardholder data environment to ensure that the current environment remains secure.
Let’s take a look at the sub-requirements in PCI DSS requirement 11.
Applying and using wireless technologies on a network is one of the most common ways for malicious users to access network and cardholder data. If a wireless device or network is installed without the company’s knowledge, the attacker can easily and “invisibly” enter the network.
Unauthorized wireless devices may be hidden, connected or attached to a network port, such as a switch or router, directly on a network device, within a computer or other system component. Such unauthorized devices may create unauthorized access points in the environment.
Knowing that the wireless devices used or in the environment are authorized can help administrators quickly identify unauthorized wireless devices. In this way, preventing the identification of unauthorized wireless access points will help minimize the exposure of the cardholder environment to malicious people.
Such operations must be carried out even if it is a policy that prohibits the use of wireless technology. Because of the easiness of adding a wireless access point to the network, the difficulty in detecting the presence of unauthorized wireless devices and the risk posed by unauthorized wireless devices.
The size and complexity of a particular environment will determine the appropriate tools and procedures to be used to provide sufficient assurance that an unauthorized wireless access point has not been installed in the environment.
However, in a multi-location environment, the number of system components and network points where a rogue wireless access device can be installed or hidden will also be high. It will, therefore, be challenging to conduct a detailed physical examination.
In this case, multiple methods can be combined by performing physical system tests together with the results of a wireless analyzer to meet the requirements.
Network access control (NAC) solutions can perform device authentication and configuration management to prevent unauthorized systems to the network or unauthorized devices connected to authorized systems on the network.
A wireless IDS / IPS device can be configured to generate an alert when an unauthorized device is detected automatically.
Methods and processes that can be used include wireless network scanning, physical / logical control of system components and infrastructure, network access control (NAC) or wireless IDS / IPS.
- Whichever method is used, it must detect and identify both authorized and unauthorized wireless network devices.
- Processes should be defined quarterly to identify and locate both authorized and unauthorized wireless access points.
- Inventory of authorized wireless access points, including business justification, needs to be kept.
- In case unauthorized wireless access points are detected, incident response procedures should be established, and these procedures should be implemented in case of an incident.
PCI DSS Requirement 11.2: Perform internal and external network vulnerability scans at least every three months and after a significant change in the network.
Vulnerability scanning is a combination of automated or manual tools, techniques or methods designed to reveal possible vulnerabilities that can be found and used by malicious individuals, against external and internal network devices and servers.
Three types of vulnerability scans are required for PCI DSS:
- Quarterly internal network vulnerability testing by qualified personnel (no need to use PCI SSC Approved Scan Vendor – ASV)
- Quarterly external network vulnerability scan by PCI ASV
- Internal and external network vulnerability scanning that should be done after significant changes
Once vulnerabilities have been identified, vulnerabilities should be corrected and repeat the scan until all vulnerabilities have been fixed.
Timely identification and closure of vulnerabilities reduce the potential for attackers to exploit a vulnerability and to compromise a system component or cardholder data.
Multiple scan reports can be combined to demonstrate that all systems are scanned for quarterly, and all identified vulnerabilities are fixed. Additional documentation may be required to verify that uncorrected vulnerabilities are in the process of being resolved.
For the first PCI DSS compatibility,
- Verification that the most recent scan result is a pass scan
- An entity’s documentation of policies and procedures that require quarterly screening
- Vulnerabilities identified in the scan results should be corrected, as shown in the re-scans.
For years after the initial PCI DSS compliance audit, scans should occur four times a year, quarterly.
PCI DSS Requirement 11.2.1: Perform quarterly internal network vulnerability scans.
All “high risk” vulnerabilities should be closed, and scans should be done by checking that the vulnerability has been fixed.
A quarterly vulnerability scan is required in the process created to identify vulnerabilities in internal network systems.
Security vulnerabilities that pose the most significant risk to the environment should be addressed with the highest priority.
The scans carried out should be carried out by qualified personnel. Internal network vulnerability scans may be performed by an independent and qualified internal staff or by a company specializing in vulnerability scanning.
PCI DSS Requirement 11.2.2: Perform quarterly external network vulnerability scans through the Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Re-scan as needed until passing scans are obtained.
Quarterly external vulnerability scans should be performed by an Approved Scanning Vendor (ASV) certified by the Payment Card Industry Security Standards Council (PCI SSC).
Since external networks have a higher risk of being attacked, quarterly external vulnerability scanning should be performed by a PCI SSC Approved Scanning Vendor (ASV).
An effective scanning program ensures that scans are performed, and security vulnerabilities are addressed and handled promptly.
PCI DSS Requirement 11.2.3: Perform internal and external network scans after significant changes and re-scan if necessary.
Determining what makes a significant change depends to a large extent on the configuration of a particular environment. Upgrades or modifications may be considered vital if they allow access to cardholder data or affect the security of the cardholder data environment.
Scanning an environment after essential changes are made ensures that the changes are completed appropriately so that the security of the environment is not compromised. All system components affected by the change must be scanned. Also, scans should be done by a qualified staff or a company specialized in their field.
Among the scan result reports;
- For external scans, there should be no vulnerability rated by CVSS of 4.0 or higher.
- For internal scans, all “high risk” vulnerabilities identified in PCI DSS Requirement 6.1 must be addressed.
PCI DSS Requirement 11.3: Apply a methodology for penetration testing
The purpose of the penetration test is to simulate a real-world attack situation to determine how far an attacker can penetrate the environment. In this way, the company can better understand its potential risks and develop appropriate strategies to defend itself against attacks.
Penetration testing is different from scanning for vulnerabilities. Penetration testing is an efficient and manual process involving the exploitation of identified vulnerabilities.
A person performing a penetration test may perform a vulnerability scan to plan a penetration test strategy as a first step, but this is not the only and final step. Even if the vulnerability scan does not detect known vulnerabilities, the penetration tester will usually have enough system information to identify potential vulnerabilities after this test.
Penetration testing is usually a very manual process. While some automated tools can be used, the penetration tester uses system information to penetrate an environment. Usually, the penetration tester will use several types of attacking techniques to circumvent the defense layers.
For example, if a penetration tester finds a way to access an application server, it can use the compromised server as a hop to make a new attack based on the resources it can access. In this way, the penetration tester can simulate the methods used by the attacker to identify potential areas of weakness in the environment.
The methodology for penetration testing should cover the entire CDE environment and critical systems. Besides, penetration tests should be conducted inside and outside the network. If segmentation is used to reduce the PCI DSS scope, these controls should also be included in the penetration test.
The penetration test methodology also needs to cover the application and network layers and be done as part of its testing. Also, the organization should review the threats and vulnerabilities experienced in the past 12 months and be taken into account in the testing approach.
Penetration testing methodology should include:
- It should be based on penetration testing approaches accepted by the industry. (for example, NIST SP800-115)
- It should include the scope of all CDE media and critical systems.
- It should include tests performed inside and outside the network.
- It should include tests to verify segmentation and scope reduction controls.
- The application layer should include penetration tests that can detect vulnerabilities.
- It should include network-layer penetration tests to include operating systems as well as components that support network functions.
- It should include the review and assessment of threats and vulnerabilities experienced in the past 12 months.
- Penetration test results and improvement activities should be stated in the final report.
PCI DSS Requirement 11.3.1 1-3: Perform internal and external network penetration tests at least once a year and after significant infrastructure or application upgrades or changes.
Penetration testing, which will be carried out regularly and after significant changes to the environment, is a proactive security measure that helps minimize potential access to the cardholder data environment (CDE) of malicious individuals.
Determining what constitutes a significant upgrade or change depends mainly on the configuration of a particular environment. Upgrades or modifications may be considered vital if they allow access to cardholder data or affect the security of the cardholder data environment.
Performing penetration tests after network upgrades and modifications assure that the available default controls are still working effectively after upgrade or change.
The available vulnerabilities found during penetration tests should be corrected, and tests should be repeated to verify the corrections.
Penetration tests can be performed by a qualified internal source or a suitable external third party. The person conducting the test must have organizational independence. The person or firm performing the test does not need to be QSA or ASV.
PCI DSS Requirement 11.3.4: If segmentation is used to isolate CDE from other networks, run segmentation penetration tests at least once a year.
Penetration tests are an essential tool to verify that any segmentation used to isolate CDEs from other networks is effective.
Penetration tests should be carried out both outside and inside the enterprise network to verify that segmentation checks have been carried out to access the CDE.
For example, network testing or scanning of open ports can be performed to verify that there are no connections between in-scope and out-of-scope networks.
Segmentation tests should include:
- Penetration testing should be performed at least once a year to verify segmentation controls. Besides, penetration tests should be carried out after any change in segmentation controls/methods. Penetration tests should cover all segmentation controls/methods in use.
- Penetration tests should verify that segmentation controls/methods are operational and effective and verify that all systems out of scope are isolated from systems in the CDE.
PCI DSS Requirement 18.104.22.168: Additional requirement only for service providers: If segmentation is used, verify the scope of PCI DSS by penetration testing at least every six months and after any changes to segmentation controls/methods.
This requirement only applies when the assessed organization is a service provider.
For service providers, verification of PCI DSS scope and segmentation should be done as often as possible to ensure that PCI DSS scope remains up-to-date and complies with changing business objectives.
Segmentation and penetration tests to be performed should include the following items:
- Segmentation tests should be performed at least once every six months to verify segmentation checks and after any changes to segmentation checks/methods.
- Penetration testing should cover all segmentation controls/methods in use.
- Penetration testing should verify that segmentation controls/methods are operational and effective and verify that all systems out of scope are isolated from systems in the CDE.
PCI DSS Requirement 11.4: Use intrusion detection (IDS) or intrusion prevention (IPS) techniques to detect or prevent intrusions on the network.
All traffic in the cardholder data environment and critical points should be monitored. Using intrusion detection or intrusion prevention techniques (IDS / IPS), network traffic should be compared with known “signatures” or the behavior of the type of attack activity. Alerts should be sent to relevant personnel, or such harmful activities should be blocked automatically.
It is quite challenging to detect unauthorized activities and to detect attacks on computer resources in real-time without a proactive approach. Security warnings generated by these techniques are significant for blocking attacks, and these warnings should be carefully monitored. Appropriate personnel should be warned of suspicious activities.
The baselines and signatures of all intrusion detection and prevention engines must be kept up to date. Old signatures and scan engines on IDS / IPS devices will not have the ability to identify new vulnerabilities that could cause an undetected violation.
Critical points within the CDE may include database servers that store cardholder data, encryption key storage locations, processing networks, or other sensitive system components identified by the organization in risk assessments.
Change detection solutions, such as file integrity monitoring (FIM) tools, control changes, additions, and deletions of critical files and notify authorized personnel when these changes are detected.
Suppose the change detection solution is not configured correctly or its alerts are not checked. In that case, a malicious person can add, remove, or replace configuration files, operating system programs or application executables on the system.
If unauthorized changes are not detected, existing security controls may be disabled, or the cardholder data may be stolen.
Critical files that are monitored for change detection are generally files that do not change regularly but will be used to bypass the security of a system or leave it vulnerable if changed.
Change detection mechanisms, such as file integrity monitoring products, usually come pre-configured with critical files defined for that operating system. Critical files for special applications should be evaluated and identified by the manufacturer or delivery provider.
Change detection tools should be configured to perform a file comparison check at least once a week and alert staff to make unauthorized changes to critical files. Besides, a process should be created for the personnel to respond to the warnings generated.
Also, a process must be created to respond to alerts generated by change detection mechanisms.
The file examples that should be monitored by the change detection solution are as follows:
- System executable files
- Application executable files
- Configuration and parameter files
- Centrally stored, past or archived, log and audit files
- Additional critical files determined by the organization
PCI DSS Requirement 11.6: Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties.
Staff need to know and follow security policies and operational procedures for continuous security monitoring and testing.
For detailed information, see the PCI DSS Quick Reference Guide from the PCI SSC Documentation library.