Requirement 11: Test Security Regularly

Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

Requirement 11: Test Security Regularly

11.1 Processes And Mechanisms For Regularly Testing Security Of Systems And Networks Are Defined And Understood

11.1.1 All security policies and operational procedures are: • Documented • Kept up to date • In use • Known to all affected parties

It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle.

11.1.2 Roles and responsibilities for performing activities are documented, assigned, and understood

Roles and responsibilities may be documented within policies and procedures or maintained within separate documents.

As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities.

11.2 Wireless Access Points Are Identified And Monitored, And Unauthorized Wireless Access Points Are Addressed

11.2.1 Authorized and unauthorized wireless access points are managed as follows: • The presence of wireless (Wi-Fi) access points is tested for, • All authorized and unauthorized wireless access points are detected and identified, • Testing, detection, and identification occurs at least once every three months • If automated monitoring is used, personnel are notified via generated alerts

The size and complexity of an environment will dictate the appropriate tools and processes to be used to provide sufficient assurance that a rogue wireless access point has not been installed in the environment.

For example, performing a detailed physical inspection of a single stand-alone retail kiosk in a shopping mall, where all communication components are contained within tamper-resistant and tamper-evident casings, may be sufficient to provide assurance that a rogue wireless access point has not been attached or installed. However, in an environment with multiple nodes (such as in a large retail store, call center, server room or data center), detailed physical inspection can be difficult. In this case, multiple methods may be combined, such as performing physical system inspections in conjunction with the results of a wireless analyzer.

11.2.2 An inventory of authorized wireless access points is maintained, including a documented business justification

If using a wireless scanner, it is equally important to have a defined list of known access points which, while not attached to the company’s network, will usually be detected during a scan. These non-company devices are often found in multi-tenant buildings or businesses located near one another. However, it is important to verify that these devices are not connected to the entity’s network port or through another network-connected device and given an SSID resembling a nearby business. Scan results should note such devices and how it was determined that these devices could be “ignored.” In addition, detection of any unauthorized wireless access points that are determined to be a threat to the CDE should be managed following the entity’s incident response plan.

11.3 External And Internal Vulnerabilities Are Regularly Identified, Prioritized, And Addressed

11.3.1 Internal vulnerability scans are performed as follows: • At least once every three months • High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings) are resolved. • Rescans are performed that confirm all high-risk and critical vulnerabilities (as noted above) have been resolved • Scan tool is kept up to date with latest vulnerability information • Scans are performed by qualified personnel and organizational independence of the tester exists

Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical) should be resolved with the highest priority.

Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional, documentation may be required to verify non-remediated vulnerabilities are in the process of being resolved.

While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used.

11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings) are managed as follows: • Addressed based on the risk defined in the entity’s targeted risk analysis • Rescans are conducted as needed

All vulnerabilities, regardless of criticality, provide a potential avenue of attack and must therefore be addressed periodically, with the vulnerabilities that expose the most risk addressed more quickly to limit the potential window of attack.

11.3.1.2 Internal vulnerability scans are performed via authenticated scanning as follows: • Systems that are unable to accept credentials for authenticated scanning are documented • Sufficient privileges are used for those systems that accept credentials for scanning • If accounts used for authenticated scanning can be used for interactive login

The credentials used for these scans should be considered highly privileged. They should be protected and controlled as such.

11.3.1.3 Internal vulnerability scans are performed after any significant change as follows: • High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings) are resolved • Rescans are conducted as needed • Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV)

Entities should perform scans after significant changes as part of the change process and before considering the change complete. All system components affected by the change will need to be scanned.

11.3.2 External vulnerability scans are performed as follows: • At least once every three months • By a PCI SSC Approved Scanning Vendor (ASV) • Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met • Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan

While scans are required at least once every three months, more frequent scans are recommended depending on the network complexity, frequency of change, and types of devices, software, and operating systems used.

Multiple scan reports can be combined to show that all systems were scanned and that all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional documentation may be required to verify non-remediated vulnerabilities are in the process of being resolved.

11.3.2.1 External vulnerability scans are performed after any significant change as follows: • Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved • Rescans are conducted as needed • Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV)

Entities should include the need to perform scans after significant changes as part of the change process and before the change is considered complete. All system components affected by the change will need to be scanned.

11.4 External And Internal Penetration Testing Is Regularly Performed, And Exploitable Vulnerabilities And Security Weaknesses Are Corrected

11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity, and includes: • Industry-accepted penetration testing approaches • Coverage for the entire CDE perimeter and critical systems • Testing from both inside and outside the network • Testing to validate any segmentation and scope-reduction controls • Application-layer penetration testing to identify, at a minimum, the vulnerabilities • Network-layer penetration tests that encompass all components that support network functions as well as operating systems • Review and consideration of threats and vulnerabilities experienced in the last 12 months • Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing • Retention of penetration testing results and remediation activities results for at least 12 months

Penetration testing techniques will differ based on an organization’s needs and structure and should be suitable for the tested environment for example, fuzzing, injection, and forgery tests might be appropriate. The type, depth, and complexity of the testing will depend on the specific environment and the needs of the organization.

11.4.2 Internal penetration testing is performed: • Per the entity’s defined methodology, • At least once every 12 months • After any significant infrastructure or application upgrade or change • By a qualified internal resource or qualified external third-party • Organizational independence of the tester exists (not required to be a QSA or ASV)

Some considerations when choosing a qualified resource to perform penetration testing include:

Specific penetration testing certifications, which may be an indication of the tester’s skill level and competence.

