SAMMY works best on screens 1024px wide or larger.
11.1: All security policies and operational procedures that are identified in Requirement 11 are: (a) Documented, (b) Kept up to date, (c) In use, (d) Known to all affected parties.
  • Examine documentation and interview personnel to verify that security policies and operational procedures are managed in accordance with all elements specified in this requirement.
Description

Requirement 11.1.1

Purpose

Requirement 11.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 11. While it is important to define the specific policies or procedures called out in Requirement 11, it is equally important to ensure they are properly documented, maintained, and disseminated.

Good Practice

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

Definitions

Security policies define the entity's security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives.

Requirement 11.1.2

Purpose

If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities and critical activities may not occur.

Good Practice

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.

Examples

A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix).

11.1: Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood.
  • Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 11 are documented and assigned.
  • Interview personnel with responsibility for performing activities in Requirement 11 to verify that roles and responsibilities are assigned as documented and are understood.
Description

Requirement 11.1.1

Purpose

Requirement 11.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 11. While it is important to define the specific policies or procedures called out in Requirement 11, it is equally important to ensure they are properly documented, maintained, and disseminated.

Good Practice

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

Definitions

Security policies define the entity's security objectives and principles. Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives.

Requirement 11.1.2

Purpose

If roles and responsibilities are not formally assigned, personnel may not be aware of their day-to-day responsibilities and critical activities may not occur.

Good Practice

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.

Examples

A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix).

11.2: Authorized and unauthorized wireless access points are managed as follows: (a) The presence of wireless (Wi-Fi) access points is tested for,, (b) All authorized and unauthorized wireless access points are detected and identified,, (c) Testing, detection, and identification occurs at least once every three months, (d) If automated monitoring is used, personnel are notified via generated alerts.
  • Examine policies and procedures to verify processes are defined for managing both authorized and unauthorized wireless access points with all elements specified in this requirement.
  • Examine the methodology(ies) in use and the resulting documentation, and interview personnel to verify processes are defined to detect and identify both authorized and unauthorized wireless access points in accordance with all elements specified in this requirement.
  • Examine wireless assessment results and interview personnel to verify that wireless assessments were conducted in accordance with all elements specified in this requirement.
  • If automated monitoring is used, examine configuration settings to verify the configuration will generate alerts to notify personnel.
Description

Requirement 11.2.1

Purpose

Unauthorized wireless access points connected to the network can provide an uncontrolled entry point for attackers. Detecting authorized and unauthorized wireless access points helps ensure that only approved wireless devices are present in the environment.

Good Practice

Wireless scans should be performed at least quarterly to identify all wireless access points within range of the facility. Automated tools can help detect rogue wireless devices continuously.

Examples

Methods for detecting unauthorized wireless access points include wireless network scans using a wireless analyzer, physical/logical inspection of system components and infrastructure, and network access control (NAC) solutions.

Requirement 11.2.2

Purpose

Maintaining an inventory of authorized wireless access points helps in identifying unauthorized devices. Without a current inventory, it may be difficult to distinguish between authorized and unauthorized access points.

Good Practice

The inventory should include the make, model, location, and responsible individual for each authorized wireless access point. The inventory should be updated whenever access points are added, removed, or relocated.

11.2: An inventory of authorized wireless access points is maintained, including a documented business justification.
  • Examine documentation to verify that an inventory of authorized wireless access points is maintained, and a business justification is documented for all authorized wireless access points.
Description

Requirement 11.2.1

Purpose

Unauthorized wireless access points connected to the network can provide an uncontrolled entry point for attackers. Detecting authorized and unauthorized wireless access points helps ensure that only approved wireless devices are present in the environment.

Good Practice

Wireless scans should be performed at least quarterly to identify all wireless access points within range of the facility. Automated tools can help detect rogue wireless devices continuously.

Examples

Methods for detecting unauthorized wireless access points include wireless network scans using a wireless analyzer, physical/logical inspection of system components and infrastructure, and network access control (NAC) solutions.

Requirement 11.2.2

Purpose

Maintaining an inventory of authorized wireless access points helps in identifying unauthorized devices. Without a current inventory, it may be difficult to distinguish between authorized and unauthorized access points.

Good Practice

The inventory should include the make, model, location, and responsible individual for each authorized wireless access point. The inventory should be updated whenever access points are added, removed, or relocated.

11.3: Internal vulnerability scans are performed as follows: (a) At least once every three months, (b) Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved, (c) Rescans are performed that confirm all high-risk and all critical vulnerabilities (as noted above) have been resolved, (d) Scan tool is kept up to date with latest vulnerability information, (e) Scans are performed by qualified personnel and organizational independence of the tester exists.
  • Examine internal scan report results from the last 12 months to verify that internal scans occurred at least once every three months in the most recent 12-month period.
  • Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk vulnerabilities and all critical vulnerabilities (defined in PCI DSS Requirement 6.3.1) are resolved.
  • Examine scan tool configurations and interview personnel to verify that the scan tool is kept up to date with the latest vulnerability information.
  • Interview responsible personnel to verify that the scan was performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.
Description

Requirement 11.3.1

Purpose

Internal vulnerability scans help identify known vulnerabilities in system components before they can be exploited by attackers. Regular scanning helps ensure that new vulnerabilities are detected and addressed promptly.

Good Practice

Internal vulnerability scans should be performed at least quarterly and after any significant change. Scans should cover all system components in the CDE and systems that could affect the security of the CDE. All high-risk vulnerabilities should be resolved and rescans performed to verify remediation.

Requirement 11.3.1.1

Purpose

Internal vulnerability scans may identify vulnerabilities of varying severity. Managing all vulnerabilities, not just critical ones, helps reduce the overall risk to the environment.

Good Practice

All vulnerabilities identified during scans should be managed based on their risk level. High-risk and critical vulnerabilities should be addressed first, with a plan for addressing lower-risk vulnerabilities in a reasonable timeframe.

Requirement 11.3.1.2

Purpose

Internal scans performed after significant changes help verify that the changes have not introduced new vulnerabilities. Without post-change scans, vulnerabilities introduced by changes may go undetected.

Good Practice

Scans should be performed after any significant change, such as new system component installations, network topology changes, firewall rule modifications, or product upgrades. Identified vulnerabilities should be remediated promptly.

