Vulnerability Management and PCI DSS: Unraveling Requirement 6.3.1

This article is the third and final installment in our series on PCI DSS version 4.0 requirement 6.3.1, which focuses on the identification and management of vulnerabilities. As one of the most complex and frequently misunderstood PCI DSS requirements, 6.3.1 significantly influences compliance programs, being referenced in ten other requirements.

In parts one and two, we explored the processes for identifying vulnerabilities and ranking risks as outlined in requirement 6.3.1. This article will delve into how requirement 6.3.1 impacts other PCI DSS requirements.

Recap of Requirement 6.3.1

For those new to the topic or in need of a refresher, part one detailed what requirement 6.3.1 entails and why it is critical. Additionally, part two explained the risk ranking process, which is fundamental to understanding the application of 6.3.1 across other requirements.

Patching (Requirement 6.3.3)

Requirement 6.3.3 mandates the installation of security patches and updates to protect systems from known vulnerabilities, using the risk rankings from 6.3.1 to determine patching urgency.

According to 6.3.3, patches addressing vulnerabilities ranked as Critical or High must be installed within one month of their release. Other vulnerabilities can be patched according to the organization’s documented policies, usually within a timeframe deemed reasonable by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA), often set at three months.

Staying abreast of new security patches and updates is crucial to meet these timeframes. Many sources for vulnerability information, as identified in 6.3.1, also notify organizations of new patches, streamlining compliance with 6.3.3.

Vulnerability Scans (Requirement 11.3.1 and Sub-requirements 11.3.1.1 and 11.3.1.3)

These requirements call for:

• Quarterly internal vulnerability scans.
• Scans after significant changes to the environment.
• Resolution of identified vulnerabilities.
• Re-scans to confirm resolution.

Vulnerabilities identified in these scans must be ranked according to 6.3.1, determining their risk and setting remediation priorities. The actions taken depend on the risk ranking and availability of patches:

1. Critical or High Risk, Patches Available: Must be patched within one month, as per 6.3.3.
2. Critical or High Risk, No Patches Available: This should be addressed immediately, with documented plans if resolution exceeds one month.
3. Not Critical or High Risk: Requires a formal Targeted Risk Analysis (TRA) to determine appropriate actions and timeframes, as outlined in requirement 12.3.1.

Penetration Tests (Requirement 11.4.4)

Requirement 11.4.4 addresses handling vulnerabilities and security weaknesses found during penetration tests. These findings must undergo the 6.3.1 risk ranking process, with the highest-risk vulnerabilities prioritized for remediation. As with internal scans, patches for these vulnerabilities should follow 6.3.3 timeframes, with documentation justifying any deviations.

Software Engineering (Requirement 6.2.4)

Developers must use secure coding practices to avoid common vulnerabilities. Requirement 6.2.4 includes High-risk vulnerabilities identified by 6.3.1, necessitating updates to development standards based on new vulnerability types.

The inventory of bespoke and custom software, as well as third-party components (requirement 6.3.2), supports this process by ensuring comprehensive vulnerability communication.

Web Application Vulnerabilities (Requirement 6.4.1/6.4.2)

Requirement 6.4.1 mandates periodic assessments of public-facing web applications or the use of automated solutions to prevent attacks. This requirement references 6.3.1 directly and indirectly via requirement 6.2.4. Vulnerabilities identified must be ranked according to 6.3.1 and remediated following the risk-based timeframes outlined in 6.3.3.

After April 1, 2025, requirement 6.4.1 will be replaced by 6.4.2, removing the option for periodic assessments and emphasizing automated solutions.

Configuration Standards (Requirement 2.2.1)

Configuration standards must be updated based on information from the 6.3.1 vulnerability identification process. This includes patches, configuration changes, and security control adjustments to mitigate vulnerabilities.

Malware (Requirement 5.2.3)

Periodic reviews determine if systems previously considered not at risk for malware should now be protected. These reviews leverage information from the 6.3.1 process to stay current on malware trends and threats.

Time Synchronization (Requirement 10.6.1)

Time synchronization systems must be patched and managed according to the 6.3.1 and 6.3.3 requirements, reinforcing the need for a comprehensive vulnerability management approach.

Considering All Parts of Infrastructure

All in-scope components, including often-overlooked systems like NTP servers, DNS servers, and network-connected UPS systems, must be monitored for vulnerabilities. The 6.3.1 process ensures these components are included, and their risks appropriately ranked and managed.

Conclusion

Requirement 6.3.1 is integral to PCI DSS compliance, influencing numerous other requirements. A thorough understanding of its vulnerability identification and risk ranking processes is essential for effective implementation and maintaining robust cybersecurity practices.