Prior experience conducting penetration testingfor example, the number of years of experience, and the type and scope of prior engagements can help confirm whether the tester’s experience is appropriate for the needs of the engagement.

11.4.3 External penetration testing is performed: • Per the entity’s defined methodology • At least once every 12 months • After any significant infrastructure or application upgrade or change • By a qualified internal resource or qualified external third party • Organizational independence of the tester exists (not required to be a QSA or ASV)

Some considerations when choosing a qualified resource to perform penetration testing include:

Specific penetration testing certifications, which may be an indication of the tester’s skill level and competence.

Prior experience conducting penetration testingfor example, the number of years of experience, and the type and scope of prior engagements can help confirm whether the tester’s experience is appropriate for the needs of the engagement.

11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows: • In accordance with the entity’s assessment of the risk posed by the security issue • Penetration testing is repeated to verify the corrections

As part of the entity’s assessment of risk, entities should consider how likely the vulnerability is to be exploited and whether there are other controls present in the environment to reduce the risk.

Any weaknesses that point to PCI DSS requirements not being met should be addressed.

11.4.5 If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: • At least once every 12 months and after any changes to segmentation controls/methods • Covering all segmentation controls/methods in use • According to the entity’s defined penetration testing methodology • Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems • Confirming effectiveness of any use of isolation to separate systems with differing security levels. • Performed by a qualified internal resource or qualified external third party • Organizational independence of the tester exists (not required to be a QSA or ASV)

Techniques such as host discovery and port scanning can be used to verify out-of-scope segments have no access to the CDE.

11.4.6 Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: • At least once every six months and after any changes to segmentation controls/methods • Covering all segmentation controls/methods in use • According to the entity’s defined penetration testing methodology • Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems • Confirming effectiveness of any use of isolation to separate systems with differing security levels • Performed by a qualified internal resource or qualified external third party • Organizational independence of the tester exists (not required to be a QSA or ASV)

Although the requirement specifies that this scope validation is carried out at least once every six months and after significant change, this exercise should be performed as frequently as possible to ensure it remains effective at isolating the CDE from other networks.

11.4.7 Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing

Entities need to conduct penetration tests in accordance with PCI DSS to simulate attacker behavior and discover vulnerabilities in their environment. In shared and cloud environments, the multi-tenant service provider may be concerned about the activities of a penetration tester affecting other customers’ systems.

Multi-tenant service providers cannot forbid penetration testing because this would leave their customers’ systems open to exploitation. Therefore, multi-tenant service providers must support customer requests to conduct penetration testing or for penetration testing results.

11.5 Network Intrusions And Unexpected File Changes Are Detected And Responded To

11.5.1 Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent intrusions into the network as follows: • All traffic is monitored at the perimeter of the CDE • All traffic is monitored at critical points in the CDE • Personnel are alerted to suspected compromises • All intrusion-detection and prevention engines, baselines, and signatures are kept up to date

Security alerts generated by these techniques should be continually monitored, so that the attempted or actual intrusions can be stopped, and potential damage limited.

11.5.1.1 Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels

Methods that can help detect and address malware communications channels include real-time endpoint scanning, egress traffic filtering, an ”allow” listing, data loss prevention tools, and network security monitoring tools such as IDS/IPS. Additionally, DNS queries and responses are a key data source used by network defenders in support of incident response as well as intrusion discovery. When these transactions are collected for processing and analytics, they can enable a number of valuable security analytic scenarios.

It is important that organizations maintain up-to-date knowledge of malware modes of operation, as mitigating these can help detect and limit the impact of malware in the environment.

11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows: • To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files • To perform critical file comparisons at least once weekly

Examples of the types of files that should be monitored include, but are not limited to:

System executables.

Application executables.

Configuration and parameter files.

Centrally stored, historical, or archived audit logs.

Additional critical files determined by entity (for example, through risk assessment or other means).

11.6 Unauthorized Changes On Payment Pages Are Detected And Responded To

11.6.1 A change- and tamper-detection mechanism is deployed as follows: • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser • The mechanism is configured to evaluate the received HTTP header and payment page • The mechanism functions are performed as follows: – At least once every seven days OR – Periodically (at the frequency defined in the entity’s targeted risk analysis)

Many web pages now rely on assembling objects, including active content (primarily JavaScript), from multiple internet locations. Additionally, the content of many web pages is defined using content management and tag management systems that may not be possible to monitor using traditional change detection mechanisms.

Therefore, the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted.

By comparing the current version of the HTTP header and the active content of payment pages as received by the consumer browser with prior or known versions, it is possible to detect unauthorized changes that may indicate a skimming attack.

Additionally, by looking for known indicators of compromise and script elements or behavior typical of skimmers, suspicious alerts can be raised.

Let’s Understand With An Example

This image is borrowed from the Cybersecurity Labs. Assume it represents your work environment and cardholder data is sitting on the server dz-win10.

Requirement 11.1

It’s all about defining policies and procedures. Then, allocate the responsibilities.

Requirement 11.2

We don’t have wireless (Wi-Fi) access points in this example. Assume, we do have it, then it needs thorough testing at least once every three months.

Requirement 11.3 And 11.4

Internal/External vulnerability scans need to be performed at dsin-dangerzone at least once every three months. Also, internal/external penetration testing needs to be performed at least once every 12 months. The frequency should be increased to every six months if segmentation is used to isolate the CDE from other networks. It applies to our example because of segmentation (VLANs/virtualization).

Requirement 11.5 And 11.6

There are additional requirements for intrusion detection and/or intrusion prevention techniques. They are not covered in this example. The same for the tamper detection mechanisms.