Requirement 11.3.1.3

Purpose

Rescanning after remediation verifies that vulnerabilities have been successfully addressed. Without rescans, there is no assurance that the remediation was effective.

Good Practice

Rescans should be performed until all high-risk vulnerabilities are resolved. The rescan results should be documented and retained as evidence of remediation.

Requirement 11.3.2

Purpose

External vulnerability scans help identify vulnerabilities that are visible from outside the network boundary. These vulnerabilities could be exploited by attackers to gain unauthorized access to the CDE.

Good Practice

External vulnerability scans should be performed at least quarterly and after any significant change by a PCI SSC Approved Scanning Vendor (ASV). All vulnerabilities that score 4.0 or higher on the CVSS scale should be resolved and rescanned.

Requirement 11.3.2.1

Purpose

External scans performed after significant changes help verify that the changes have not introduced externally visible vulnerabilities. Without post-change scans, new vulnerabilities may go undetected.

Good Practice

External scans should be performed after significant changes that affect externally facing systems. Scans should be performed by a qualified ASV and should be completed with a passing result.

11.3: All other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows: (a) Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1, (b) Rescans are conducted as needed.
  • Examine the entity’s targeted risk analysis that defines the risk for addressing all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings at Requirement 6.3.1) to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1.
  • Interview responsible personnel and examine internal scan report results or other documentation to verify that all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings at Requirement 6.3.1) are addressed based on the risk defined in the entity’s targeted risk analysis, and that the scan process includes rescans as needed to confirm the vulnerabilities have been addressed.
Description

Requirement 11.3.1

Purpose

Internal vulnerability scans help identify known vulnerabilities in system components before they can be exploited by attackers. Regular scanning helps ensure that new vulnerabilities are detected and addressed promptly.

Good Practice

Internal vulnerability scans should be performed at least quarterly and after any significant change. Scans should cover all system components in the CDE and systems that could affect the security of the CDE. All high-risk vulnerabilities should be resolved and rescans performed to verify remediation.

Requirement 11.3.1.1

Purpose

Internal vulnerability scans may identify vulnerabilities of varying severity. Managing all vulnerabilities, not just critical ones, helps reduce the overall risk to the environment.

Good Practice

All vulnerabilities identified during scans should be managed based on their risk level. High-risk and critical vulnerabilities should be addressed first, with a plan for addressing lower-risk vulnerabilities in a reasonable timeframe.

Requirement 11.3.1.2

Purpose

Internal scans performed after significant changes help verify that the changes have not introduced new vulnerabilities. Without post-change scans, vulnerabilities introduced by changes may go undetected.

Good Practice

Scans should be performed after any significant change, such as new system component installations, network topology changes, firewall rule modifications, or product upgrades. Identified vulnerabilities should be remediated promptly.

Requirement 11.3.1.3

Purpose

Rescanning after remediation verifies that vulnerabilities have been successfully addressed. Without rescans, there is no assurance that the remediation was effective.

Good Practice

Rescans should be performed until all high-risk vulnerabilities are resolved. The rescan results should be documented and retained as evidence of remediation.

Requirement 11.3.2

Purpose

External vulnerability scans help identify vulnerabilities that are visible from outside the network boundary. These vulnerabilities could be exploited by attackers to gain unauthorized access to the CDE.

Good Practice

External vulnerability scans should be performed at least quarterly and after any significant change by a PCI SSC Approved Scanning Vendor (ASV). All vulnerabilities that score 4.0 or higher on the CVSS scale should be resolved and rescanned.

Requirement 11.3.2.1

Purpose

External scans performed after significant changes help verify that the changes have not introduced externally visible vulnerabilities. Without post-change scans, new vulnerabilities may go undetected.

Good Practice

External scans should be performed after significant changes that affect externally facing systems. Scans should be performed by a qualified ASV and should be completed with a passing result.

11.3: Internal vulnerability scans are performed via authenticated scanning as follows: (a) Systems that are unable to accept credentials for authenticated scanning are documented, (b) Sufficient privileges are used for those systems that accept credentials for scanning, (c) If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2.
  • Examine scan tool configurations to verify that authenticated scanning is used for internal scans, with sufficient privileges, for those systems that accept credentials for scanning.
  • Examine scan report results and interview personnel to verify that authenticated scans are performed.
  • If accounts used for authenticated scanning can be used for interactive login, examine the accounts and interview personnel to verify the accounts are managed following all elements specified in Requirement 8.2.2.
  • Examine documentation to verify that systems that are unable to accept credentials for authenticated scanning are defined.
Description

Requirement 11.3.1

Purpose

Internal vulnerability scans help identify known vulnerabilities in system components before they can be exploited by attackers. Regular scanning helps ensure that new vulnerabilities are detected and addressed promptly.

Good Practice

Internal vulnerability scans should be performed at least quarterly and after any significant change. Scans should cover all system components in the CDE and systems that could affect the security of the CDE. All high-risk vulnerabilities should be resolved and rescans performed to verify remediation.

Requirement 11.3.1.1

Purpose

Internal vulnerability scans may identify vulnerabilities of varying severity. Managing all vulnerabilities, not just critical ones, helps reduce the overall risk to the environment.

Good Practice

All vulnerabilities identified during scans should be managed based on their risk level. High-risk and critical vulnerabilities should be addressed first, with a plan for addressing lower-risk vulnerabilities in a reasonable timeframe.

Requirement 11.3.1.2

Purpose

Internal scans performed after significant changes help verify that the changes have not introduced new vulnerabilities. Without post-change scans, vulnerabilities introduced by changes may go undetected.

Good Practice

Scans should be performed after any significant change, such as new system component installations, network topology changes, firewall rule modifications, or product upgrades. Identified vulnerabilities should be remediated promptly.

Requirement 11.3.1.3

Purpose

Rescanning after remediation verifies that vulnerabilities have been successfully addressed. Without rescans, there is no assurance that the remediation was effective.

Good Practice

Rescans should be performed until all high-risk vulnerabilities are resolved. The rescan results should be documented and retained as evidence of remediation.

Requirement 11.3.2

Purpose

