Vulnerability management in PCI DSS: Connecting all related controls

Vulnerability management is one of the most exhausting tasks in a PCI DSS environment, since it is necessary to periodically monitor the publication of notifications by manufacturers, review the reports of scans and penetration tests, assign a priority to each identified vulnerability and - based on it - manage its correction and validate that the actions implemented were effective. And all this within established time limits. For this reason, the PCI SSC published the infographic "PCI DSS v4.0.1 Vulnerability Management Processes", which serves as a reference to link all the steps and controls of the PCI DSS standard necessary for the identification, categorization, prioritization and remediation of vulnerabilities.

Each step of the PCI DSS vulnerability management process is described in a standard-specific control, distributed over different requirements. However, these tasks had not been schematized in a flowchart in which their order, prerequisites and connection to other controls could be understood. And it is precisely here that the PCI SSC Infographic takes action: Logically connecting each of the controls to establish a coordinated vulnerability management strategy.

Vulnerability management infographic in PCI DSS

The infographic is divided into two parts:

• A first part oriented to the process of identification, categorization and prioritization of the identified vulnerabilities and their associated risk.
• A second part where, based on the previous results, the risk management is proceeded with, either through the implementation of controls for its mitigation, the removal of the associated asset, the delegation to a third party or the use of a compensatory control whether there are technical or administrative restrictions that do not allow for the implementation of controls as required by the standard.

The ultimate goal of this activity is to manage each identified vulnerability, ensuring that the associated risk has been managed correctly.

Vulnerability management vs. analysis and risk management

It is very important that entities affected by PCI DSS compliance keep in mind that the process of categorising and assigning criticality levels to identified vulnerabilities is only the first step. Implicitly, in order to contextualize the vulnerability in each specific environment, it is essential to execute a risk analysis.

Keep in mind that manufacturers and other entities often use scoring systems to assess the severity of vulnerabilities, being one of the most used Common Vulnerability Scoring System (CVSS). CVSS provides a numeric system from 0 to 10 to represent the criticality of a vulnerability. However, it does not take into account other variables such as the probability of attack or the impact that a vulnerability can have on a particular environment, so that value, without its proper context, can lead to errors in potential risk management processes.

CVSS vulnerability metrics. Source: https://nvd.nist.gov/vuln-metrics/cvss#

The concepts of ‘vulnerability’ and ‘risk’ should not be confused. CVSS is a metric for assigning criticality to vulnerabilities, not risks

According to the document NIST Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments and many other risk analysis and management standards and guidelines (OCTAVE, ISO 27005, MAGERIT, FAIR, etc.) the following elements should be considered in order to have a clear context of the potential risk:

• Threat (threat): A threat is any circumstance or event with the potential to adversely affect the operations of the organization and its assets, individuals, other organizations or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service.
• Vulnerability (vulnerability): A vulnerability is a weakness in an information system, in system security procedures, in internal controls or in its implementation that could be exploited by a threat source.
• Probability (likelihood): The probability of occurrence is a weighted risk factor based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability (or set of vulnerabilities).
• Impact (impact): The level of impact of a threat event is the extent of the damage that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or system availability.
• Risk (risk): Risk is a function of the likelihood of a threat occurring and the potential adverse impact if it occurs. To calculate the risk there are multiple formulas, both quantitative and qualitative, including:
  • Risk = probability x impact – MAGERIT
  • Risk = vulnerability x probability x impact – FAIR (Factor Analysis of Information Risk)
  • Risk = (threat x vulnerability x probability x impact)/controls implemented

Generic risk model with its critical components (NIST 800-30)

Only with an analysis of these variables, you can have a complete context to prioritize and define the actions to be performed:

• Mitigating risk, using the deployment of standard-specific controls or compensatory controls, minimising risk up to a threshold tolerated by the organisation.
• Eliminate risk, removing the affected asset from the environment.
• Transfer risk, delegating its management and responsibility to a third party.

It is worth noting that under the PCI DSS standard, any identified risk cannot be accepted (i.e.: the risk cannot be known and nothing can be done to manage it), as it would expose the institution to a potential impact on payment card data.

Risk management strategies in PCI DSS

Returning again to the PCI SSC infographic, once you have the criticality values of a particular vulnerability (whether they have been provided by the manufacturer or by a third party or have been calculated by the entity), you must proceed with its contextualization to the affected environment, for which all the other variables listed above must be added to the equation (threat, probability, impact). Where the value of the risk is obtained, remediation shall be prioritised. This action is implicit in the following section of the infographic:

Risk analysis to prioritize remediation

It is VERY IMPORTANT that not only the criticality value of the vulnerability is used as a remediation prioritization element. Prioritization should come from a risk analysis, which adds the necessary contextualization of the affected environment and gives real prioritization value.

Practical Example of Vulnerability Management

Below is a simple example of vulnerability management based on the criteria described above. It is important to note that there are multiple ways to calculate risk, so the institution must choose and adapt these formulas to its own needs.

For the purposes of this example, the OWASP risk calculator (OWASP Risk Rating Calculator), which is based on the formula Probability x Impact, taking into account threats and vulnerabilities.

Example: Exploitable Vulnerability in Database

For this case, imagine that a technical vulnerability has been identified in a database that allows the scaling of privileges of authenticated users to obtain administrative provileges. This is a public vulnerability, with exploits and exploit tools available. However, sensitive data stored in this database is encrypted, there is an intrusion detection system in place and there is an action log (logs). If an attacker were to access the stored data, the impact would be less (since sensitive information is protected) but could have an impact on the reputation of the entity if it is published in online forums.

Adjusting the values of the variables, we get that the result is HIGH (HIGH) and, according to PCI DSS req. 6.3.3, its correction should be implemented within the first month after the update is released.

Result of risk analysis using OWASP Risk Rating Calculator

It is important to see that the values assigned to the vulnerability (vulnerability factors) are critical (if CVSS were used it would be a vulnerability with a score of 9 (CRITICAL), for example) but, taking into account the context of the organization, the controls implemented and the impact, its criticality decreases. Precisely for this reason it is SO IMPORTANT to contextualize the values of both vulnerabilities and risks.

Additional comments

Although this PCI SSC infographic serves as a starting point and reference for vulnerability management, there are some elements that were not taken into account and that should be incorporated in later versions:

1. The PCI DSS v4.0.1 standard does not make a clear differentiation between the concepts of "vulnerability" and "risk", sometimes using them as synonyms. As explained above, vulnerability criticalities are usually provided by manufacturers or third parties with standard formulas (CVSS, for example) that do not take into account the particularities of each affected environment. For this reason, The factor that should be used to prioritize remediation actions is the risk and not the criticality of the vulnerability.
2. The infographic is focused on results from internal vulnerability scans, but is also applicable to external scans (ASV) and penetration tests, as well as code analysis processes.
3. The flowchart starts with the execution of scans. However, vulnerabilities can also be identified from manufacturer notifications, internal reviews, notifications from software bug bounty, etc.
4. It is assumed that remediation actions are only the installation of security updates (patches). However, other actions such as configuration corrections, implementation of compensatory controls, removal of affected assets, etc. can also be employed.
5. Finally, once the remediation is implemented, it is necessary to re-run a scan (rescan – 11.3.1.3/11.3.2.1) or pentest (11.4.4) to confirm that everything is working as expected and update the secure configuration guides to prevent the same problem from being replicated in the deployment of similar assets (2.2.1).