Related Requirements

This is part three (3) of a three (3) part series on PCI DSS version 4.0 requirement 6.3.1, for identification and management of vulnerabilities. This requirement is one (1) of the most misunderstood PCI DSS requirements and has a large impact on compliance programs because it is referenced in 10 other requirements.

Parts one (1) and two (2) covered the vulnerability identification and risk ranking processes described in requirement 6.3.1. This part addresses other requirements that requirement 6.3.1 impacts.

It is worth reviewing part one (1) if you are not sure what requirement 6.3.1 is about or are confused as to why it’s a topic worth exploring. Most of the requirements covered in this part specifically reference the risk ranking process described in part two (2), so an understanding of that process will be important as well.

Patching

Requirement 6.3.3 requires organizations to install security patches and updates to protect systems from known vulnerabilities and relies on the risk ranking process from requirement 6.3.1 to determine how quickly patches must be applied.

According to requirement 6.3.3, a newly released security patch or update must be installed within one (1) month if it remediates a vulnerability ranked as Critical or High by the risk ranking process defined under requirement 6.3.1. Security updates and patches that address other vulnerabilities not ranked as Critical or High can be installed on a timeframe determined by the organization (this timeframe must be documented in the organization’s policies and procedures). The timeframe for patching lower priority vulnerabilitiesis only limited by what a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA) would accept as reasonable, but three (3) months is a good starting point.

It is important to be aware of newly released security patches and updates as well as the vulnerabilities they remediate so that the timeframes established by requirement 6.3.3 can be met. Many of the vulnerability information sources described as part of the requirement 6.3.1 vulnerability identification process will also provide notice of new security patches and updates, so the vulnerability identification process can be leveraged to help meet requirement 6.3.3 as well.

Note that the countdown to the one (1) month patch deadline in requirement 6.3.3 starts when a patch for a vulnerability is released, not when the vulnerability was discovered. Organizations should take steps to reduce risk in accordance with the guidance below for vulnerability scans when patches are not yet available for vulnerabilities, but this is not part of requirement 6.3.3.

Requirement 6.3.3 also does not apply to patches that don’t address vulnerabilities, e.g., updates that add features to a product. Organizations are under no obligation to upgrade to the latest version of a software package, as long as the version of the package they are running is still receiving security updates. Software that is no longer receiving security updates will eventually cause non-compliance as it accrues vulnerabilities that cannot be resolved in accordance with the vulnerability scanning and penetration testing requirements. Monitoring for end-of-life software is addressed separately in requirement 12.3.4.

Vulnerability Scans

Requirement 11.3.1 and its 11.3.1.1 and 11.3.1.3 sub-requirements all refer to requirement 6.3.1. Collectively these require:

• Internal vulnerability scans performed quarterly.
• Internal vulnerability scans performed after any significant change^[1] to the environment.
• Identified vulnerabilities must be resolved.
• Re-scans conducted to confirm that identified vulnerabilities have been resolved.

Vulnerabilities identified via the quarterly (requirement 11.3.1) and post-change (requirement 11.3.1.3) internal vulnerability scans must be put through the risk ranking process from requirement 6.3.1 to determine their rank, just like vulnerabilities identified as part of the vulnerability identification process described in requirement 6.3.1. The timeframes for resolving these vulnerabilities will depend on the resulting risk rankings and fall into three (3) categories, each described separately below:

1. Ranked as Critical or High Risk, patches are available.
2. Ranked as Critical or High Risk, patches are not available.
3. Not ranked as Critical or High Risk.

Addressing vulnerabilities for which patches are not available could involve any of the following actions, or some more creative solutions:

• Disabling the affected service(s)
• Changing configuration settings to work around the vulnerability
• Adjusting security controls to block access to the vulnerable service
• Setting up alerts that will detect and block attempts to exploit the vulnerability
• Removing the system(s) from the PCI DSS scope, e.g., by isolation from the CDE

Common Vulnerabilities and Exposures (CVE) records in the National Vulnerability Database (NVD)^[2] will usually provide information on workarounds and other suggested remediation steps for vulnerabilities, if any are available.

Note that the information below is only relevant to the internal vulnerability scans. PCI DSS does not allow the flexibility afforded by the risk ranking process for the external Approved Scanning Vendor (ASV) vulnerability scans. All external vulnerabilities with a Common Vulnerability Scoring System (CVSS) score of 4.0 or higher must be addressed within the three (3) month scan window to obtain a passing external ASV scan regardless of what the organization thinks of their risk.

Critical or High Risk – Patches Available

