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.

Intelligence and Insights

Mobile Application Security - Why You Should Focus On IT

Mobile Application Security – Why You Should Focus On IT

Mobile applications ease every day and workday tasks. Yet, they pose vulnerabilities and threats that must be addressed. This article provides guidance on how penetration testing and other best practices will help you secure mobile …
How Hackers Crack Passwords and What You Can Do About It

How Hackers Crack Passwords and What You Can Do About It

When a password is the only thing standing between hackers and data, you can count of them to capitalize on weak passwords. Here’s how you can strengthen your passwords to avoid becoming the victim of …
Understanding the Key Components of a SOC2 Report

Understanding the Key Components of a SOC2 Report

SOC 2 audit reports follow a basic outline. In each report, you will find the vendor’s management assertion, the independent auditor’s report, the vendor’s description of its system, and a listing of controls tested …