Evan Schuman's StorefrontBacktalk

Jeff Hall has been involved in information security for more than 30 years and has been a QSA since 2007.

The current PCI DSS quarterly vulnerability scanning requirement is nothing short of ridiculous, given the fact that most operating system vendors and some application software providers release patches at least monthly. (OK, it isn’t so ridiculous if your goal is to guarantee a constant security hole for the convenience of cyberthieves. For those of you whose goals are other than that, though….) When Visa published their Customer Information Security Program (CISP) back in 2002, they set the bar of quarterly vulnerability scanning because it was believed to be the most efficient and cost effective approach for providing security. This practice has continued unaltered even when the CISP was converted to the PCI DSS in 2007.

Over the past decade, Council officials, retail IT people and QSAs have begun to question the quarterly requirement, but the fear was that retailers would simply not do it, as they could never cost-justify it, particularly for Level 4 retailers. The council has always had a strong pragmatic nature, weighing the effectiveness of guidelines against what they could realistically hope for retailers to do. This is not unlike the practicality compromises that the U.S. Department of Agriculture’s food pyramid (and now the food plate) did for years, where it wasn’t the ideal diet, but it was pushing American consumers in the right direction. If it was better than what they currently doing, it was seen as a win. The Council thinks similarly. So what’s different today? Why should this change? The fact is that the facts of vulnerabilities have changed over the last decade.

The first fact that changed was the creation of the National Vulnerability Database (NVD) by the US Department of Homeland Security (DHS), US-CERT and the National Institute of Standards and Technology (NIST). The NVD tracks all vulnerabilities regardless of the entity that discovered the vulnerability so that they are tracked consistently. But by far the biggest change was the development of the Common Vulnerability Scoring System or CVSS for the NVD. The CVSS determines the severity of a vulnerability based on a number of factors including a vulnerability’s exploit metrics, impact metrics, environmental metrics and the ability of the vulnerability to modify itself over time. With a complete database of vulnerabilities scored for their threat, we can now determine the likelihood of a vulnerability with a CVSS score of 4.0 or greater.

With that in mind, you can query the NVD looking for vulnerabilities that have a CVSS score of 4.0 or greater (the PCI DSS definition of high, severe or critical vulnerabilities remember) and you will find 52,503 vulnerabilities as of July 1, 2013 out of a total of 56,303. That is a whopping 93 percent of all vulnerabilities meeting the PCI DSS criteria of requiring patching or being mitigated while the patch is tested. When 9 out of 10 vulnerabilities are deemed high, severe or critical, what is the statistical likelihood that a month goes by without something requiring patching? Close to none. If you think this is some new statistical anomaly, think again. I have periodically queried the NVD over the last four years and the percentage of vulnerabilities with a CVSS score greater than 4.0 has consistently stayed above 90 percent.

As a refresher for everyone’s memory, PCI DSS requirement 6.1 requires that “high-priority systems and devices are addressed within one month, and addressing less critical devices and systems within three months.” In addition, requirement 11.2.3 requires that a QSA confirm that vulnerability scans are conducted until all vulnerabilities with a CVSS score of 4.0 or greater are no longer discovered. Given the aforementioned statistic, the likelihood of any one month period having no vulnerabilities with a CVSS of 4.0 or greater is very slim if not nonexistent. As a result, if an organization is not conducting at least monthly vulnerability scanning the likelihood that they have a high, severe or critical vulnerability in their cardholder data environment (CDE) is very high and those vulnerabilities need to be patched as soon as possible.

What detractors of the standard will point to is the fact that the statistic also virtually assures that it is impossible to get a “clean” vulnerability scanning report, i.e., one that does not contain a vulnerability with a CVSS score of 4.0 or greater. This was addressed several years ago by the Council with a clarification to QSAs in their training. If a QSA could prove that an organization’s patching process was reliable, unpatched systems’ risks were mitigated while they remained unpatched and the QSA was willing to accept the risk presented by this approach, then the one month patching requirement was allowed to be ignored.

This clarification was the result of QSAs and participating organizations (PO) educating the Council on the fact that today’s

testing and quality assurance processes make it almost impossible to get patches into production in a month or less for all devices in a CDE. Although the one month standard remains, it remains for organizations that cannot prove that their patching processes are reliable and that they mitigate unpatched vulnerabilities.

Even without the statistical analysis, a lot of retailers have come to the realization that quarterly scanning just does not provide them the peace of mind they want. As a result, they have ditched a quarterly schedule and have been conducting vulnerability scanning of their CDE monthly, weekly or, in some instances, daily. Their rationale is that the vulnerability scanning vendors are constantly updating their detection signatures and will flag vulnerabilities, particularly zero-days, long before a vendor has a patch. This allows them to get a “heads up” and mitigate before they have a breach.

Hence, quarterly vulnerability scanning today really is a silly idea and it needs to change.

Jeff can be reached at pciguru@gmail.com.