External vulnerability scans help identify vulnerabilities that are visible from outside the network boundary. These vulnerabilities could be exploited by attackers to gain unauthorized access to the CDE.

Good Practice

External vulnerability scans should be performed at least quarterly and after any significant change by a PCI SSC Approved Scanning Vendor (ASV). All vulnerabilities that score 4.0 or higher on the CVSS scale should be resolved and rescanned.

Requirement 11.3.2.1

Purpose

External scans performed after significant changes help verify that the changes have not introduced externally visible vulnerabilities. Without post-change scans, new vulnerabilities may go undetected.

Good Practice

External scans should be performed after significant changes that affect externally facing systems. Scans should be performed by a qualified ASV and should be completed with a passing result.

11.3: Internal vulnerability scans are performed after any significant change as follows: (a) Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved, (b) Rescans are conducted as needed, (c) Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
  • Examine change control documentation and internal scan reports to verify that system components were scanned after any significant changes.
  • Interview personnel and examine internal scan and rescan reports to verify that internal scans were performed after significant changes and that all high-risk vulnerabilities and all critical vulnerabilities (defined in PCI DSS Requirement 6.3.1) were resolved.
  • Interview personnel to verify that internal scans are performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.
Description

Requirement 11.3.1

Purpose

Internal vulnerability scans help identify known vulnerabilities in system components before they can be exploited by attackers. Regular scanning helps ensure that new vulnerabilities are detected and addressed promptly.

Good Practice

Internal vulnerability scans should be performed at least quarterly and after any significant change. Scans should cover all system components in the CDE and systems that could affect the security of the CDE. All high-risk vulnerabilities should be resolved and rescans performed to verify remediation.

Requirement 11.3.1.1

Purpose

Internal vulnerability scans may identify vulnerabilities of varying severity. Managing all vulnerabilities, not just critical ones, helps reduce the overall risk to the environment.

Good Practice

All vulnerabilities identified during scans should be managed based on their risk level. High-risk and critical vulnerabilities should be addressed first, with a plan for addressing lower-risk vulnerabilities in a reasonable timeframe.

Requirement 11.3.1.2

Purpose

Internal scans performed after significant changes help verify that the changes have not introduced new vulnerabilities. Without post-change scans, vulnerabilities introduced by changes may go undetected.

Good Practice

Scans should be performed after any significant change, such as new system component installations, network topology changes, firewall rule modifications, or product upgrades. Identified vulnerabilities should be remediated promptly.

Requirement 11.3.1.3

Purpose

Rescanning after remediation verifies that vulnerabilities have been successfully addressed. Without rescans, there is no assurance that the remediation was effective.

Good Practice

Rescans should be performed until all high-risk vulnerabilities are resolved. The rescan results should be documented and retained as evidence of remediation.

Requirement 11.3.2

Purpose

External vulnerability scans help identify vulnerabilities that are visible from outside the network boundary. These vulnerabilities could be exploited by attackers to gain unauthorized access to the CDE.

Good Practice

External vulnerability scans should be performed at least quarterly and after any significant change by a PCI SSC Approved Scanning Vendor (ASV). All vulnerabilities that score 4.0 or higher on the CVSS scale should be resolved and rescanned.

Requirement 11.3.2.1

Purpose

External scans performed after significant changes help verify that the changes have not introduced externally visible vulnerabilities. Without post-change scans, new vulnerabilities may go undetected.

Good Practice

External scans should be performed after significant changes that affect externally facing systems. Scans should be performed by a qualified ASV and should be completed with a passing result.

11.3: External vulnerability scans are performed as follows: (a) At least once every three months, (b) By a PCI SSC Approved Scanning Vendor (ASV), (c) Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met, (d) Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.
  • Examine ASV scan reports from the last 12 months to verify that external vulnerability scans occurred at least once every three months in the most recent 12-month period.
  • Examine the ASV scan report from each scan and rescan run in the last 12 months to verify that vulnerabilities are resolved and the ASV Program Guide requirements for a passing scan are met.
  • Examine the ASV scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV).
Description

Requirement 11.3.1

Purpose

Internal vulnerability scans help identify known vulnerabilities in system components before they can be exploited by attackers. Regular scanning helps ensure that new vulnerabilities are detected and addressed promptly.

Good Practice

Internal vulnerability scans should be performed at least quarterly and after any significant change. Scans should cover all system components in the CDE and systems that could affect the security of the CDE. All high-risk vulnerabilities should be resolved and rescans performed to verify remediation.

Requirement 11.3.1.1

Purpose

Internal vulnerability scans may identify vulnerabilities of varying severity. Managing all vulnerabilities, not just critical ones, helps reduce the overall risk to the environment.

Good Practice

All vulnerabilities identified during scans should be managed based on their risk level. High-risk and critical vulnerabilities should be addressed first, with a plan for addressing lower-risk vulnerabilities in a reasonable timeframe.

Requirement 11.3.1.2

Purpose

Internal scans performed after significant changes help verify that the changes have not introduced new vulnerabilities. Without post-change scans, vulnerabilities introduced by changes may go undetected.

Good Practice

Scans should be performed after any significant change, such as new system component installations, network topology changes, firewall rule modifications, or product upgrades. Identified vulnerabilities should be remediated promptly.

Requirement 11.3.1.3

Purpose

Rescanning after remediation verifies that vulnerabilities have been successfully addressed. Without rescans, there is no assurance that the remediation was effective.

Good Practice

Rescans should be performed until all high-risk vulnerabilities are resolved. The rescan results should be documented and retained as evidence of remediation.

Requirement 11.3.2

Purpose

External vulnerability scans help identify vulnerabilities that are visible from outside the network boundary. These vulnerabilities could be exploited by attackers to gain unauthorized access to the CDE.

Good Practice

External vulnerability scans should be performed at least quarterly and after any significant change by a PCI SSC Approved Scanning Vendor (ASV). All vulnerabilities that score 4.0 or higher on the CVSS scale should be resolved and rescanned.

Requirement 11.3.2.1

Purpose

External scans performed after significant changes help verify that the changes have not introduced externally visible vulnerabilities. Without post-change scans, new vulnerabilities may go undetected.

Good Practice

External scans should be performed after significant changes that affect externally facing systems. Scans should be performed by a qualified ASV and should be completed with a passing result.

