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:
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:
Requirement 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows:
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:
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:
Requirement 6.3 Security vulnerabilities are identified and addressed.
Requirement 6.3.1 Security vulnerabilities are identified and managed as follows:
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:
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:
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:
Requirement 11.3.1.2 Internal vulnerability scans are performed via authenticated scanning as follows:
Requirement 11.3.1.3 Internal vulnerability scans are performed after any significant change as follows:
Requirement 11.3.2 External vulnerability scans are performed as follows:
Requirement 11.3.2.1 External vulnerability scans are performed after any significant change as follows:
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:
Requirement 11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows:
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:
Requirement 12.6.2 The security awareness program is:
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:
Requirement A1.2.3 Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including:
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.