“Passing” Vulnerability Scans

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.

11 Responses to ““Passing” Vulnerability Scans”

  1. May 25, 2016 at 12:36 PM

    Hi, we have public faced web sites sitting in DMZ and other public IP addresses connecting stores to ISP (not for web sites). Should the external vulnerability scan ONLY scans the public faced web sites, while external penetration test scans the web sites AND the public faced IP addresses?

    • May 25, 2016 at 2:50 PM

      Public facing is public facing. So your ASV scans should be picking up all publicly facing assets (i.e., all devices with public IP addresses) not just Web sites.

  2. September 15, 2010 at 3:17 PM

    Your approach is a good one… but 6.1.b addresses critical security patches within 30 days. Most of the vulnerabilities that I see are not due to a critical security patch, several are due to ssl key encryption strength and/or expiry date and mis-configuration issues. With these types of issues, merchants can setup plans to remediate through their change management process without affecting production and have up to the quarter to address.

    Furthermore, a merchant would have a finding if they do have a quarterly scan (before remediation) that has a vulnerability present for a critical patch that was released more than 30 days ago; as they would not be meeting 6.1.b.

    Also with the new standard being released in a few months, merchants will be able to perform a risk analysis on each vulnerability and will be able to potentially accept risks. What are your thoughts on this one guru?

  3. 4 dgonzalez_IT
    February 18, 2010 at 1:56 PM

    Patch Management was one of the most difficult things I had to deal with when I went through the PCI process with a past employer and I can’t remember how many times I was questions why I had so many scans setup to run. Reason being was because I had my vulnerability scanner set to scan daily for production servers, then a weekly for servers plus the rest of the critical network components, then a monthly scan of everything. It might have seemed like over kill to upper management, but it really gave me clear visibility of the state my patching and vulnerability management was in. It painted a clear picture of how my systems where yesterday, or a week ago compared to the current day and why and what vulnerabilities surfaced if any.

    So many organizations forget how important patching systems are. Great read as always!

  4. February 15, 2010 at 3:37 PM


    I think you are referring to the card brands’ Web site, not the PCI SSC Web site. The card brands, in particular Visa, list service providers that are PCI compliant. However, those are service providers that actually provide card processing services. In order to be on that list, you must pay Visa a fee as well as register as a card processing entity.

    I am not aware of any list of certified managed service providers that is maintained by the PCI SSC.

    PCI Guru

  5. February 14, 2010 at 11:44 PM

    Hi PCI Guru,

    I have a question, I asked the PCI Council and got no answer maybe you can help, sorry if its too left field.

    As a reseller of Level 1 PCI DSS certified manged services, could the company be listed on the PCI councils website as PCI compliant? despite the fact that we dont actually touch / store / process credit cards ourselves, but rather sell certified managed services (this function is provided by our supplier).



  6. February 22, 2010 at 5:19 AM

    What you recommend we conduct as part of our vulnerability scanning process. Our methodology has us conduct our reconnaissance work of MySpace, Facebook, LinkedIn, etc. then not as part of our penetration testing. This approach allows our penetration testing to be strictly focused on compromising the network and systems. We believe this approach is more like the real world.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


February 2010

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,386 other followers

%d bloggers like this: