Vulnerability Identification

PCI DSS version 4.0 requirement 6.3.1, for identification and management of vulnerabilities, and its predecessors in previous versions of PCI DSS have long been misunderstood. This requirement is referenced in 10 other PCI DSS requirements that impact how organizations will configure systems, develop applications, apply patches, and deal with the results of vulnerability scans and penetration tests. A solid understanding of requirement 6.3.1 is a core requirement for an effective and efficient PCI DSS compliance program.

Often, when I ask an organization how they are meeting this requirement, I am told that it is covered by the vulnerability scans performed under requirement 11. Requirement 6.3.1 is much deeper than scans however, and the applicability notes in PCI DSS version 4.0 have been updated to make this clear: “This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.” 

As a general rule, if you read two (2) different compliance requirements in the same framework and think they’re asking you for the same thing, you’re misinterpreting at least one (1) of those requirements.

With much clearer guidance, organizations can expect QSAs to pay closer attention to 6.3.1. So, if requirement 6.3.1 is not a vulnerability scan, how do we meet it? And what role does it play in other PCI DSS requirements? This is part one (1) of a three (3) part series that will take a deep dive into these topics to help organizations be prepared for their next assessment.

Requirement 6.3.1

Let’s start with the text of the requirement so we can approach each of its parts:

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.

As the opening line indicates, this requirement is telling us to define a process for identifying and managing vulnerabilities. The bullet points break this down into two (2) main tasks and provide some supporting details:

• A process for identifying vulnerabilities that may affect the organization, including commercial-off-the-shelf and bespoke or custom^[1] software, from a variety of sources
• A process for assigning risk rankings to the vulnerabilities that have been identified, including Critical and High risks

This post will specifically help organizations define and document the process for identifying vulnerabilities in a manner compliant with requirement 6.3.1. Risk ranking and other related requirements will be covered separately in parts two (2) and three (3), respectively.

Vulnerability Identification Process

Vulnerability scans and penetration tests are essential ways to identify vulnerabilities, and we will come back to them later, but the first bullet point of requirement 6.3.1 tells us that organizations must have more sources of information to help identify vulnerabilities that may affect the organization’s systems. This is a human-driven, manual process that involves monitoring for security alerts from a variety of different sources and weighing their relevance. 

A key driver behind this approach is the simple fact that there are many types of vulnerabilities that scanners can’t reliably detect:

• Most vulnerability scanners are checking for vulnerabilities in open source and commercial off-the-shelf software based on a known vulnerability database and will not find vulnerabilities in bespoke or custom software because those vulnerabilities are rarely included in such databases.
• Vulnerability scanners use automated checks. If a vulnerability can’t be checked automatically, it will not be detected by scanners.
• It takes time to update vulnerability scanners when new vulnerabilities are discovered. Scanners may miss vulnerabilities that have been recently discovered because proof-of-concept code hasn’t been released yet.
• Specialized vulnerability scanners that are designed for bespoke or custom software frequently miss vulnerabilities due to the difficulty of automatically identifying new vulnerabilities in applications.
• A vulnerability scanner is only as good as the access it has to the target. A scanner will miss many vulnerabilities if it is scanning through a restrictive firewall or is otherwise limited.

The first step when building a vulnerability identification process is to understand what software the organization is using within the scope of PCI DSS. This helps subscribe to sources that are likely to have vulnerability information relevant to the components the organization has and helps filter out irrelevant information about products the organization does not have. This software information should already be available, as requirement 12.5.1 calls for an inventory of systems components and the PCI DSS definition of system component includes software.

The next step for an organization is to determine a list of appropriate sources for vulnerability information based on the software they use. These will fall into a few categories:

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

Vendor Advisories

Many software and service vendors operate a mailing list and/or website with advisories about security issues and patches for their products, e.g., Microsoft, Google, Amazon, and Cisco. Organizations should sign up for and monitor the advisories from relevant vendors as these will often provide the first notice when a security patch is released. Unfortunately, some vendors may not immediately announce the discovery of a potential security issue in their products, so other sources are necessary for more timely information.

Remember to gather alerts for open-source projects as well as commercial software. Keep in mind that advisories for open-source projects may come from sources that are harder to use, like bug tracking systems or development email lists rather than simple security advisory email lists.

Public Alerts

Various organizations publish security advisories, usually via email lists, RSS feeds, or on websites. These can provide a wealth of information, especially when it comes to software from vendors that aren’t known for publishing their own security advisories. The drawback is that most public advisory sources cover a wide variety of vendors and some effort will be required to identify which advisories are relevant to an organization.