11.3: External vulnerability scans are performed after any significant change as follows: (a) Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved, (b) Rescans are conducted as needed, (c) Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
  • Examine change control documentation and external scan reports to verify that system components were scanned after any significant changes.
  • Interview personnel and examine external scan and rescan reports to verify that external scans were performed after significant changes and that vulnerabilities scored 4.0 or higher by the CVSS were resolved.
  • Interview personnel to verify that external scans are performed by a qualified internal resource(s) or qualified external third party and that organizational independence of the tester exists.
Description

Requirement 11.3.1

Purpose

Internal vulnerability scans help identify known vulnerabilities in system components before they can be exploited by attackers. Regular scanning helps ensure that new vulnerabilities are detected and addressed promptly.

Good Practice

Internal vulnerability scans should be performed at least quarterly and after any significant change. Scans should cover all system components in the CDE and systems that could affect the security of the CDE. All high-risk vulnerabilities should be resolved and rescans performed to verify remediation.

Requirement 11.3.1.1

Purpose

Internal vulnerability scans may identify vulnerabilities of varying severity. Managing all vulnerabilities, not just critical ones, helps reduce the overall risk to the environment.

Good Practice

All vulnerabilities identified during scans should be managed based on their risk level. High-risk and critical vulnerabilities should be addressed first, with a plan for addressing lower-risk vulnerabilities in a reasonable timeframe.

Requirement 11.3.1.2

Purpose

Internal scans performed after significant changes help verify that the changes have not introduced new vulnerabilities. Without post-change scans, vulnerabilities introduced by changes may go undetected.

Good Practice

Scans should be performed after any significant change, such as new system component installations, network topology changes, firewall rule modifications, or product upgrades. Identified vulnerabilities should be remediated promptly.

Requirement 11.3.1.3

Purpose

Rescanning after remediation verifies that vulnerabilities have been successfully addressed. Without rescans, there is no assurance that the remediation was effective.

Good Practice

Rescans should be performed until all high-risk vulnerabilities are resolved. The rescan results should be documented and retained as evidence of remediation.

Requirement 11.3.2

Purpose

External vulnerability scans help identify vulnerabilities that are visible from outside the network boundary. These vulnerabilities could be exploited by attackers to gain unauthorized access to the CDE.

Good Practice

External vulnerability scans should be performed at least quarterly and after any significant change by a PCI SSC Approved Scanning Vendor (ASV). All vulnerabilities that score 4.0 or higher on the CVSS scale should be resolved and rescanned.

Requirement 11.3.2.1

Purpose

External scans performed after significant changes help verify that the changes have not introduced externally visible vulnerabilities. Without post-change scans, new vulnerabilities may go undetected.

Good Practice

External scans should be performed after significant changes that affect externally facing systems. Scans should be performed by a qualified ASV and should be completed with a passing result.

11.4: A penetration testing methodology is defined, documented, and implemented by the entity, and includes: (a) Industry-accepted penetration testing approaches, (b) Coverage for the entire CDE perimeter and critical systems, (c) Testing from both inside and outside the network, (d) Testing to validate any segmentation and scope- reduction controls, (e) Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4, (f) Network-layer penetration tests that encompass all components that support network functions as well as operating systems, (g) Review and consideration of threats and vulnerabilities experienced in the last 12 months, (h) Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing, (i) Retention of penetration testing results and remediation activities results for at least 12 months.
  • Examine documentation and interview personnel to verify that the penetration-testing methodology defined, documented, and implemented by the entity includes all elements specified in this requirement.
Description

Requirement 11.4.1

Purpose

A penetration testing methodology ensures that penetration tests are comprehensive, consistent, and repeatable. Without a defined methodology, tests may miss critical vulnerabilities or provide inconsistent results.

Good Practice

The methodology should define the scope, approach, and reporting requirements for penetration tests. It should be based on industry-accepted approaches such as NIST SP 800-115, OWASP Testing Guide, or PTES.

Requirement 11.4.2

Purpose

Internal penetration testing helps identify vulnerabilities that could be exploited by an insider or by an attacker who has gained access to the internal network. Internal tests complement vulnerability scans by testing for exploitability.

Good Practice

Internal penetration tests should be performed at least annually and after any significant changes to the infrastructure, applications, or network. Tests should attempt to exploit identified vulnerabilities to determine the potential impact.

Requirement 11.4.3

Purpose

External penetration testing helps identify vulnerabilities in externally facing systems that could be exploited by attackers from outside the network. External tests simulate real-world attack scenarios.

Good Practice

External penetration tests should be performed at least annually and after any significant changes to externally facing systems. Tests should be performed by qualified, experienced testers who are organizationally independent of the environment being tested.

Requirement 11.4.4

Purpose

Exploitable vulnerabilities discovered during penetration testing represent real risks to the environment. Correcting these vulnerabilities and retesting ensures that the risks have been effectively mitigated.

Good Practice

All exploitable vulnerabilities found during penetration testing should be corrected and the corrections verified through retesting. The retesting should confirm that the vulnerabilities can no longer be exploited.

Requirement 11.4.5

Purpose

If network segmentation is used to reduce the scope of the CDE, the effectiveness of that segmentation must be verified. If segmentation controls fail, the entire network may need to be considered in scope for PCI DSS.

Good Practice

Segmentation penetration tests should verify that segmentation controls effectively isolate the CDE from out-of-scope networks. Tests should be performed at least annually and after any changes to segmentation controls.

Requirement 11.4.6

Purpose

Service providers face unique risks due to the volume of cardholder data they handle and the number of clients they support. More frequent segmentation testing helps ensure that segmentation controls remain effective.

Good Practice

Service providers should perform segmentation penetration testing at least every six months and after any significant changes to segmentation controls or methods. Results should be documented and any issues remediated promptly.

Requirement 11.4.7

Purpose

Multi-tenant service providers must ensure that their segmentation controls effectively isolate each customer's data and environment. Without effective segmentation, one customer's data could be accessible from another customer's environment.

Good Practice

Multi-tenant service providers should test segmentation controls between customer environments. Tests should verify that one customer cannot access another customer's cardholder data or environment.

