More Understanding PCI DSS Scanning Requirements

Recently, Tenable published a blog, Understanding PCI DSS Scanning Requirements, which provided an overview of the three distinct network vulnerability scanning requirements found in the Payment Card Industry Data Security Standard (PCI DSS). The blog primarily focused on using Tenable.io for your external network vulnerability scanning to meet the PCI DSS 11.2.2 requirement. [Tenable, with Tenable.io, is an Approved Scanning Vendor (ASV) certified by the Payment Card Industry Security Standards Council (PCI SSC) to perform external network vulnerability scanning of a company’s perimeter, or Internet facing systems.]

There is often confusion about the vulnerability scanning requirements for PCI, most likely because there is so much focus on the external vulnerability scanning. Why? External scanning is the only one of the three scanning requirements that must be performed by an authorized third party (an ASV). And the vast majority of “small” merchants and service providers are allowed to conduct their own compliance validation by (1) submitting the appropriate Self-Assessment Questionnaire (SAQ) and corresponding Attestation of Compliance (AoC), and (2) submitting evidence of four quarterly (passing) external vulnerability scans performed by an ASV.

In this blog, I will focus on the other two network vulnerability scanning requirements: (1) internal network vulnerability scanning, and (2) internal/external network vulnerability scanning after “significant changes” to your cardholder data environment (CDE).I will also address how you can meet these requirements with either Nessus Professional, Nessus Manager/, Tenable.io™, SecurityCenter™ or SecurityCenter Continuous View™.

In PCI terms, there are two types of entities: your company is either a Merchant (accepting debit/credit cards for the payment of goods and services you provide) who “transmits, processes, or stores, cardholder data,” or a Service Provider (a catch-all category that includes any other company that supports the payment card authorization & settlement and post-settlement activities, or more simply could “impact the security of [your customers’] cardholder data.”)

At a minimum, if you are a Merchant, and you either validate compliance with a QSA company (producing a Report on Compliance or RoC) or you self-assess using either SAQ-C or SAQ-D, then you are required to perform quarterly internal vulnerability scans and rescans as needed to resolve all “high-risk” vulnerabilities in your internal network.

If you are a Service Provider, you are required to perform quarterly internal vulnerability scanning regardless of whether you validate compliance with a QSA or by way of a Self-Assessment Questionnaire.

Note: Even if your payment processing is performed primarily by a third party and/or your systems are hosted in the cloud, you are still responsible for validating compliance with the PCI DSS, which includes responsibility for vulnerability scanning as described above. If you’re not sure if this applies to you – ask! Don’t assume that the third party company you’ve engaged is doing it for you.

If you’ve determined that you need to perform internal vulnerability scanning, let’s look at the details of that requirement.

Internal vulnerability scanning (PCI DSS 11.2.1)

The PCI SSC provides a definition for an internal scan:

Refers to a vulnerability scan conducted from inside the logical network perimeter on all internal-facing hosts that are within or provide a path to an entity’s cardholder data environment (CDE).

The PCI DSS section that deals with network vulnerability scanning is requirement 11.2:

11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

The detailed requirement for internal vulnerability scanning states the following:

11.2.1 Perform quarterly internal vulnerability scans and rescans as needed, until all “high-risk” vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel.

There really isn’t much detail provided in the PCI DSS about what constitutes a valid, or qualifying internal network vulnerability scan – they pretty much have left that to the scan vendors to determine what is appropriate. The few detailed requirements are actually found in the PCI DSS Approved Scanning Vendors Program Guide which provides the following recommendations:

• Applying the detailed requirements for external vulnerability scanning found in the ASV Program Guide to internal vulnerability scanning programs:
  • Be Non-disruptive – no exploitation, denial of service, or degradation of performance
  • Perform Host Discovery – make a reasonable attempt to find all live systems
  • Perform Service Discovery –perform a port scan on all TCP ports and all common UDP ports
  • Perform OS and Service Fingerprinting – primarily used to tailor additional vulnerability discovery
  • Have Platform Independence – scanner must cover all commonly used systems
  • Be Accurate – confirmed vulnerabilities must be reported as well as suspected or potential vulnerabilities

