Seeing a red “X” on your quarterly scan report can be a disheartening experience. It sounds worse than it actually is. The majority of merchants who are given a red “X” are not in danger of a breach or compliance shutdown – they’re failing a checklist item for which an answer is already known. The key is determining which of three buckets your failure fits into before making any changes.
Why scans fail more often than they pass
Verizon’s 2019 Payment Security Report showed us most companies don’t maintain full PCI DSS compliance, often because meeting the standard’s ongoing requirements is a tall order. Take the asv scan. If you’re failing one every quarter, then A) the scan returned a false positive, and you don’t need to patch anything, B) your scanning tool failed to include one or more required public IPs in the scan, so you need to update your tool and rescan, or C) a real vulnerability is there, and you need to patch your system within the 90-day window. You may require an approved vendor to help you resolve these scan fails.
Start with triage, not remediation
Before making any patches, review the report and compare it to your current environment. Check any “vulnerable service X on port Y” discovery against the service you are actually running on that port. ASV scans are automated and automated checks often misread banners, misinterpret software version numbers, and identify products incorrectly (or flag services that have been shutdown for months). If you get a report and immediately start remediation work based on unverified data, you’re going to tweak and upgrade things that were already secure (or not even in production) and still run out of time to fix the true deficiencies before the rescan.
Check your work. Is the IP right? The port? The service? The version number of the service being directly queried? Look it up. Look it all up, in your own asset management records. Then decide what is a false positive (like that workstation management agent that replies on the same port as an exploitable service scan) and what you actually have to upgrade.
The findings you’ll see again and again
After you filter out the noise from your scan results, the findings that remain are pretty consistent from one report to the next. The low-hanging fruit in a vulnerability report is often:
- Outdated or weak versions of TLS and configured cipher suites.
2. Expiring or expired certificates.
3. Default credentials present on some interface.
4. Legacy software and hardware using outdated software.
Detecting old and weak TLS and cipher suites is as easy as running Nmap or SSLyze, and the CVEs attributed to these vulnerabilities are years old at this point. Your fix here is often just a quick restart of the web server or load balancer with a modern configuration in place that disables the older versions of TLS and ciphers you no longer want to use.
Expired certificates are often a low-hanging fruit situation as well. If you don’t have a good system in place to monitor and track all of your certificates, you won’t realize something has expired until a user sees the warning in their browser.
When you run a vulnerability scan on your network and get a hit for default credentials on some service, those two probably aren’t the only ones you have deployed in your network. Fixing that in your report is as easy as changing the password and rescanning to confirm your fix.
Don’t remediate before checking scope
Many merchants face issues at this stage that are not technical but rather related to the coverage. If your scan leaves some public IPs in your environment out of its scope such as your cloud range, a secondary office, or any IPs that have been added since your last scan, you could potentially obtain a clean scan report while not being compliant. Any incomplete IP list that passes a scan is actually a blind spot. Before you start fixing anything, make sure to compare the list of IPs that your ASV scanned with your actual external IPs. If you discover any gaps, work on getting them included in the scan before you take any other steps.
Remediate, request the rescan, and watch the clock
Once you’ve confirmed which findings are real and your scope is complete, fix what needs fixing and go back to your scanning vendor with a documented rescan request. Most ASVs allow rescans within the same 90-day cycle, but that window closes fast if you’ve already used up time on false-positive chasing or scope confusion. You should be able to do those quick-pickup scans on demand and get to resubmission within a day or two. Getting those little problems cleared up and handling fast turnaround rescans keeps the process from grinding to a halt. Once you get a clean result, you’ll receive an Attestation of Scan Compliance, which goes to your acquiring bank as proof you met the requirement for that quarter.
When a scan pass isn’t enough
A passing ASV scan tells you there are no known, externally detectable vulnerabilities on your public IPs at that moment. It doesn’t tell you how an attacker might chain together smaller issues, misconfigurations, or business logic flaws to get further into your environment. That’s what penetration testing is for. If your organization handles a large volume of transactions, has had repeated scan failures tied to the same root cause, or you’re preparing for a higher compliance tier, a pen test gives you the human-led depth that automated scanning can’t. For most quarterly cycles, a clean ASV scan is exactly what’s required. Know the difference so you’re not under-testing when the stakes call for more.
A failed scan is a Tuesday-morning problem, not a crisis. Work the triage, fix what’s real, check your scope, and get the rescan done before the window closes – and next quarter’s report will look a lot less alarming.