Requirement 6.3.3, as described above, applies to all security patches, not just for vulnerabilities identified as part of the requirement 6.3.1 vulnerability identification process. This means that patches must be applied within one (1) month of release for vulnerabilities identified during internal vulnerability scans that are ranked as Critical or High risk by the organization’s risk ranking process defined under requirement 6.3.1.

As discussed in Part two (2) of this blog, organizations could rely on the CVSS score alone to rank vulnerability risk, but this often causes problems. A more robust process is recommended to determine the risk of identified vulnerabilities as they apply to the organization’s environment and adjust the patching schedule appropriately.

Critical or High Risk – No Patches Available

The internal vulnerability scan requirements do not provide any specific time limits for remediating vulnerabilities identified during the scans that have been ranked as Critical or High risk. The guidance section for requirement 11.3.1 only states that any vulnerabilities ranked as Critical or High must be “resolved with the highest priority” and “…additional, documentation may be required to verify non-remediated vulnerabilities are in the process of being resolved.” This leaves us with a requirement to resolve these vulnerabilities but no clear timeframe for doing so.

A reasonable approach to requirement 11.3.1 timeframes is to attempt to address any Critical or High risk vulnerabilities as quickly as possible, with a goal of addressing them and conducting a rescan to verify they have been resolved within one (1) month. Plans and estimated timeframes should be documented for addressing Critical and High risk vulnerabilities that cannot be remediated within the one (1) month window. These can help demonstrate to a QSA that the organization is attempting to resolve the vulnerabilities and provide justification for why they could not be resolved during the one (1) month window.

Not Critical or High Risk

In theory, requirement 6.3.3 allows organizations to apply patches in accordance with their own timeframes established via organizational policy. However, requirement 11.3.1.1 has some additional instructions for vulnerabilities detected during vulnerability scans that the requirement 6.3.1 process has determined are not Critical or High risk.

Requirement 11.3.1.1 requires a more formal Targeted Risk Analysis (TRA) be performed on each vulnerability to determine how to address each vulnerability. Details of the TRA process are outside the scope of this post but are described in requirement 12.3.1. Templates for completing a TRA are provided on the PCI Security Standards Council (SSC) site. In short, an organization needs to consider the potential impact and likelihood of each vulnerability and use this information to justify the approach to addressing these vulnerabilities, including timeframes.

Penetration Tests

PCI DSS requires external, internal, and segmentation penetration testing. Multitenant service providers will also need to conduct logical separation tests. Requirement 11.4.4 describes what must be done with the exploitable vulnerabilities and security weaknesses found during the penetration tests. As with the vulnerability scans, requirement 11.4.4 tells us to put the vulnerabilities and weaknesses identified during these tests through the risk ranking process from requirement 6.3.1 and to repeat tests to verify issues have been corrected.

Notably, requirement 11.4.4 is vague about how to handle the vulnerabilities and weaknesses once they have been ranked. The guidance for requirement 11.4.4 only tells us to remediate the highest risk vulnerabilities more quickly but provides no further guidance on time limits. The advice given above for the internal vulnerability scans applies here as well—Use the timeframes from requirement 6.3.3 for any vulnerabilities that can be patched and document plans and reasonable timeframes to remediate other issues, prioritizing those that are Critical and High risk.

Software Engineering

Requirement 6.2.4 requires developers to use programming techniques designed to avoid creating common types of vulnerabilities in bespoke and custom software^[3] they write or that is written on their behalf. This requirement includes a list of common vulnerability types that must be avoided and includes a reference to High risk vulnerabilities identified as part of the processes defined in requirement 6.3.1 in this list.

As mentioned in part one (1), the vulnerability identification process from requirement 6.3.1 must identify new types of vulnerabilities in bespoke and custom software. The vulnerability identification procedure should include steps for communicating any such vulnerabilities that have been ranked as Critical or High risk to the personnel responsible for the software development process so that development standards can be updated to address these vulnerabilities.

The inventory of bespoke and custom software as well as third-party components used by bespoke and custom software, created to meet requirement 6.3.2, will help facilitate these conversations.

Web Application Vulnerabilities

Requirement 6.4.1 requires either periodic vulnerability assessments of public-facing web applications or the use of automated solutions to prevent attacks. The periodic assessment option references requirement 6.3.1 both directly and indirectly.

Requirement 6.4.1 is set to be replaced by requirement 6.4.2 on April 01, 2025. Requirement 6.4.2 removes the option to perform the periodic assessments and will therefore no longer contain references to requirement 6.3.1. This section can be ignored after that date or by any organization that is already using automated solutions to prevent attacks in lieu of periodic assessments.