The biggest difference between internal vulnerability scanning and external vulnerability scanning is what the PCI DSS requires in terms of a “passing” scan

The biggest difference between internal vulnerability scanning and external vulnerability scanning is what the PCI DSS requires in terms of a “passing” scan. For external scans all vulnerabilities rated “Medium” and higher must be remediated; but for internal vulnerability scanning only “High” or “Critical” vulnerabilities have to be remediated in order to adhere to the requirement.

The risk ranking for internal vulnerability scanning is determined by you the customer

It is also worth noting that the risk ranking for internal vulnerability scanning is determined by you the customer, in accordance with requirement PCI DSS 6.1 which requires you to “establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as 'high,' 'medium,' or 'low') to newly discovered security vulnerabilities.” The biggest advantage here is that you have the opportunity to take an actual risk-based approach to the overall security of your internal network, which means you can take into account limited access, internal segmentation, likelihood of attack from the Internet, and so forth.

There is also a handful of special “automatic failures” for external vulnerability scanning that in some cases do not apply at all to internal scan results (e.g. open access to databases from the Internet or unrestricted DNS zone transfers).

Vulnerability scanning after significant changes (PCI DSS 11.2.3)

The third type of vulnerability scanning ... is when significant changes occur to the network environment

The third type of vulnerability scanning required by the PCI DSS is when significant changes occur to the network environment, particularly the cardholder data environment. The PCI DSS does not require that these scans be performed by an ASV (for external scanning), only that they are performed by qualified personnel.

What constitutes a significant change? The PCI DSS offers this guidance:

The determination of what constitutes a significant change is highly dependent on the configuration of a given environment. If an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment, then it could be considered significant.

Scanning an environment after any significant changes are made ensures that changes were completed appropriately such that the security of the environment was not compromised as a result of the change. All system components affected by the change will need to be scanned.

There is certainly not universal agreement on what constitutes a “significant change” to your environment, but things such as adding systems or system components, updating OS/application versions, applying patches, changing access rules, or adding new logic or functionality are all worthy of consideration. Tenable would suggest erring on the side of caution if for no other reason than the fact that you are allowed to perform unlimited scanning (e.g. there is no additional cost for additional scans performed).

How Tenable solutions meet these scanning requirements

Any Tenable product may be used to execute vulnerability scans that meet both the internal and scan-after-significant-change requirements found in PCI DSS 11.2.

Tenable.io VM, Nessus Professional and Nessus Manager come with a scan policy template that is acceptable for use in meeting the PCI DSS 11.2.1 Internal vulnerability scanning requirement.

This scan policy template provides the minimum functionality required for an internal vulnerability scan; namely, a comprehensive scan of all TCP ports and common UDP ports as well as omitting things like Denial-of-Service attacks or certain conditions that are exclusive to external vulnerability scanning (that our Tenable.io VM solution provides).If you are a SecurityCenter or SecurityCenter Continuous View customer, there is a similar scan policy template available for use with your deployed Nessus scan engines.

Customers who use Nessus Manager or Tenable.io VM have the added benefit of being able to deploy remote Nessus scan engines to geographically diverse locations such as all of your retail stores or regional offices. Effective vulnerability scanning of remote retail locations has always been a challenge for merchants subject to PCI adherence, but with Tenable.io VM there is no longer the need to attempt internal routing of scan engines and results – you simply manage it all from the cloud.

Whether you are using Tenable.io for your external scanning for PCI today, or you are a long time user of Nessus or SecurityCenter for internal scanning, the good news is that you can use the Tenable solutions that you already love to meet all of your PCI vulnerability scanning requirements – inside, outside, and all over the world.

For more information:

• Visit the PCI solutions page
• Contact your Tenable Sales Manager
• Join the discussion at the Straight Talk about PCI Tenable forum