Understanding and Meeting PCI DSS Requirement 6.3.1: Vulnerability Identification

PCI DSS version 4.0 requirement 6.3.1, focusing on the identification and management of vulnerabilities, along with its predecessors in previous iterations of PCI DSS, has often been misconstrued. This requirement is interlinked with 10 other PCI DSS requirements, influencing how organizations configure systems, develop applications, apply patches, and address the outcomes of vulnerability scans and penetration tests. A thorough grasp of requirement 6.3.1 is pivotal for establishing a robust and streamlined PCI DSS compliance program.

Frequently, when inquiring about an organization’s compliance with this requirement, the response revolves around the vulnerability scans conducted under requirement 11. However, requirement 6.3.1 entails more depth than mere scans. The applicability notes in PCI DSS version 4.0 have been revised to emphasize this: “This requirement diverges from vulnerability scans performed for Requirements 11.3.1 and 11.3.2. Instead, it necessitates a process for actively monitoring industry sources for vulnerability intelligence and determining the risk ranking for each vulnerability.”

As a guiding principle, if two distinct compliance requirements within the same framework appear to solicit identical actions, it indicates a misinterpretation of at least one of those requirements.

With clearer directives, organizations can anticipate Qualified Security Assessors (QSAs) to scrutinize requirement 6.3.1 more closely. Consequently, if requirement 6.3.1 doesn’t entail a vulnerability scan, how is it fulfilled? And what role does it play in other PCI DSS requirements? This marks the first installment of a comprehensive three-part series delving into these subjects to equip organizations for forthcoming assessments. 

Let’s begin by examining the text of Requirement 6.3.1:

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 high-risk or critical to the environment.
• Vulnerabilities for bespoke and custom, and third-party software (for example, operating systems and databases) are covered.

The initial statement of this requirement prompts us to establish a process for recognizing and handling vulnerabilities. The listed points delineate two primary tasks and offer supplementary details:

• Establishing a procedure for identifying vulnerabilities that could impact the organization, encompassing both commercial-off-the-shelf and custom software, sourced from various outlets.
• Implementing a system for assessing risk levels associated with identified vulnerabilities, including categorization into Critical and High-risk classifications.

This discussion will specifically aid organizations in formulating and documenting the process for identifying vulnerabilities in compliance with Requirement 6.3.1. Subsequent parts will address risk ranking and other pertinent requirements separately in parts two and three, respectively.

Process for Identifying Vulnerabilities

While vulnerability scans and penetration tests remain crucial methods for vulnerability detection, the primary directive of requirement 6.3.1 underscores the necessity for organizations to broaden their sources of information for identifying potential vulnerabilities affecting their systems. This entails a human-driven, manual approach involving vigilant monitoring of security alerts from diverse outlets and assessing their pertinence.

This approach is motivated by the recognition that certain vulnerabilities elude detection by scanners for various reasons:

• Vulnerability scanners typically focus on known vulnerabilities in open source and commercial off-the-shelf software, often overlooking vulnerabilities in bespoke or custom software absent from standard vulnerability databases.
• Automated checks employed by vulnerability scanners may overlook vulnerabilities that cannot be assessed automatically.
• Delays in updating vulnerability scanners mean they may miss recently discovered vulnerabilities lacking accompanying proof-of-concept code.
• Specialized scanners for bespoke software struggle to detect new vulnerabilities automatically, leading to potential oversights.
• The effectiveness of a vulnerability scanner depends on its access to the target; restrictive firewalls or other limitations can impede detection.

The initial phase in establishing a vulnerability identification process involves comprehending the organization’s software landscape within the PCI DSS scope. This facilitates subscribing to relevant vulnerability information sources while filtering out irrelevant data about unutilized products. Such software details should be readily available, as mandated by requirement 12.5.1, which necessitates an inventory of system components, inclusive of software.

Subsequently, organizations should compile a roster of suitable vulnerability information sources based on their software usage, encompassing:

• Vendor advisories
• Public alerts
• Private information-sharing groups
• Paid threat intelligence

Vendor Alerts

Numerous software and service providers maintain mailing lists and websites dedicated to disseminating advisories regarding security vulnerabilities and patches for their offerings. Prominent examples include Microsoft, Google, Amazon, and Cisco. Organizations must subscribe to and actively monitor advisories from relevant vendors, as these often serve as the initial notification channels for newly released security patches. However, it is worth noting that certain vendors may not promptly disclose the discovery of potential security issues in their products, necessitating reliance on alternative sources for more timely updates.

Additionally, it is crucial to gather alerts for both open-source projects and commercial software. It’s important to acknowledge that advisories for open-source projects may originate from less user-friendly sources such as bug-tracking systems or development email lists, rather than straightforward security advisory email lists.

Public Security Alerts

Numerous organizations disseminate security advisories through channels like email lists, RSS feeds, and websites. These alerts can offer valuable insights, particularly for software from vendors less inclined to issue their advisories. However, the breadth of coverage across multiple vendors means that some effort is necessary to sift through and identify the advisories pertinent to a specific organization.

