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 any Nessus® or SecurityCenter™ product 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 an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Tenable, with Nessus Cloud, is a PCI ASV.
Scanning after significant changes (11.2.3) may also be performed using any Nessus or SecurityCenter product and should be repeated until all high or medium risk findings are remediated depending on whether they are 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. However, the team doesn’t want to fail anyone – they work closely with customers who need help.
The Tenable ASV service is part of a Nessus Cloud subscription
Our ASV service is part of a Nessus Cloud 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 v2. This policy is one of the scan templates available within Nessus Cloud. 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 an administrative section of the Nessus Cloud for customer review. This administration area is where you:
Review any failed items that must be addressed before you qualify for a compliant ASV attestation from Nessus Cloud
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
This Scan and Submit for PCI ASV Validation video produced by the Tenable Training Department has more detail on how the process of submitting scans to Tenable works.
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.
Our goal is to not fail anyone, but to help them get through the process successfully
To get a few tips on how to successfully submit scans, I talked with Jason Turner, one of our PCI ASV certified team members. Jason made the point several times that although Tenable follows the PCI ASV guidelines, our goal is to not fail anyone but to help them get through the process successfully. 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). 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.
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.
PCI DSS 3.1 SSL changes
Finally, I want to mention some recent SSL changes that likely affect your organization’s compliance with PCI DSS v3.1 and which also impact your scan results.
In April, the PCI SSC released PCI DSS v3.1, largely because NIST determined in April 2014 that the Secure Sockets Layer (SSL) protocol and early versions of the Transport Layer Security (TLS) protocol are no longer acceptable solutions for the protection of sensitive data. The revised PCI DSS v3.1 has been updated based on the PCI SSC definition of “strong cryptography.” Basically, the SSC stated that SSL and early TLS could not be used as security controls in three specific areas to protect payment data after June 30, 2016: the protection of insecure communications protocols (Req. 2.2.3), any non-console administrative access to systems (Req. 2.3), and the transmission of cardholder data over untrusted or open networks (Req.4.1).
Customers can use Nessus or SecurityCenter to detect usage of SSL/TLS in their internal networks and/or their cardholder data environments to assure that your organization maintains compliance throughout and beyond the June 30, 2016 grace period.
The Council also provided special instructions to ASVs to start failing any detected instance of SSL or “early TLS” immediately, but to accept formal risk mitigation or migration strategies through the grace period.
For ASVs like Tenable, this means that for any scans submitted between now and June 30, 2016, we list the usage of SSL V2, SSL V3 and TLS 1.0 as a PCI failure. Up to June 30, 2016, you can submit documentation which demonstrates the presence of a risk mitigation and migration plan as evidence for findings which are listed as failures. After June 30th however, you must update to a later version of TLS. Jeffrey Man’s blog, PCI SSC Announces the End of SSL Usage for the Payment Card Industry, has more details on this change.
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:
PCI Security page
PCI Discussion forum
Nessus Plugins
Many thanks to Jason Turner, Jeffrey Man and Kevin Herrett for their generous contributions to this article.