PCI DSS confusion: These are not the patches you are looking for!

Or, are they?

In the course of our PCI DSS-related work, we’ve noticed one issue that often causes some confusion for many clients:  Do missing operating system or application patches need to be applied, even if those missing patches are only flagged by the internal vulnerability scan as medium or low risk? It’s an important question which needs to be answered carefully in order to ensure that the client remains compliant with the DSS, without incurring unnecessary cost and overhead.

The short (and useless) answer is that they may do!  For the longer (and more useful) answer read on.

Patching activities and vulnerability remediation activities can overlap, however they are actually quite separate beasts.  Let’s consider patching first:  From a purely patching perspective, PCI DSS requirement 6.2 states that you should:

“Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor- supplied security patches. Install critical security patches within one month of release.”

The testing procedures and guidance for this control go on to state that:

• “Applicable critical vendor-supplied security patches are installed within one month of release.”

   

• “All applicable vendor-supplied security patches are installed within an appropriate time frame (for example, within three months).”

This means that, regardless of any internal vulnerability scan findings, all systems must have vendor-supplied security patches installed within a month (for critical patches) or “an appropriate time frame” (for all non-critical patches).

Now, let’s consider remediating vulnerabilities that were discovered as a result of a vulnerability scan, using a tool such as Nessus.  From an internal vulnerability scan perspective PCI DSS requirement 11.2.1 states:

“Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify all “high risk” vulnerabilities are resolved in accordance with the entity’s vulnerability ranking.“

This means that in order to meet requirement 11.2.1, an organisation only has to remediate “high risk” vulnerabilities identified in the internal vulnerability scan results.  And here’s where the confusion lies:  Even though requirement 11.2.1 only mandates remediation of high-risk vulnerabilities,  lower-risk findings will still need to be addressed if they result in non-compliance with other PCI DSS requirements.

Let’s consider two examples:

1. If a vulnerability scan identifies that a system is missing medium-risk vendor-supplied security patches, these patches must still be applied in order to be compliant with PCI DSS requirement 6.2, as described above. The fact that a vulnerability scan identified the issue and reported it as only a medium risk has no bearing as to whether or not the patches must be applied.
   
   
2. Another example is the internal vulnerability scan finding that is sometimes produced by Nessus: “SMB signing not required”. This is a medium-risk finding and as discussed above, medium-risk findings do not have to be fixed to meet requirement 11.2.1. However this finding is still relevant as it indicates an issue with the application of an organisation’s system configuration standards on the identified systems. PCI DSS requirement 2.2 deals with system configuration and hardening standards and it states:  “Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.”  SMB signing is an industry-accepted best-practice, as described in this document from Microsoft and so this vulnerability would need to be addressed.