What is a “passing” scan? The PCI DSS requirement 11.2.b defines a passing scan as a scan that does not report any urgent, critical, or high vulnerabilities, i.e., any vulnerability with a CVSS base score of 4.0 or greater. So what is the big deal and why is a passing scan so difficult to obtain?
The National Vulnerability Database (NVD) maintained by the National Institute of Standards and Technology (NIST) has 40,029 vulnerabilities cataloged from 1999 through the end of 2009. Of those vulnerabilities, almost 94% (37,523) have a CVSS base score of 4.0 or greater. As a result, statistics say that there are going to be times when the vulnerability scan comes back with an urgent, critical or high vulnerability. While requirement 11.2.b allows a minimum of quarterly scanning, requirement 6.1.b requires that all urgent, critical or high patches must be applied within a month. As a result, once a vulnerability is identified by your scan, you essentially have 30 days to apply a patch and you must rescan to ensure that the patch has been applied.
Under a quarterly scanning program, when a non-passing scan occurs, you must now schedule a scan at least 30 days later to prove that the urgent, critical or high vulnerability was patched. Given statistics say that 94% of all vulnerabilities have a CVSS base score of 4.0 or greater, it is highly likely that you will have to scan at least eight times during the year. The four quarterly scans plus four more remediation scans. However, given those previous statistics, it is also highly likely that those four remediation scans will reveal new vulnerabilities meaning that you will have to scan at least four more times. That means at least 12 scans, possibly more. This is why a lot of organizations just do monthly scans.
But, this is not the entire patching story. Most of the time, vendors have a patch within days or a week or two of identification. However, there are instances where vendors have taken months or even years to deliver a patch. As a result, in certain instances, patches may simply not be available from a given vendor. In some rare and bizarre scenarios, we have seen certain patches from vendors remove patches thus reintroducing old vulnerabilities. When systems were reviewed, the system patch records still indicated that all patches had been applied however the vulnerability had reappeared and had to be patched again.
Addressing vulnerabilities can get even more delayed when we talk about packaged software. For organizations running packaged solutions, they typically do not have the option to patch their software within the 30 day window required in 6.1.b. This is because packaged software vendors need to test operating system patches and other system patches with their software prior to telling their customers that the patch is compatible with the packaged solution. In some cases, the software vendor issues their own service packs on a quarterly, semi-annual or other periodic basis that contain compatible system patches as well as any updates to their own software.
This is where the experience of the QSA comes into play. An experienced QSA understands the realities and that scans showing new vulnerabilities are a fact of life. As a result, I recommend the following guidelines to determine if an organization is meeting their PCI compliance obligations regarding patching and scanning.
- Determine that vulnerability scanning, penetration testing and patch management processes are documented. Obtain and review all policies, standards and procedures related to vulnerability scanning, penetration testing and patch management.
- Determine that there is proof that supports that the patch management process works as documented. Proof that a patch management process is working includes any reports from tools such as Microsoft WSUS, Big Fix, Lumension, GFI LANguard, Shavlik HfnetchkPro and the like as well as reviews of system patching records from the systems themselves and the vulnerability scanning and penetration testing reports.
- Determine that the vulnerability scanning and penetration testing processes are functioning by reviewing all available reports from those processes for the PCI compliance reporting period. Confirm that any new vulnerabilities identified are either addressed in the 30 day window or are documented as to why they were not addressed. Determine that rescanning and retesting are performed after any patching has been completed. Remember, only your external quarterly scans need to be done by an ASV. Any other scanning done can be done by qualified internal resources, so you do not have to incur additional costs of an ASV for scans outside of the quarterly scans.
- Review change control records and determine if any significant changes have been made to either PCI in-scope applications or the in-scope networks. If significant changes have occurred, match the completion dates of those changes to vulnerability scans and penetration tests to ensure that scanning and testing was performed after those significant changes were implemented.
- If a vulnerability is not patched, obtain documentation explaining why the vulnerability is not patched, the risk presented by the vulnerability, what has been implemented to mitigate any additional risks presented by the vulnerability and, if possible, when is the vulnerability expected to be addressed. Determine that management has approved that the vulnerability has not been patched and they accept any additional risk presented.
If an organization can provide all of this documentation and proof, in my opinion they are meeting their PCI compliance obligations regardless of what their vulnerability scans and penetration tests document.
PCI Guru 