11.4: Internal penetration testing is performed: (a) Per the entity’s defined methodology,, (b) At least once every 12 months, (c) After any significant infrastructure or application upgrade or change, (d) By a qualified internal resource or qualified external third-party, (e) Organizational independence of the tester exists (not required to be a QSA or ASV).
  • Examine the scope of work and results from the most recent internal penetration test to verify that penetration testing is performed in accordance with all elements specified in this requirement.
  • Interview personnel to verify that the internal penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Description

Requirement 11.4.1

Purpose

A penetration testing methodology ensures that penetration tests are comprehensive, consistent, and repeatable. Without a defined methodology, tests may miss critical vulnerabilities or provide inconsistent results.

Good Practice

The methodology should define the scope, approach, and reporting requirements for penetration tests. It should be based on industry-accepted approaches such as NIST SP 800-115, OWASP Testing Guide, or PTES.

Requirement 11.4.2

Purpose

Internal penetration testing helps identify vulnerabilities that could be exploited by an insider or by an attacker who has gained access to the internal network. Internal tests complement vulnerability scans by testing for exploitability.

Good Practice

Internal penetration tests should be performed at least annually and after any significant changes to the infrastructure, applications, or network. Tests should attempt to exploit identified vulnerabilities to determine the potential impact.

Requirement 11.4.3

Purpose

External penetration testing helps identify vulnerabilities in externally facing systems that could be exploited by attackers from outside the network. External tests simulate real-world attack scenarios.

Good Practice

External penetration tests should be performed at least annually and after any significant changes to externally facing systems. Tests should be performed by qualified, experienced testers who are organizationally independent of the environment being tested.

Requirement 11.4.4

Purpose

Exploitable vulnerabilities discovered during penetration testing represent real risks to the environment. Correcting these vulnerabilities and retesting ensures that the risks have been effectively mitigated.

Good Practice

All exploitable vulnerabilities found during penetration testing should be corrected and the corrections verified through retesting. The retesting should confirm that the vulnerabilities can no longer be exploited.

Requirement 11.4.5

Purpose

If network segmentation is used to reduce the scope of the CDE, the effectiveness of that segmentation must be verified. If segmentation controls fail, the entire network may need to be considered in scope for PCI DSS.

Good Practice

Segmentation penetration tests should verify that segmentation controls effectively isolate the CDE from out-of-scope networks. Tests should be performed at least annually and after any changes to segmentation controls.

Requirement 11.4.6

Purpose

Service providers face unique risks due to the volume of cardholder data they handle and the number of clients they support. More frequent segmentation testing helps ensure that segmentation controls remain effective.

Good Practice

Service providers should perform segmentation penetration testing at least every six months and after any significant changes to segmentation controls or methods. Results should be documented and any issues remediated promptly.

Requirement 11.4.7

Purpose

Multi-tenant service providers must ensure that their segmentation controls effectively isolate each customer's data and environment. Without effective segmentation, one customer's data could be accessible from another customer's environment.

Good Practice

Multi-tenant service providers should test segmentation controls between customer environments. Tests should verify that one customer cannot access another customer's cardholder data or environment.

11.4: External penetration testing is performed: (a) Per the entity’s defined methodology, (b) At least once every 12 months, (c) After any significant infrastructure or application upgrade or change, (d) By a qualified internal resource or qualified external third party, (e) Organizational independence of the tester exists (not required to be a QSA or ASV).
  • Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed according to all elements specified in this requirement.
  • Interview personnel to verify that the external penetration test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Description

Requirement 11.4.1

Purpose

A penetration testing methodology ensures that penetration tests are comprehensive, consistent, and repeatable. Without a defined methodology, tests may miss critical vulnerabilities or provide inconsistent results.

Good Practice

The methodology should define the scope, approach, and reporting requirements for penetration tests. It should be based on industry-accepted approaches such as NIST SP 800-115, OWASP Testing Guide, or PTES.

Requirement 11.4.2

Purpose

Internal penetration testing helps identify vulnerabilities that could be exploited by an insider or by an attacker who has gained access to the internal network. Internal tests complement vulnerability scans by testing for exploitability.

Good Practice

Internal penetration tests should be performed at least annually and after any significant changes to the infrastructure, applications, or network. Tests should attempt to exploit identified vulnerabilities to determine the potential impact.

Requirement 11.4.3

Purpose

External penetration testing helps identify vulnerabilities in externally facing systems that could be exploited by attackers from outside the network. External tests simulate real-world attack scenarios.

Good Practice

External penetration tests should be performed at least annually and after any significant changes to externally facing systems. Tests should be performed by qualified, experienced testers who are organizationally independent of the environment being tested.

Requirement 11.4.4

Purpose

Exploitable vulnerabilities discovered during penetration testing represent real risks to the environment. Correcting these vulnerabilities and retesting ensures that the risks have been effectively mitigated.

Good Practice

All exploitable vulnerabilities found during penetration testing should be corrected and the corrections verified through retesting. The retesting should confirm that the vulnerabilities can no longer be exploited.

Requirement 11.4.5

Purpose

If network segmentation is used to reduce the scope of the CDE, the effectiveness of that segmentation must be verified. If segmentation controls fail, the entire network may need to be considered in scope for PCI DSS.

Good Practice

Segmentation penetration tests should verify that segmentation controls effectively isolate the CDE from out-of-scope networks. Tests should be performed at least annually and after any changes to segmentation controls.

Requirement 11.4.6

Purpose

Service providers face unique risks due to the volume of cardholder data they handle and the number of clients they support. More frequent segmentation testing helps ensure that segmentation controls remain effective.

Good Practice

Service providers should perform segmentation penetration testing at least every six months and after any significant changes to segmentation controls or methods. Results should be documented and any issues remediated promptly.

Requirement 11.4.7

Purpose

Multi-tenant service providers must ensure that their segmentation controls effectively isolate each customer's data and environment. Without effective segmentation, one customer's data could be accessible from another customer's environment.

Good Practice

Multi-tenant service providers should test segmentation controls between customer environments. Tests should verify that one customer cannot access another customer's cardholder data or environment.

11.4: Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows: (a) In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1, (b) Penetration testing is repeated to verify the corrections.
  • Examine penetration testing results to verify that noted exploitable vulnerabilities and security weaknesses were corrected in accordance with all elements specified in this requirement.