Formerly managed by universities or non-profit entities, many public security alert platforms, commonly known as CERTs (Computer Emergency Readiness or Response Teams), have now been consolidated under the Cybersecurity & Infrastructure Security Agency (CISA) of the U.S. Department of Homeland Security (DHS). CISA advisories encompass a range of security events, including new vulnerabilities, security patches, and cyber attacks.

The National Vulnerability Database (NVD), administered by the National Institute of Standards and Technology (NIST), serves as a comprehensive repository of known vulnerabilities in both commercial and open-source software. Each vulnerability is allocated a unique Common Vulnerabilities and Exposures (CVE) identifier, typically referenced in vulnerability scan and penetration test reports. The CVE system, managed by MITRE, is undergoing a transition from its previous domain at cve.mitre.org to www.cve.org.

Various application programming interfaces (APIs), feeds, and interfaces accessible through the aforementioned websites facilitate interaction with the NVD and CVEs. Monitoring for new CVEs can provide early warning before scanner detection and vendor patch releases, as most vulnerabilities are initially disclosed via CVEs. Furthermore, the NVD and other CVE resources serve as valuable references for gaining deeper insights into vulnerabilities detected through scanners and penetration tests.

Private Information-Sharing Groups

Certain organizations restrict the dissemination of security advisories solely to vetted entities, exemplified by entities like InfraGard, a collaboration between the FBI and private organizations. These sources often release information before it becomes publicly available.

Moreover, various industries facilitate the exchange of Information Security insights among their members. These exchanges range from informal discussions among IT teams within the same sector, commonly conducted through mailing lists or online forums, to formal Information Sharing and Analysis Centers (ISACs) which have garnered popularity over the past decade. Private communications offer two primary advantages: organizations may share information they are reluctant to disclose publicly, and the shared information is typically more pertinent to the organization when sourced from within the same industry.

The National Council of ISACs maintains a comprehensive list of ISACs focusing on critical industries.

Paid Threat Intelligence

Numerous Information Security firms now provide commercial threat intelligence services. Organizations can specify their preferences regarding the types of information they seek, entrusting these services to gather, assess, and refine data to enhance its relevance. Furthermore, threat intelligence entities may possess access to vulnerability data not yet publicly disclosed, offering preemptive alerts even before entries appear in the CVE database. Some services go as far as monitoring clandestine channels for indications of imminent or undetected attacks targeting a particular organization.

This intelligence can be delivered through written mediums such as emails or reports. Certain services facilitate integration with security products, enabling real-time updates to firewall and intrusion prevention systems for automatic mitigation of emerging threats.

While these services come with a significant cost, they often represent the most exhaustive repository of vulnerability information available, thereby alleviating the strain on an organization’s internal resources tasked with monitoring for new vulnerabilities.

Vulnerabilities in Custom and Bespoke Software

Addressing vulnerabilities in custom and bespoke software poses an additional challenge, as conventional sources typically focus on vulnerabilities in publicly released software. Consequently, organizations must familiarize themselves with common programming errors leading to vulnerabilities. Efforts to document these errors include resources such as the Open Web Application Security Project (OWASP) Top Ten and Common Weakness Enumeration (CWE). According to PCI DSS requirement 6.2.4, in-house and contracted developers should already possess a solid grasp of these issues.

Periodically, entirely new categories of programming errors surface, potentially impacting a broad spectrum of bespoke and custom software. Developers may unknowingly incorporate vulnerable code over extended periods. More frequently, vulnerabilities emerge in widely used software libraries or APIs, affecting software built with the affected components. Organizations employing bespoke or custom software should actively monitor alerts, promptly relaying relevant information to development teams. This allows for timely assessment of the need to update libraries and APIs or adjust code to rectify potential vulnerabilities.

Additionally, organizations can explore the option of implementing a bug bounty program to enlist external security researchers in identifying software vulnerabilities that may elude in-house personnel. Third-party platforms like HackerOne can manage bug bounty programs if organizations opt not to handle them internally.

Documentation of the Program

The organization’s policies ought to delineate the types of vulnerability information sources under surveillance, designate responsible parties for monitoring these sources, and establish the frequency of reviews. Procedures should further detail the specific sources to be monitored, methods for accessing them, and protocols for discerning pertinent from extraneous information.

Regardless of the origin of vulnerability information, the ability to sift through irrelevant advisories while capturing relevant vulnerabilities is essential for streamlining operations without compromising efficacy. Those tasked with vulnerability monitoring must possess a comprehensive understanding of the organization’s array of services, firmware, software packages, and versions. This knowledge facilitates prompt identification of vulnerabilities that could impact the organization and enables the exclusion of non-applicable vulnerabilities.

PCI DSS requirement 12.5.1 mandates a documented inventory of system components, including software, aiding in the identification of vulnerabilities within the organization’s environment. Additionally, requirement 6.3.2 stipulates a separate documented inventory of bespoke and custom software, along with third-party components like libraries and APIs. This inventory equips personnel responsible for vulnerability management with the necessary information to identify relevant alerts. Both inventories should be referenced as integral parts of the vulnerability identification procedures outlined in requirement 6.3.1.

In Conclusion:

PCI DSS requirement 6.3.1 necessitates a robust vulnerability identification process beyond standard scanning activities. By leveraging diverse information sources and implementing effective procedures, organizations can enhance their compliance efforts and mitigate security risks effectively.