What is PCI DSS v4.0 Requirement 11.4.4?

What is PCI DSS v4.0 Requirement 11.4.4?

Among the many changes in the new PCI DSS v4.0 are those regarding requirement 11.4.4, which refers to the remediation of "exploitable vulnerabilities" and "security weaknesses”—though history has more clearly established what is meant by the former, there may be some confusion concerning the latter as organizations continue to make the transition to the new version.

But as experienced PCI Qualified Security Assessors who have done a deep dive into the updates to this flagship standard, we’re going to clarify this requirement and its language so that your shift to PCI DSS v4.0 goes all the more smoothly.

Though there will still be plenty of new guidance to comb through, having read this, you’ll at least have more surety on this one important aspect.

Exploitable Vulnerabilities vs. Security Weaknesses

Requirement 11.4.4 addresses the remediation of “exploitable vulnerabilities” and “security weaknesses,” as we mentioned, and to fully understand how to fix them, we first need to define these elements.

Here’s a high-level breakdown:

Exploitable Vulnerabilities:	Security Weaknesses:
These are specific flaws or weaknesses in a system's: Design; Implementation; Operation; or Management that could be directly exploited to violate the system's security policy and controls to gain access to the system. Because these are typically associated with a higher level of risk due to their potential to be exploited by malicious actors, swift action and mitigation are usually essential to prevent potential security breaches.	This is a broader term that encompasses all types of vulnerabilities—including high, medium, and low-risk—regardless of their exploitability or severity. Security weaknesses could be in the form of: Software bugs Misconfigurations Weak passwords Lack of encryption, etc. While these may not all be directly exploitable, they still represent areas where the system's security could be improved to reduce the overall risk.

Exploitable Vulnerabilities:

Security Weaknesses:

These are specific flaws or weaknesses in a system's:

Design;
Implementation;
Operation; or
Management that could be directly exploited to violate the system's security policy and controls to gain access to the system.

Because these are typically associated with a higher level of risk due to their potential to be exploited by malicious actors, swift action and mitigation are usually essential to prevent potential security breaches.

This is a broader term that encompasses all types of vulnerabilities—including high, medium, and low-risk—regardless of their exploitability or severity.

Security weaknesses could be in the form of:

Software bugs
Misconfigurations
Weak passwords
Lack of encryption, etc.

While these may not all be directly exploitable, they still represent areas where the system's security could be improved to reduce the overall risk.

** Please note that these definitions are of our own making and professional judgment and not official, as PCI DSS did not define them in the standard.

Still, we understand "exploitable vulnerabilities" to mean the same as it has before in prior versions of the standard, and v4.0’s guidance column in the DSS explains that you can use your vulnerability risk assessment process—as outlined in requirement 6.3.1—to ensure that those that pose the highest risk to your organization will be remediated more quickly.

PCI DSS v4.0 Requirement 11.4.4 Explained

But according to requirement 11.4.4, you must remediate all discovered security weaknesses—not just the highest risks. Insofar as how to do so, there are basic details in other requirements:

Requirement	Detail
Requirement 6.3.1	What It Addresses: Requires that you define and manage the risk of each issue identified, including permissible timeframes for corrective action. Vulnerabilities must be assigned a risk ranking based on industry best practices and their potential impact on your organization. At a minimum, this applies to all vulnerabilities considered to be high risk or critical to your environment, but your vulnerability risk assessment process should correct all gaps, regardless of their exploitability or severity, including anything for bespoke and third-party software (e.g., operating systems and databases).
Requirement 6.3.3	What It Addresses: Requires that system components are protected from known vulnerabilities through the installation of applicable security patches/updates. Critical and high-security patches/updates, as identified in line with 6.3.1, must be installed within one month of release. All other vulnerabilities, including medium and low vulnerabilities, are to be treated in line with your organization's risk treatment policy (see requirement 6.3.1).

Requirement

Detail

Requirement 6.3.1

What It Addresses: Requires that you define and manage the risk of each issue identified, including permissible timeframes for corrective action.

Vulnerabilities must be assigned a risk ranking based on industry best practices and their potential impact on your organization.

At a minimum, this applies to all vulnerabilities considered to be high risk or critical to your environment, but your vulnerability risk assessment process should correct all gaps, regardless of their exploitability or severity, including anything for bespoke and third-party software (e.g., operating systems and databases).

Requirement 6.3.3

What It Addresses: Requires that system components are protected from known vulnerabilities through the installation of applicable security patches/updates.

Critical and high-security patches/updates, as identified in line with 6.3.1, must be installed within one month of release.

All other vulnerabilities, including medium and low vulnerabilities, are to be treated in line with your organization's risk treatment policy (see requirement 6.3.1).

So, even if requirement 11.4.4 says that you must complete remediation on all “exploitable vulnerabilities” and “security weaknesses” noted in your pen test report, how you do so will depend on your decided-upon vulnerability management policies—your assessors will examine how well you follow your own set rules.

For instance, if your organization's risk treatment policy allows 6 months for low-risk findings to be corrected, then we as assessors will evaluate your compliance with requirement 11.4.4 as per that policy during our assessment.

Once all remediation is complete, you’ll of course need to have another pen test performed—also called a retest—that will focus on the findings from the original pen test to verify that the exploitable vulnerabilities and weaknesses identified have been corrected.

Though this retest is typically performed by the same entity that performed the original pen test, this is not necessarily a requirement. What is required is that whoever performs the pen test (or retest) is qualified by experience or training and has organizational independence from the systems being tested.

Moving Forward with PCI DSS v4.0

As you do get to remediation, we would recommend all organizations allow themselves sufficient runway to correct all vulnerabilities. So if your vulnerability risk assessment process—as documented in policy in line with requirement 6.3.1—allows for six months to address low vulnerabilities, have your penetration test performed six months before your PCI DSS audit so that you’ll have plenty of time to answer without question that all weaknesses have been corrected which were identified.

But even now that Requirement 11.4.4 is a little clearer for you, you may still have plenty of questions regarding PCI DSS v4.0 and the ongoing transition to the new version. Don’t worry, if so—not only can we offer early insight into a v4.0 assessment, but we’ve also written extensively about different aspects of the standard to help ease your adjustments going forward:

About ERIC SAMPSON

Eric Sampson is a Director at Schellman. Eric began his professional career in 2005 while working as an IT auditor in Philadelphia. Eric executed several critical projects for clients in the areas of information security and Service Organization Controls (SOC) reporting projects. To date, Eric has provided services to clients in the healthcare, information technology, and financial services industries, among others.