Description

Requirement 11.4.1

Purpose

A penetration testing methodology ensures that penetration tests are comprehensive, consistent, and repeatable. Without a defined methodology, tests may miss critical vulnerabilities or provide inconsistent results.

Good Practice

The methodology should define the scope, approach, and reporting requirements for penetration tests. It should be based on industry-accepted approaches such as NIST SP 800-115, OWASP Testing Guide, or PTES.

Requirement 11.4.2

Purpose

Internal penetration testing helps identify vulnerabilities that could be exploited by an insider or by an attacker who has gained access to the internal network. Internal tests complement vulnerability scans by testing for exploitability.

Good Practice

Internal penetration tests should be performed at least annually and after any significant changes to the infrastructure, applications, or network. Tests should attempt to exploit identified vulnerabilities to determine the potential impact.

Requirement 11.4.3

Purpose

External penetration testing helps identify vulnerabilities in externally facing systems that could be exploited by attackers from outside the network. External tests simulate real-world attack scenarios.

Good Practice

External penetration tests should be performed at least annually and after any significant changes to externally facing systems. Tests should be performed by qualified, experienced testers who are organizationally independent of the environment being tested.

Requirement 11.4.4

Purpose

Exploitable vulnerabilities discovered during penetration testing represent real risks to the environment. Correcting these vulnerabilities and retesting ensures that the risks have been effectively mitigated.

Good Practice

All exploitable vulnerabilities found during penetration testing should be corrected and the corrections verified through retesting. The retesting should confirm that the vulnerabilities can no longer be exploited.

Requirement 11.4.5

Purpose

If network segmentation is used to reduce the scope of the CDE, the effectiveness of that segmentation must be verified. If segmentation controls fail, the entire network may need to be considered in scope for PCI DSS.

Good Practice

Segmentation penetration tests should verify that segmentation controls effectively isolate the CDE from out-of-scope networks. Tests should be performed at least annually and after any changes to segmentation controls.

Requirement 11.4.6

Purpose

Service providers face unique risks due to the volume of cardholder data they handle and the number of clients they support. More frequent segmentation testing helps ensure that segmentation controls remain effective.

Good Practice

Service providers should perform segmentation penetration testing at least every six months and after any significant changes to segmentation controls or methods. Results should be documented and any issues remediated promptly.

Requirement 11.4.7

Purpose

Multi-tenant service providers must ensure that their segmentation controls effectively isolate each customer's data and environment. Without effective segmentation, one customer's data could be accessible from another customer's environment.

Good Practice

Multi-tenant service providers should test segmentation controls between customer environments. Tests should verify that one customer cannot access another customer's cardholder data or environment.

11.4: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: (a) At least once every 12 months and after any changes to segmentation controls/methods, (b) Covering all segmentation controls/methods in use, (c) According to the entity’s defined penetration testing methodology, (d) Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems, (e) Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3), (f) Performed by a qualified internal resource or qualified external third party, (g) Organizational independence of the tester exists (not required to be a QSA or ASV).
  • Examine segmentation controls and review penetration-testing methodology to verify that penetration-testing procedures are defined to test all segmentation methods in accordance with all elements specified in this requirement.
  • Examine the results from the most recent penetration test to verify the penetration test covers and addresses all elements specified in this requirement.
  • Interview personnel to verify that the test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Description

Requirement 11.4.1

Purpose

A penetration testing methodology ensures that penetration tests are comprehensive, consistent, and repeatable. Without a defined methodology, tests may miss critical vulnerabilities or provide inconsistent results.

Good Practice

The methodology should define the scope, approach, and reporting requirements for penetration tests. It should be based on industry-accepted approaches such as NIST SP 800-115, OWASP Testing Guide, or PTES.

Requirement 11.4.2

Purpose

Internal penetration testing helps identify vulnerabilities that could be exploited by an insider or by an attacker who has gained access to the internal network. Internal tests complement vulnerability scans by testing for exploitability.

Good Practice

Internal penetration tests should be performed at least annually and after any significant changes to the infrastructure, applications, or network. Tests should attempt to exploit identified vulnerabilities to determine the potential impact.

Requirement 11.4.3

Purpose

External penetration testing helps identify vulnerabilities in externally facing systems that could be exploited by attackers from outside the network. External tests simulate real-world attack scenarios.

Good Practice

External penetration tests should be performed at least annually and after any significant changes to externally facing systems. Tests should be performed by qualified, experienced testers who are organizationally independent of the environment being tested.

Requirement 11.4.4

Purpose

Exploitable vulnerabilities discovered during penetration testing represent real risks to the environment. Correcting these vulnerabilities and retesting ensures that the risks have been effectively mitigated.

Good Practice

All exploitable vulnerabilities found during penetration testing should be corrected and the corrections verified through retesting. The retesting should confirm that the vulnerabilities can no longer be exploited.

Requirement 11.4.5

Purpose

If network segmentation is used to reduce the scope of the CDE, the effectiveness of that segmentation must be verified. If segmentation controls fail, the entire network may need to be considered in scope for PCI DSS.

Good Practice

Segmentation penetration tests should verify that segmentation controls effectively isolate the CDE from out-of-scope networks. Tests should be performed at least annually and after any changes to segmentation controls.

Requirement 11.4.6

Purpose

Service providers face unique risks due to the volume of cardholder data they handle and the number of clients they support. More frequent segmentation testing helps ensure that segmentation controls remain effective.

Good Practice

Service providers should perform segmentation penetration testing at least every six months and after any significant changes to segmentation controls or methods. Results should be documented and any issues remediated promptly.

Requirement 11.4.7

Purpose

Multi-tenant service providers must ensure that their segmentation controls effectively isolate each customer's data and environment. Without effective segmentation, one customer's data could be accessible from another customer's environment.

Good Practice

Multi-tenant service providers should test segmentation controls between customer environments. Tests should verify that one customer cannot access another customer's cardholder data or environment.

11.4: 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: (a) At least once every six months and after any changes to segmentation controls/methods, (b) Covering all segmentation controls/methods in use, (c) According to the entity’s defined penetration testing methodology, (d) Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems, (e) Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3), (f) Performed by a qualified internal resource or qualified external third party, (g) Organizational independence of the tester exists (not required to be a QSA or ASV).
  • Additional testing procedure for service provider assessments only: Examine the results from the most recent penetration test to verify that the penetration covers and addressed all elements specified in this requirement.
  • Additional testing procedure for service provider assessments only: Interview personnel to verify that the test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV).
