Your Guide to PCI Scannin Success

How Network Scans Protect Credit Card Data and Ensure Compliance with PCI DSS

The PCI Data Security Standard (PCI DSS) requires businesses that store, process or transmit credit data to regularly scan their external networks to detect possible vulnerabilities to intrusions. These scans are a part of PCI DSS compliance testing and must be done by an Approved Scanning Vendor (ASV) at least quarterly, as well as after any major change to the business environment.

Approved Scanning Vendors, often referred to as ASVs, are companies certified by the PCI Council to validate a company’s compliance with the Payment Card Industry Data Security Standard.

PCI Standard 11.2.2 Requires External Vulnerability Scans

The PCI DSS requires vulnerability scanning of external (internet-facing) system components that lead to or are part of the cardholder data environment. This is because external networks are most susceptible to compromise by hackers trying to access credit card data. PCI Requirement 11.2.2 states these scans must be done “quarterly” but In reality, this means at least every 90 days, not just once a quarter.

Organizations should create an internal process for staying current with PCI scanning requirements every 90 days. In addition, any changes made in a scanned environment before 90 days, should be tested with a new scan to ensure that there are not any new security vulnerabilities.

If your organization uses a third-party service provider for hosting, they must be able to provide you with evidence of compliant ASV scans of your hosted environment. Note that you are responsible to ensure that all of your organization’s Internet-facing IP ranges and domains have been scanned by the provider when it underwent ASV scans.

The Benefits of External Vulnerability Scanning

The PCI Council states that external vulnerability scans are “an indispensable tool” to be used in conjunction with a vulnerability management program. Scans can identify misconfigurations of websites, applications, and other information technology components with Internet-facing IP addresses.

The Vulnerability Scan Process In Brief

Generally speaking, these are the steps that take place start to finish.

  1. Scoping – The organization Identifies the external-facing IP addresses, domain names and systems that are within (or provide a pathway to) the Cardholder Data Environment. The organization may exclude from the scope only externally accessible systems that are physically or logically segmented from the Cardholder Data Environment. Remember: It is ultimately the scan customer’s responsibility to establish the scope.
  2. Scanning – The ASV will conduct a discovery process to confirm the scope provided by the customer. If undiscovered domains or components are found, the customer must attest that they are out of scope or redefine the scope to include them. After the scan, the ASV will detail all potential vulnerabilities. A severity level of 4.0 or higher is an automatic fail.
  3. Remediation – The scan report will describe each vulnerability, provide a prioritized risk rating of “High” or “Medium” severity, identify the associated issues and provide guidance on how to fix or patch vulnerabilities. For each failing vulnerability, the organization must implement a solution or dispute the finding.
  4. Retesting – The ASV must perform a re-scan that results in a passing scan.
  5. Final Reporting / Attestation – The organization and the ASV must attest that the scan was performed against the correct scope and was carried out in accordance with the ASV Program Guide.

Dealing with Scan Results

A scan can result in:

  1. A Passing Scan
  2. A Failing Scan that is Disputed
  3. A Failing Scan that is Remediated

Passing Scan – An organization that passes the vulnerability scan should submit the completed ASV report to the organization’s acquirers and/or Participating Payment Brand, as directed.

Failed Scan – Disputed – Organizations can dispute noted vulnerabilities. Common areas for dispute resolution include false positives, exceptions in the scan report, incorrect scans or inconclusive findings attributed to scan interference. The ASV must clearly inform their customer of the process for disputing scans. The organization needs to provide reasonable evidence to the ASV to prove that the vulnerability is a false positive or not applicable. The ASV analyzes that information and decides if it is a false positive or not. Organizations could also present compensating controls to mitigate a risk. Again, the ASV needs to assess and agree with the solution to create an exception in the scan results.

Failed Scan – Remediated - For non-disputed issues that lead to failed scans, the organization works to resolve vulnerabilities. The ASV can provide guidance but cannot implement any changes because the ASV needs to maintain independence. The ASV can rescan the environment until the issue is fixed but the organization is the one that needs to fix it. The procedure to work with an ASV on failed scans is outlined in the ASV Program Guide on the PCI website.

Need help with PCI Compliance?

 

Learn more about our services

 

Need help with PCI Compliance?

ERMProtect's Weekly Newsletter

Get a curated briefing of the week's biggest cyber news every Friday.

Stop Phishing Attacks with ERMProtect's Security Awareness Training

Turn your employees into a human firewall with our innovative Security Awareness Training.

Our e-learning modules take the boring out of security training.

Intelligence and Insights

Effective Cyber Security Awareness Training for Employees in 2020

Effective Cyber Security Awareness Training for Employees in 2020

Cybersecurity is no longer a technical problem. It’s a people problem. And ensuring that people have the know-how to defend themselves and their organization against threats is a critical component of a robust cybersecurity program …
SOC 2 - Value Added Proposition

What is the real value of SOC 2 Compliance?

Major companies that outsource aspects of their data information operations can’t risk using vendors who don’t rigorously protect sensitive information. That’s why many organizations now demand that their vendors become SOC 2 compliant, a designation …
PCI DSS v4.0 – What you need to know now

PCI DSS v4.0 – What you need to know now

Some clients are already asking what to expect when the next version of the Payment Card Industry Data Security Standard is released next year. That’s no surprise, since decisions that are being made now by …