Gartner Blog Network


On PCI DSS and Scanning

by Anton Chuvakin  |  December 16, 2011  |  2 Comments

PCI DSS and vulnerability scanning are maybe not brothers, but definitely close relatives. PCI DSS mandates that scanning actually happens on schedule, while vulnerability assessment helps find the holes  that attackers may exploit to steal the card data. So, this post is a reminder about the topic in general as well as about the fact that PCI DSS 2.0 tweaked how vulnerability management should happen in particular.

First, internal scanning was – how should I put it? – lagging a bit across merchants. Yes,  it was just as mandatory, but while merchants all had their ASV reports prepared for external scanning every quarter, the scans of actual card processing systems on the inside were not as aggressive (wait..did I just call a vulnerability scan once a quarter “aggressive”? Woe be onto me…). By the way, it is a really good idea to do “quarterly” scanning more often as it allows you to avoid surprises and gives you more time to fix, rescan and obtain a passing report.

Second,  if periodic (i.e quarterly) scanning was performed, scanning after major network changes (yes, just as mandatory) was lagging even further behind. What is a major change? DSS does not go into details here, but one can use – gasp! – common sense for figuring this out: if new systems or new services were exposed to hostile networks, it was a major change for sure. If processing systems were moved around on the network, new ones deployed or network ACLs changes, it probably was as well (ask you QSA maybe?)

DSS 2.0 cleans up that language. Now Req 11.2.1 reminds that a merchant should “perform quarterly internal vulnerability scans”, while Req 11.2.3 reminds to “perform internal and external scans after any significant change.”

Third, and possibly most important: internal scans now also have at passing grade! In the past, external scans must have no vulnerabilities with CVSS base score above 4.0, but there was no standard for the internal scans. And now  there is: “Review the scan reports and verify that the scan process includes rescans until passing results are obtained [A.C. – presumably this implies that they are using an ASV tool that has a pass/fail indicator], or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.” (testing procedure 11.2.1.b)

By the way, I am hearing that some organizations use two different tools for internal and external PCI scanning. Do you think this is logical? All major vulnerability assessment vendors are ASVs now (with the sole exception working towards this goal) and so reasons for picking an ASV tool for external scanning and another for internal scanning seems like a recipe for a lot of data integration efforts, manual report correlation and other totally unnecessary analytics.

As a reminder, next quarter I will publish three exciting documents about vulnerability assessment and vulnerability management, each longer than the other two (no, not really Smile)

Previous vulnerability management related posts are:

  1. On Scanning “New” Environments that covers scanning virtual, cloud, mobile and other unusual and emerging IT environments
  2. On Vulnerability Prioritization and Scoring that talks about prioritizing the vulnerabilities for remediation
  3. On LARGE Scale Vulnerability Management that asks a few useful questions about large deployments.

Additional Resources

Category: pci-dss  security  vulnerability-management  

Tags: pci-compliance  pci-dss  vulnerability-assessment  vulnerability-management  

Anton Chuvakin
Research VP and Distinguished Analyst
8 years with Gartner
19 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio


Thoughts on On PCI DSS and Scanning


  1. Andrew Mason says:

    To be honest, it would be nice to see a requirement of certification for internal scanning as our experience has shown this to be lacking in quite a few areas, especially where a QSA is not required for sign off.

    The majority of vulnerabilities our penetration testing team find would have been identified by the utilisation of an internal vulnerability scanner so as well as ticking a PCI box, it would be good security practice.

    heres hoping!

  2. Thanks for the comment. I’d second the “here’s hoping” sentiment, if your pentest reveals glaring internal holes, that pretty much means that the merchant was negligent with internal scanning…



Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.