Description

Requirement 11.4.1

Purpose

A penetration testing methodology ensures that penetration tests are comprehensive, consistent, and repeatable. Without a defined methodology, tests may miss critical vulnerabilities or provide inconsistent results.

Good Practice

The methodology should define the scope, approach, and reporting requirements for penetration tests. It should be based on industry-accepted approaches such as NIST SP 800-115, OWASP Testing Guide, or PTES.

Requirement 11.4.2

Purpose

Internal penetration testing helps identify vulnerabilities that could be exploited by an insider or by an attacker who has gained access to the internal network. Internal tests complement vulnerability scans by testing for exploitability.

Good Practice

Internal penetration tests should be performed at least annually and after any significant changes to the infrastructure, applications, or network. Tests should attempt to exploit identified vulnerabilities to determine the potential impact.

Requirement 11.4.3

Purpose

External penetration testing helps identify vulnerabilities in externally facing systems that could be exploited by attackers from outside the network. External tests simulate real-world attack scenarios.

Good Practice

External penetration tests should be performed at least annually and after any significant changes to externally facing systems. Tests should be performed by qualified, experienced testers who are organizationally independent of the environment being tested.

Requirement 11.4.4

Purpose

Exploitable vulnerabilities discovered during penetration testing represent real risks to the environment. Correcting these vulnerabilities and retesting ensures that the risks have been effectively mitigated.

Good Practice

All exploitable vulnerabilities found during penetration testing should be corrected and the corrections verified through retesting. The retesting should confirm that the vulnerabilities can no longer be exploited.

Requirement 11.4.5

Purpose

If network segmentation is used to reduce the scope of the CDE, the effectiveness of that segmentation must be verified. If segmentation controls fail, the entire network may need to be considered in scope for PCI DSS.

Good Practice

Segmentation penetration tests should verify that segmentation controls effectively isolate the CDE from out-of-scope networks. Tests should be performed at least annually and after any changes to segmentation controls.

Requirement 11.4.6

Purpose

Service providers face unique risks due to the volume of cardholder data they handle and the number of clients they support. More frequent segmentation testing helps ensure that segmentation controls remain effective.

Good Practice

Service providers should perform segmentation penetration testing at least every six months and after any significant changes to segmentation controls or methods. Results should be documented and any issues remediated promptly.

Requirement 11.4.7

Purpose

Multi-tenant service providers must ensure that their segmentation controls effectively isolate each customer's data and environment. Without effective segmentation, one customer's data could be accessible from another customer's environment.

Good Practice

Multi-tenant service providers should test segmentation controls between customer environments. Tests should verify that one customer cannot access another customer's cardholder data or environment.

11.4: Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.
  • Additional testing procedure for multi- tenant service providers only: Examine evidence to verify that multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.
Description

Requirement 11.4.1

Purpose

A penetration testing methodology ensures that penetration tests are comprehensive, consistent, and repeatable. Without a defined methodology, tests may miss critical vulnerabilities or provide inconsistent results.

Good Practice

The methodology should define the scope, approach, and reporting requirements for penetration tests. It should be based on industry-accepted approaches such as NIST SP 800-115, OWASP Testing Guide, or PTES.

Requirement 11.4.2

Purpose

Internal penetration testing helps identify vulnerabilities that could be exploited by an insider or by an attacker who has gained access to the internal network. Internal tests complement vulnerability scans by testing for exploitability.

Good Practice

Internal penetration tests should be performed at least annually and after any significant changes to the infrastructure, applications, or network. Tests should attempt to exploit identified vulnerabilities to determine the potential impact.

Requirement 11.4.3

Purpose

External penetration testing helps identify vulnerabilities in externally facing systems that could be exploited by attackers from outside the network. External tests simulate real-world attack scenarios.

Good Practice

External penetration tests should be performed at least annually and after any significant changes to externally facing systems. Tests should be performed by qualified, experienced testers who are organizationally independent of the environment being tested.

Requirement 11.4.4

Purpose

Exploitable vulnerabilities discovered during penetration testing represent real risks to the environment. Correcting these vulnerabilities and retesting ensures that the risks have been effectively mitigated.

Good Practice

All exploitable vulnerabilities found during penetration testing should be corrected and the corrections verified through retesting. The retesting should confirm that the vulnerabilities can no longer be exploited.

Requirement 11.4.5

Purpose

If network segmentation is used to reduce the scope of the CDE, the effectiveness of that segmentation must be verified. If segmentation controls fail, the entire network may need to be considered in scope for PCI DSS.

Good Practice

Segmentation penetration tests should verify that segmentation controls effectively isolate the CDE from out-of-scope networks. Tests should be performed at least annually and after any changes to segmentation controls.

Requirement 11.4.6

Purpose

Service providers face unique risks due to the volume of cardholder data they handle and the number of clients they support. More frequent segmentation testing helps ensure that segmentation controls remain effective.

Good Practice

Service providers should perform segmentation penetration testing at least every six months and after any significant changes to segmentation controls or methods. Results should be documented and any issues remediated promptly.

Requirement 11.4.7

Purpose

Multi-tenant service providers must ensure that their segmentation controls effectively isolate each customer's data and environment. Without effective segmentation, one customer's data could be accessible from another customer's environment.

Good Practice

Multi-tenant service providers should test segmentation controls between customer environments. Tests should verify that one customer cannot access another customer's cardholder data or environment.

11.5: Intrusion-detection and/or intrusion- prevention techniques are used to detect and/or prevent intrusions into the network as follows: (a) All traffic is monitored at the perimeter of the CDE, (b) All traffic is monitored at critical points in the CDE, (c) Personnel are alerted to suspected compromises, (d) All intrusion-detection and prevention engines, baselines, and signatures are kept up to date.
  • Examine system configurations and network diagrams to verify that intrusion-detection and/or intrusion-prevention techniques are in place to monitor all traffic: • At the perimeter of the CDE. • At critical points in the CDE.
  • Examine system configurations and interview responsible personnel to verify intrusion- detection and/or intrusion-prevention techniques alert personnel of suspected compromises.
  • Examine system configurations and vendor documentation to verify intrusion-detection and/or intrusion-prevention techniques are configured to keep all engines, baselines, and signatures up to date.
