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 )
Previous vulnerability management related posts are:
- On Scanning “New” Environments that covers scanning virtual, cloud, mobile and other unusual and emerging IT environments
- On Vulnerability Prioritization and Scoring that talks about prioritizing the vulnerabilities for remediation
- On LARGE Scale Vulnerability Management that asks a few useful questions about large deployments.
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.