Requirement 6.4.1 indirectly references requirement 6.3.1 via requirement 6.2.4, described in the previous section. The assessment must include testing for all common software attacks listed in requirement 6.2.4. Recall that requirement 6.2.4 requires consideration of Critical and High risk vulnerabilities identified as part of requirement 6.3.1 as potential common software attacks. This means the assessment must check for any relevant Critical or High risk application vulnerabilities identified via the process defined in requirement 6.3.1.

As with vulnerability scans and penetration tests, the requirement 6.4.1 periodic assessment option requires any discovered vulnerabilities to be put through the risk ranking process defined in requirement 6.3.1. Also, much like the vulnerability scan and penetration test requirements, requirement 6.4.1 does not provide specific timelines for addressing these vulnerabilities. The same advice applies here: apply all patches in accordance with requirement 6.3.3 timeframes and plan to remediate other vulnerabilities in accordance with their risk ranking.

Keep in mind, the vulnerabilities identified as part of this assessment will likely include vulnerabilities unique to each application, effectively bugs written by the in-house or contracted developers. These vulnerabilities will not have CVE numbers or CVSS scores in the NVD, so this is why it's important to have a risk ranking system that can effectively rank any vulnerability rather than using a scale that relies solely on published CVSS scores.

Configuration Standards

Requirement 2.2.1 contains a set of criteria for developing, implementing, and maintaining system configuration standards. This includes updating the configuration standards based on information collected as part of the vulnerability identification process defined in requirement 6.3.1.

The process for identifying vulnerabilities should include steps to notify the personnel responsible for maintaining system configuration standards whenever a vulnerability that could affect those systems is identified. The inventory of system components, including software, created to meet requirement 12.5.1 will help facilitate these conversations.

The configuration standards should be updated to mitigate the vulnerabilities when notification is received. This may include updating a configuration standard to reflect a patch that needs to be applied, a change to system settings to work around a vulnerability until a patch is available, or a change to network security control settings to prevent the vulnerability from being exploited.

No timeframe is established for these communications and the resulting updates to the configuration standards. Notification should generally occur every time the vulnerability identification process is carried out and configuration standards can be updated based on the risks posed by the vulnerabilities.

Malware

PCI DSS only requires anti-malware controls on systems that are at risk for malware, but requirement 5.2.3 requires periodic reviews of systems that have been determined not to be at risk of malware in order to determine if that status should be changed. The guidance for requirement 5.2.3 refers to the vulnerability identification process defined in requirement 6.3.1 as a source of information about trends in malware that should be used when making applicability decisions.

The information sources used in the vulnerability identification process defined in requirement 6.3.1 should provide information about malware campaigns and the types of systems affected. The vulnerability identification process should include steps to notify the personnel responsible for conducting the periodic reviews of malware threats when relevant information about malware is collected to help make appropriate decisions during the periodic reviews. If new malware types or campaigns are known to target a system component that was previously considered not at risk of malware, it is likely time to reconsider that component’s status.

Time Synchronization

Requirement 10.6.1 requires time synchronization of system clocks. The applicability notes mention managing vulnerabilities and patching time synchronization technology in accordance with requirements 6.3.1 and 6.3.3. This is an oddly specific reference as there is no significant link between requirements 10.6.1 and 6.3.1, but it serves as a good reminder that requirement 6.3.1 applies to all systems in scope for PCI DSS, even the humble time synchronization server.

Considering All Parts of Infrastructure

Organizations may forget about parts of their infrastructure that just work without much attention, e.g., NTP servers, DNS servers, network switches and routers, network-connected uninterruptible power supply (UPS) systems, lights-out management systems, network-connected cameras, door lock access systems, etc. Any type of system component, including the ones we rarely think about, could contain vulnerabilities that might allow an attacker to gain access to a network and/or traverse inside the network.

To be effective, the vulnerability identification process defined in requirement 6.3.1 must include monitoring for alerts related to vulnerabilities in all in-scope components, and the risk ranking process should consider how each of these components can impact the security of account data.

^[1] What constitutes a significant change is addressed in Section 7 of the PCI DSS v4.0 Requirements and Testing Procedures document.

^[2] Refer to part one (1) to learn about CVE and NVD.

^[3] PCI DSS defines Custom Software as “software developed by the entity for its own use” while Bespoke Software is “developed by a third-party on behalf of the entity and per the entity’s specifications.” Essentially, this covers any software that is not open source or bought off-the-shelf.