The Vulnerability Management Lifecycle in PCI DSS v.4: Identifying, Investigating, Addressing, and Maintaining Security

Introduction:

PCI DSS (Payment Card Industry Data Security Standard) version 4 brings a renewed focus on security and compliance in handling of payment card data.

Central to PCI DSS v.4 is the concept of the vulnerability management lifecycle, a systematic approach to identifying, investigating, addressing, and maintaining security vulnerabilities.

In this article, we will explore the vulnerability management lifecycle within the context of PCI DSS v.4, outlining the requirements, technologies, and the role of Approved Scanning Vendors (ASVs) in ensuring compliance.

But, before we begin let us clarify what a Vulnerability is.

According to the PCI SSC Glossary, Vulnerability is a flaw or weakness which, if exploited, may result in an intentional or unintentional compromise of a system. https://www.pcisecuritystandards.org/glossary/#glossary-v

Vulnerability Management, on the other hand, is a cyclical practice that varies in theory but contains common processes which include:

• discover all assets,
• prioritize assets,
• assess or perform a complete vulnerability scan,
• report on results,
• remediate vulnerabilities,
• verify remediation - repeat.

Now, we can move to PCI DSS.

As we know the standard consists of 12 requirements combined into 6 concepts. One of them is - Maintain a Vulnerability Management Program, binding 2 principal requirements together.

Requirement 5: Protect All Systems and Networks from Malicious Software

Requirement 6: Develop and Maintain Secure Systems and Software

What is the Vulnerability Management LifeCycle?

The VMLC in PCI DSS v.4 involves four key stages:

a. Identify: The first step is to identify potential vulnerabilities within the cardholder data environment (CDE). This includes not only known vulnerabilities but also emerging threats that may pose risks to payment card data.

b. Investigate: Once vulnerabilities are identified, it's essential to investigate their scope and impact. This involves determining whether the vulnerabilities could lead to a compromise of cardholder data and understanding their criticality.

c. Address: After investigation, vulnerabilities must be addressed promptly. This includes implementing fixes, patches, or mitigating controls to reduce the risk they pose to the CDE.

d. Maintain: The final step is continuous maintenance. Security is an ongoing process, and maintaining a secure environment involves regularly reassessing for vulnerabilities, keeping systems up-to-date, and adapting to emerging threats.

The keyword in the d stage above is continuous. In other words, the cycle shall be run continuously repeating other steps in a cycle.

Let us review the Requirements for Vulnerability Management stipulated in PCI DSS v4:

PCI DSS v4 outlines specific requirements for vulnerability management to ensure the security of cardholder data:

a. Identify:

Requirement 2.2.1 Configuration standards are developed, implemented, and maintained to:

• Address all known security vulnerabilities.
• Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.

Requirement 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:

• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software.

Requirement 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:

• Code reviews look for both existing and emerging software vulnerabilities.

Requirement 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:

• Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1.

Requirement 6.3 Security vulnerabilities are identified and addressed.

Requirement 6.3.1 Security vulnerabilities are identified and managed as follows:

• New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).
• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
• Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.
• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.

Requirement 6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.

Requirement 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:

• Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).

Requirement 6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:

Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:

– At least once every 12 months and after significant changes.

– By an entity that specializes in application security.

– Including, at a minimum, all common software attacks in Requirement 6.2.4.

– All vulnerabilities are ranked in accordance with requirement 6.3.1.

– All vulnerabilities are corrected.

– The application is re-evaluated after the corrections

b. Investigate:

Requirement 11.3 External and Internal vulnerabilities are regularly identified, prioritized, and addressed.

Requirement 11.3.1 Internal vulnerability scans are performed as follows:

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

Requirement 11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings defined in Requirement 6.3.1) are managed as follows:

• 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.
• Rescans are conducted as needed.

Requirement 11.3.1.2 Internal vulnerability scans are performed via authenticated scanning as follows:

• Systems that are unable to accept credentials for authenticated scanning are documented.
• Sufficient privileges are used for those systems that accept credentials for scanning.
• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2.

Requirement 11.3.1.3 Internal vulnerability scans are performed after any significant change as follows:

• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
• Rescans are conducted as needed.
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

Requirement 11.3.2 External vulnerability scans are performed as follows:

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

Requirement 11.3.2.1 External vulnerability scans are performed after any significant change as follows:

• Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.
• Rescans are conducted as needed.
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

c. Address:

Requirement 11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.

Requirement 11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity, and includes:

• Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4.
• Review and consideration of threats and vulnerabilities experienced in the last 12 months.
• Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing.

Requirement 11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows:

• In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1.
• Penetration testing is repeated to verify the corrections.

d. Maintain:

Requirement 12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following:

• An up-to-date inventory of all cryptographic cipher suites and protocols in use, including the purpose and where used.
• Active monitoring of industry trends regarding the continued viability of all cryptographic cipher suites and protocols in use.
• A documented strategy to respond to anticipated changes in cryptographic vulnerabilities.

Requirement 12.6.2 The security awareness program is:

• Reviewed at least once every 12 months, and
• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s CDE, or the information provided to personnel about their role in protecting cardholder data.

Requirement 12.6.3.1 Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to:

• Phishing and related attacks.
• Social engineering

Requirement A1.2.3 Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including:

• Customers can securely report security incidents and vulnerabilities to the provider.
• The provider addresses and remediates suspected or confirmed security incidents and vulnerabilities according to Requirement 6.3.1.

Note: Appendix F Leveraging the PCI Software Security Framework to Support Requirement 6 is a good guideline for Software Development, this part we will review during our next articles

The Approved Scanning Vendors (ASVs)

According to PCI SSC https://listings.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors

An ASV is an organization with a set of security services and tools (“ASV scan solution”) to conduct external vulnerability scanning services to validate adherence with the external scanning requirements of PCI DSS Requirement 11.2.2.

The scanning vendor’s ASV scan solution is tested and approved by PCI SSC before an ASV is added to PCI SSC’s List of Approved Scanning Vendors.

If You visit the link above, we will see a long list of organizations that provide "security services and tools (“ASV scan solution”) to conduct external vulnerability scanning service".

Conclusion:

In PCI DSS v.4, the Vulnerability Management Lifecycle plays a pivotal role in maintaining the security of payment card data. By identifying, investigating, addressing, and maintaining vulnerabilities, organizations can enhance their security posture and reduce the risk of data breaches. Compliance with the specific requirements outlined in PCI DSS v.4, along with the engagement of Approved Scanning Vendors (ASVs), is crucial in achieving and maintaining a secure cardholder data environment. ASVs provide a human touch to vulnerability assessment, complementing automated scanning, and helping organizations stay compliant and secure.