Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Understanding PCI DSS Scanning Requirements

Note:   This article, originally published in 2015 was updated in August 2017 to reflect both Tenable product changes and also to the PCI DSS requirements.


The Payment Card Industry Data Security Standard (PCI DSS) requirement 11, “Regularly test security systems and processes,” involves running internal and external vulnerability scans. In this article, I’ll describe these requirements, share tips for successfully submitting external scans to your PCI Approved Scanning Vendor (ASV) and talk about changes the PCI Security Standards Council (SSC) announced earlier this year about the Secure Sockets Layer (SSL) protocol that could cause you to fail the scanning requirement.

Who needs to be PCI DSS compliant?

Who needs to be PCI DSS compliant is very clear. From the official PCI Security Standards Council website, PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).

What can be more confusing, though, is figuring out an organization’s assessment requirements. For merchants, there are multiple levels of how to do your PCI reporting, based on the number of credit card transactions processed each year. And to make it a bit more confusing, each credit card brand has its own reporting levels.

PCI requires three types of network scanning

Requirement 11.2 covers scanning. It states that you need to "Run internal and external network vulnerability scans at least quarterly and after any significant change in the network." Scans need to be run by qualified internal or external parties.

Run internal and external network vulnerability scans at least quarterly and after any significant change in the network.

For internal scanning, the testing procedures must verify that four quarterly internal scans took place in the past 12 months and that rescans occurred until all “high-risk” vulnerabilities as defined by requirement 6.1 were resolved. Basically, you can do internal scans with Tenable.io™, Nessus® or SecurityCenter™ and verify the results on your own.

The external scan must be done via an an Approved Scanning Vendor (ASV)

External scans, like internal ones, must be done at least quarterly. The difference is that the external scan must be done via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Tenable, with Tenable.io, is a PCI ASV.

Scanning after significant changes (11.2.3) may also be performed using Tenable.io™, Nessus® or SecurityCenter™ for either internal or external systems.

Submitting external scans to Tenable

Tenable takes being an ASV very seriously. We have a team of PCI ASV certified analysts who apply the external scanning requirements by the book.

The Tenable ASV service is part of a Tenable.io subscription

Our ASV service is part of a Tenable.io Vulnerability Management subscription. To do an external scan for PCI, you must use the pre-built static PCI DSS policy, PCI Quarterly External Scan, that adheres to the quarterly scanning requirements of the ASV Program Guide v3. This policy is one of the scan templates available within Tenable.io VM. Subscribers can run unlimited scans using that policy and when ready, submit scans to Tenable for validation. By clicking Submit for PCI, the scan results will be uploaded to the PCI ASV workbench in Tenable.io VM for customer review. The PCI ASV workbench is where you:

  • Review any failed items that must be addressed before you qualify for a compliant ASV attestation.
  • Dispute any result that you believe is a false positive or that has a Compensating Control associated with it
  • Submit attachments as evidence for a dispute

To pass a PCI ASV attestation, all items (except for denial of service (DoS) vulnerabilities) listed as Critical, High, or Medium (or with a CVSS score of 4.0 or higher) and certain findings that are considered “automatic failure” must either be remediated or disputed by the customer. All disputed items must be resolved, accepted as exceptions, accepted as false positives, or mitigated through the use of compensating controls.

To get a few tips on how to successfully submit scans, I talked with Jason Turner, one of our PCI ASV certified team members. Here are a few suggestions from Jason:

  • Submit your scans 30 days before your submission is due (this is good advice for any ASV you’re working with). If you're using Tenable.io, you can run and submit as many scans as needed with the caveat that you must be able to properly dispute any risks presented as PCI failures. Expect that there will be some back-and-forth conversations and requests for information with your vendor, so don’t cut the deadline too close in case you run out of time. If possible, stagger your quarters away from a calendar quarter, which is often busier for your ASV.
  • Very few scans get PCI ASV attestation without needing some additional information. Don’t worry if your vendor asks you for additional information, and expect the first scan you submit to have the most issues. You’ll learn as you submit more scans to your ASV. To make it easy for customers using Tenable.io to know which dispute needs more information, we recently updated our PCI ASV interface with a new "Information requested" feature.
  • Don’t expect a one-size-fits-all for time to review a submission. Reviewing five findings for example, is very different from reviewing 500. Tenable’s SLA guarantees that we will report back within five days of submission, though we try to be quicker whenever possible.

Resources

If you’d like to learn more about how Tenable helps organizations meet internal and external scanning, as well as other PCI DSS requirements, please see the following resources:

Many thanks to Jason Turner, Jeffrey Man and Kevin Herrett for their generous contributions to this article.