If you have found your way to this article, then likely you have to satisfy the following PCI DSS requirement (current PCI DSS version standard is 3.2.1):

11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

An Approved Scanning Vendor (ASV) is an entity that can perform ASV scans that will validate adherence to the external scanning requirement as per PCI DSS Requirement 11.2.2. The ASV must be approved by the PCI SSC and will then be added to the list of Approved Scanning Vendors.

Quarterly external vulnerability scanning must be performed by a PCI SSC Approved Scanning Vendor (ASV). This is because external networks, which are part of the PCI DSS scope, are exposed to a greater risk of compromise by malicious users (greater probability of attacks, greater number of potential attackers, etc.). So, a strong scanning program ensures you can address security vulnerabilities in a timely manner.

Obtaining ASV PASS scans on a quarterly basis in the right way is one of the most pressing and worrisome obligations that a PCI DSS compliance entity has to accomplish. There are several ambiguous points which can cause mistakes and confusion. We’ve outlined the two most common ones here.

To Whitelist or not to Whitelist - That is the question

External targets of an entity can be reached from public source IPs. In some cases from any IP , but more often than not only from specific IP addresses. If that’s the case, the ASV scan could result in: FAIL ASV scan (e.g. due to scan interferences), incomplete ASV scan (e.g. due to host(s) detected as not alive), etc.

So, should the scanned entity whitelist ASV scanner IPs?

ASVscan_castle

The response isn’t just a Yes or No.

ASV scanners must be allowed to perform scanning without interference from “active protection systems”. “Active” here means security systems that dynamically modify their behavior based on information gathered from non-attack network traffic patterns. These systems include IPS, WAF, QoS, and even Firewalls that block IP addresses upon detection of a port scan (not static rules).

What about Firewalls and their static rule?

In general, static rules on network devices don’t need to be changed in order to perform an ASV scan in a PCI DSS compliant way.

If ‘host not alive’ or ‘scan interference’ issues persist after whitelisting the ASV scanner IPs on active protection systems, a solution exists. Then the configuration of the ASV scan and devices can be performed in a way that the host is found as alive and without any interferences. This usually can be done with scan/device temporary settings, which include:

  • Customize TCP discovery
  • Customize UDP discovery
  • Enable ICMP
  • Change firewall closed port behavior from drop to reject

If the above is not possible, there is another way: The ASV customer has to provide the proper evidence to support their assertion that the scan was not actively blocked. And if the ASV agrees that the scan was not actively blocked, it may determine that an additional scan is not necessary. This means involving ASV support (likely each quarter).

Quarterly ASV scans and Remediation scans – When and Why

It’s important to understand what a quarter is. By definition, a quarter refers to the division of a year into four equal parts. So, the following are all valid ASV scan quarters in a 12-month period:

  • Cycle 1:
    • From January to March
    • From April to June
    • From July to September
    • From October to December
  • Cycle 2:
    • From February to April
    • From May to July
    • From August to October
    • From November to January (next year)
  • Cycle 3:

    • From March to May
    • From June to August
    • From September to November
    • From December to February (next year)

The first quarter is the quarter in which an entity performs the first ASV scan.

A PCI DSS compliant entity has to obtain 4 PASS ASV scans on a quarterly basis. This means that if your ASV scan results in a FAIL, you will have to perform the relevant remediation ASV scan in the same quarter of the failed ASV scan until a pass scan is achieved.

Let’s see an example to clarify. Consider we have the following quarters:

ASVscan_calendar_Advantio

The current ASV scan quarter is in red (Jul-Sep) and:

  1. We perform the first quarterly scan (first black-red circle) and it results in PCI FAIL.
  2. Then we perform a remediation scan (second black-red circle) and it again results in a FAIL.
  3. If we fix the vulnerabilities discovered, the following two cases can be observed:
    1. We perform the remediation scan again within September (third black-green circle). This remediation scan is valid for the RED quarter as PCI PASS ASV scan.
    2. We perform the remediation scan again in October (fourth red-green circle). This remediation scan is NOT valid for the RED quarter thus leaving a quarter without a PASS ASV scan, and the entity could be found not PCI DSS compliant.

Reaching PCI DSS Compliance

For any entity wishing to become or maintain their PCI DSS compliance and certification, it’s important that they understand PCI DSS standards, guidelines and best practices. This is in addition to understanding each related industry standard and its best practice. Yet, this will not be enough. Experience gained from encountering and solving issues is invaluable. It outlines each step an entity has to perform to reach PCI DSS compliance.

Advantio has been recognized as Europe’s second largest QSA provider by VISA. Our security team’s certifications include PCI QSA, PA DSS, ISO/IEC 27001 Lead Auditor, CISSP, CISA, CISM, OSSTMM and CSSLP. Our PCI DSS experts are highly skilled and always up to date when it comes to the new versions of PCI DSS standards.

Contact us if you need help or consultation on ASV scans.

Contact us

I am a Computer Science Engineer and a Security Consultant at Advantio.

In Advantio I apply my innate curiosity, enthusiasm, methods of organization in the studying and working, and strong analytic competencies. I also can draw on my background in software engineering, data processing, network and systems architecture as well as Information Security. My information security background includes consultancy and audit, training, SSDLC and policy development among others.

Certified as Qualified Security Assessor (QSA) by PCI Security Standards Council.