Description

Requirement 11.5.1

Purpose

Intrusion-detection and/or intrusion-prevention techniques on the network help detect and/or prevent unauthorized access. Without these mechanisms, attackers may be able to access the CDE undetected.

Good Practice

IDS/IPS should be deployed at the perimeter of the CDE and at critical points within the network. Systems should be configured to detect and alert on, or prevent, all known attack signatures and anomalous network activity.

Requirement 11.5.1.1

Purpose

Keeping IDS/IPS systems current ensures they can detect the latest attack techniques. Outdated signatures or rules may fail to detect newer threats.

Good Practice

IDS/IPS signatures should be kept current through automatic updates. The systems should be configured to detect both known attacks (signature-based) and anomalous behavior (behavior-based) where possible.

Requirement 11.5.2

Purpose

Change-detection mechanisms such as file integrity monitoring (FIM) help detect unauthorized modifications to critical system files, configuration files, and content files. Unauthorized changes may indicate system compromise.

Good Practice

Change-detection mechanisms should be deployed to alert on unauthorized modifications to critical files. Comparisons should be performed at least weekly, and alerts should be generated for detected changes. Changes should be evaluated to determine if they are authorized.

11.5: Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels.
  • Additional testing procedure for service provider assessments only: Examine documentation and configuration settings to verify that methods to detect and alert on/prevent covert malware communication channels are in place and operating.
  • Additional testing procedure for service provider assessments only: Examine the entity’s incident-response plan (Requirement 12.10.1) to verify it requires and defines a response in the event that covert malware communication channels are detected.
  • Additional testing procedure for service provider assessments only: Interview responsible personnel and observe processes to verify that personnel maintain knowledge of covert malware communication and control techniques and are knowledgeable about how to respond when malware is suspected.
Description

Requirement 11.5.1

Purpose

Intrusion-detection and/or intrusion-prevention techniques on the network help detect and/or prevent unauthorized access. Without these mechanisms, attackers may be able to access the CDE undetected.

Good Practice

IDS/IPS should be deployed at the perimeter of the CDE and at critical points within the network. Systems should be configured to detect and alert on, or prevent, all known attack signatures and anomalous network activity.

Requirement 11.5.1.1

Purpose

Keeping IDS/IPS systems current ensures they can detect the latest attack techniques. Outdated signatures or rules may fail to detect newer threats.

Good Practice

IDS/IPS signatures should be kept current through automatic updates. The systems should be configured to detect both known attacks (signature-based) and anomalous behavior (behavior-based) where possible.

Requirement 11.5.2

Purpose

Change-detection mechanisms such as file integrity monitoring (FIM) help detect unauthorized modifications to critical system files, configuration files, and content files. Unauthorized changes may indicate system compromise.

Good Practice

Change-detection mechanisms should be deployed to alert on unauthorized modifications to critical files. Comparisons should be performed at least weekly, and alerts should be generated for detected changes. Changes should be evaluated to determine if they are authorized.

11.5: A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows: (a) To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files, (b) To perform critical file comparisons at least once weekly.
  • Examine system settings, monitored files, and results from monitoring activities to verify the use of a change-detection mechanism.
  • Examine settings for the change-detection mechanism to verify it is configured in accordance with all elements specified in this requirement.
Description

Requirement 11.5.1

Purpose

Intrusion-detection and/or intrusion-prevention techniques on the network help detect and/or prevent unauthorized access. Without these mechanisms, attackers may be able to access the CDE undetected.

Good Practice

IDS/IPS should be deployed at the perimeter of the CDE and at critical points within the network. Systems should be configured to detect and alert on, or prevent, all known attack signatures and anomalous network activity.

Requirement 11.5.1.1

Purpose

Keeping IDS/IPS systems current ensures they can detect the latest attack techniques. Outdated signatures or rules may fail to detect newer threats.

Good Practice

IDS/IPS signatures should be kept current through automatic updates. The systems should be configured to detect both known attacks (signature-based) and anomalous behavior (behavior-based) where possible.

Requirement 11.5.2

Purpose

Change-detection mechanisms such as file integrity monitoring (FIM) help detect unauthorized modifications to critical system files, configuration files, and content files. Unauthorized changes may indicate system compromise.

Good Practice

Change-detection mechanisms should be deployed to alert on unauthorized modifications to critical files. Comparisons should be performed at least weekly, and alerts should be generated for detected changes. Changes should be evaluated to determine if they are authorized.

11.6: A change- and tamper-detection mechanism is deployed as follows: (a) To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security- impacting HTTP headers and the script contents of payment pages as received by the consumer browser, (b) The mechanism is configured to evaluate the received HTTP headers and payment pages, (c) The mechanism functions are performed as follows: – At least weekly OR – Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
  • Examine system settings, monitored payment pages, and results from monitoring activities to verify the use of a change- and tamper- detection mechanism.
  • Examine configuration settings to verify the mechanism is configured in accordance with all elements specified in this requirement.
  • If the mechanism functions are performed at an entity-defined frequency, examine the entity’s targeted risk analysis for determining the frequency to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1.
  • Examine configuration settings and interview personnel to verify the mechanism functions are performed either: • At least weekly OR • At the frequency defined in the entity’s targeted risk analysis performed for this requirement.
Description

Requirement 11.6.1

Purpose

E-commerce skimming attacks target payment pages to capture cardholder data. Unauthorized modifications to payment page scripts or HTTP headers can indicate that a skimming attack is in progress. Detecting these modifications helps prevent data theft.

Good Practice

A mechanism should be in place to detect unauthorized changes to HTTP headers and content of payment pages as received by the consumer browser. This may include monitoring for changes to scripts, content security policies, and other page elements. Alerts should be generated for unauthorized changes and investigated promptly.

Examples

Mechanisms for detecting changes include Content Security Policy (CSP) reporting, Subresource Integrity (SRI) checking, real-time monitoring of payment page content, and third-party monitoring services that detect changes to payment page scripts.