As organizations that must follow the Payment Card Industry Data Security Standard (PCI DSS) know, meeting its testing requirements is not easy. One such requirement that organizations struggle with consistently is 11.2.2, which states compliant organizations must "perform quarterly external vulnerability scans via an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC)."
Why is the PCI scanning requirement a challenge? This requirement applies to all types and manner of organizations -- large and small, technically sophisticated and those less so. For a compliance officer at a less technically sophisticated organization, these reports can look like straight-up gibberish. In addition, ASVs have specific requirements about what information they must include in the report and in what format, so reports from competing ASVs tend to have similar content and structure. This is good for driving uniformity among vendors, but also creates a problem: If you don't understand one vendor's report, you're not going to understand them all.
The first step for an organization trying to meet requirement 11.2.2 is hiring an ASV to conduct quarterly scanning. It's important to remember, however, that the PCI Security Standards Council must certify the ASV as a qualified vendor that can perform this scanning. The Standards Council maintains a complete, up-to-date list of these certified ASVs, and organizations should verify that their scanning provider is on that list before establishing a quarterly screening agreement.
The vulnerability scanning exercise ASVs conduct is designed to investigate external-facing devices to determine their overall security profile. It specifically targets vulnerabilities and/or configuration issues on the portion of your payment infrastructure accessible via the public Internet.
It's very possible that during a given reporting cycle, the organization will not pass the first time the scan is run.
Organizations should have a goal of obtaining one "passing" (i.e., compliant) scan report for each quarter in a calendar year. This is particularly important to mention, because PCI requirements mandate four passing scan reports (see the assessment criteria for 11.2.2).
As a result, if you do not pass one or more PCI scanning reports, you won't be compliant. It's very possible that during a given reporting cycle, the organization will not pass the first time the scan is run. Remediation needs to occur in order for the scan to pass, and this can (and should) impact a PCI scanning process schedule. Organizations should schedule scanning activities early and budget enough time to perform remediation and subsequent retesting until they obtain a passing report.
You'd be surprised how many organizations miss a quarterly report (and ensure non-compliance as a result) due to simple logistics. For example, they simply forget to schedule a report, do not realize remediation takes much longer than they've planned for or "bump" remediation in favor of competing priorities.
To remain compliant, organizations are required to have no issues in the "mandatory failure" category or have a "common vulnerability scoring system" (CVSS) base score of 4 or higher. The CVSS is an agreed-upon standard methodology for assigning severity rankings for potential security issues identified during a scan. The "mandatory failure" category (outlined in Table 1, starting on page 15 of the ASV Program Guide) is a subset of vulnerabilities the ASV marks as an automatic failure within the report. It's helpful for organizations to familiarize themselves with this list ahead of time and attempt to minimize any of these issues in their environment.
For compliance professionals who are brought in to manage this process, that means getting that list in front of the engineers and system administrators responsible for configuration of the systems. It also should be made clear to them the consequences of having any of these security issues in the environment.
Disputing PCI scan report findings
Believe it or not, there are some things you can do to maximize your likelihood of a successful scan report. First, organizations need to ensure that the scanning processes' scope includes all aspects of the cardholder data environment (CDE) that are externally accessible. The inverse of this, however, is that you also exclude things that are not externally accessible, such as areas that are segmented from the CDE and can therefore be removed from the scanning processes' scope.
More on PCI DSS compliance
Podcast: Overcoming PCI DSS compliance barriers
Five strategies to streamline the PCI audit process
Organizations can also dispute findings and false positives -- items that are not applicable to their specific environment. Organizations are required, however, to justify these false positives from a technical standpoint, and in writing. If the compliance team is managing this effort, bring engineers into the loop to provide that feedback and ensure appropriate documentation.
Organizations can also dispute the severity of a finding, including the CVSS base score. This is difficult, however, since the National Vulnerability Database assigns many vulnerabilities a CVSS base score that ASVs usually consider immutable.
Lastly, a given vulnerability can be disputed on the basis that you have a compensating control in place to mitigate the issue. Organizations need to note that the ASV does not allow disputes to be carried over from report to report, so organizations should retain a record of their evidence and justification for a dispute, since it will come up again in subsequent scans.
The point is that organizations have options when it comes to these reports. They just need to be educated on what the process entails, loop in technical resources early and enlist their help in that process. By being disciplined and organized in how you approach the requirement, you can minimize the scanning requirement effort and maximize your likelihood of achieving a successful result.
Ed Moyle is a founding partner at New Hampshire-based information security and compliance consulting firm SecurityCurve. Moyle previously worked as a senior manager with Computer Task Group Inc.'s global security practice and, prior to that, served as a vice president and information security officer at Merrill Lynch Investment Managers.
This was first published in November 2012