Various public security alert mailing lists and websites previously run by universities or non-profits, usually known as CERTs (Computer Emergency Readiness or Response Teams), have been consolidated under the Cybersecurity & Infrastructure Security Agency (CISA) of the U.S. Department of Homeland Security (DHS). CISA advisories cover a variety of security events including new vulnerabilities, security patches, and attacks.

The National Vulnerability Database (NVD), run by the National Institute of Standards and Technology (NIST), catalogs known vulnerabilities in commercial and open-source software. Each vulnerability is assigned a unique identifying Common Vulnerabilities and Exposures (CVE) number, which is usually referenced in vulnerability scan and penetration test reports. The CVE system is based on a long-running program by MITRE, which is currently transitioning from its old home at cve.mitre.org to www.cve.org.

Various application programming interfaces (APIs), feeds, and interfaces are available via the websites listed above to interact with the NVD and CVEs. Most vulnerabilities are first publicly announced via the release of a CVE so monitoring for new CVEs can provide early warning before scanners gain detection capability and vendors release patches. The NVD and other CVE resources are also good references to gain a deeper understanding of vulnerabilities detected by scanners and penetration tests.

Private Information Sharing Groups

Some organizations will communicate security advisories only to organizations they have vetted, for example InfraGard (a partnership between the FBI and private organizations). These sources may publish information before it is available to the public.

Members of many industries also share Information Security information amongst themselves. Some of these are informal communications between the IT teams of companies in the same sector, often via mailing lists or online forums. Formal Information Sharing and Analysis Centers (ISACs) have also gained popularity over the past decade. There are two (2) main advantages to these private communications: organizations may be willing to share information that they are not willing to make public and the information will likely be more relevant to the organization if it’s coming from another organization in the same industry.

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

Paid Threat Intelligence

A variety of Information Security companies now offer commercial threat intelligence services. Organizations can describe the types of information they are interested in and rely on these services to collect, review, and distill information to make it more relevant. Additionally, threat intelligence organizations may have access to vulnerability information that has not been publicly released yet, providing an even earlier warning than the CVE database. Some threat intelligence services include monitoring underground information sources for impending or undetected successful attacks on a specific organization.

Threat intelligence can be consumed in written format (e.g., emails or reports). Some services offer integration with security products to enable dynamic updates to firewall and intrusion prevention systems so they can automatically block new threat activity.

Although costly, a threat intelligence service is often the most comprehensive source of vulnerability information and can reduce the burden on the organization’s own personnel when monitoring for new vulnerabilities.

Custom and Bespoke Software Vulnerabilities

Custom and bespoke software presents an extra challenge as the sources above only provide information about vulnerabilities in publicly released software. Instead, organizations must understand the common programming mistakes that developers make that lead to vulnerabilities. Various efforts made to document these programming mistakes include the Open Web Application Security Project (OWASP) Top Ten and Common Weakness Enumeration (CWE). In-house and contracted developers should already have a good understanding of these mistakes per PCI DSS requirement 6.2.4.

Occasionally, an entirely new type of programming mistake is discovered with the potential to affect a wide variety of bespoke and custom software as developers may have been unwittingly writing vulnerable code for years. More frequently, a flaw is found in a common software library or API that may affect software built using the affected components. Organizations with bespoke or custom software should be monitoring for alerts that should be passed along to development personnel so they can determine if they need to update the libraries and APIs they use and/or make adjustments to their code to address potential vulnerabilities.

Organizations can also consider operating a bug bounty program to encourage external security researchers to help find vulnerabilities in their software that in-house personnel might not have the skills to detect. If not performing this in house, third-party experts like HackerOne can manage the bug bounty program on their behalf.

Documenting the Program

The organization’s policies should define the types of vulnerability information sources that will be monitored, who is responsible for monitoring these sources, and how often they should be reviewed. Procedures should take this a step further by defining the specific sources that will be monitored, how to access them, and the steps to take to identify relevant and irrelevant information.

Regardless of the source(s) of vulnerability information, filtering out irrelevant advisories without missing relevant vulnerabilities is key to reducing overhead while maintaining effectiveness. It is important for those responsible for monitoring vulnerabilities to know the different services, firmware and software packages, and versions used by the organization. This helps to quickly identify vulnerabilities that may affect the organization and to rule out vulnerabilities that cannot have an effect.

PCI DSS requirements 12.5.1 calls for a documented inventory of system components, including software, that can assist in identifying vulnerabilities that affect the organization’s environment. PCI DSS requirement 6.3.2 calls for an additional documented inventory of bespoke and custom software as well as third-party components, e.g., libraries and APIs, used by the bespoke and custom software so the personnel performing vulnerability management can identify relevant alerts. Both of these inventories should be referenced as part of the requirement 6.3.1 vulnerability identification procedures.

^[1] 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.