When you’re wading into the external vulnerability scanning requirement of the Payment Card Industry Data Security Standard (PCI DSS), the most frequent question we hear as an Approved Scanning Vendor (ASV) is, “What do I need to scan?”
The real question is, “What don’t you need to scan?”
You need to scan everything, and everything may be more than you think. There are ways you can segment systems to remove them from PCI DSS scope, however, every system that either directly handles cardholder data, or is connected to systems that do, needs to be scanned. This is usually a larger scanning scope than those new to PCI DSS compliance expect.
This mandate comes from the Payment Card Industry Security Standards Council (PCI SSC) and their ASV program. Section “5.5 ASV Scan Scope Definition” of the ASV Program Guide spells out what needs to be included in external vulnerability scans. The ASV Program Guide is, in turn, cited by Requirement 11.2 of the PCI DSS.
The ASV Program Guide stipulates not only that every system needs to be scanned, but also that the scans must target those systems by every avenue that leads to them. This includes all IP addresses, fully qualified domain names (FQDNs), hostnames, etc. If you have systems that can be reached in multiple ways, you’re required to have them scanned by each of those routes.
The ASV Program Guide also states that:
“The scan customer is ultimately responsible for defining the appropriate scope of the external vulnerability scan.”
That may lead you to think, “I’ve got a lot of systems that do the exact same thing. Can I just scan a sample of them?” The guidance in the ASV Program Guide essentially boils down to:
You must scan everything. It’s up to you to tell your ASV everything you have. If you omit scan targets from the list you provide the ASV, you are responsible for any sort of breach that occurs on those systems.
There actually aren’t any passages in the ASV Program Guide that explicitly say, “You can’t sample.” Couple that with the statement that scan customers are responsible for defining scope, and some merchants and ASVs have taken this as license to interpret scoping freely. We respectfully disagree.
The ASV Program Guide uses definitive phrases like, “all external-facing IP addresses,” “all fully qualified domain names (FQDN)” and “the entire in-scope infrastructure.” We take this language at face value. It does not allow for any sort of sampling, or elimination of scan targets that reach the same systems and services.
Why do you need to scan all these targets if they are going to return the same results?
If they all return the same results, that’s great! That’s what you’re demonstrating by scanning all of them. Many times, we’ve scanned systems that were intended to be identical, only to find that they were not. Configuration synchronization may slip (especially if it’s a manual task). Some organizations may not even be aware of some services running.
For example, in a recent scan for a customer with over 475 restaurant locations, we reported at least 22 different combinations of findings. However, all locations were intended to be configured identically.
Similarly, we have a customer with over 600 retail locations, all intended to carry the same configuration. However, a recent scan reported at least nine different combinations of findings. Being aware of and accounting for these differences is a crucial part of these merchants’ PCI DSS compliance efforts.
Another thing to keep in mind is that systems may respond differently when accessed by different channels. As an illustration of how that may look, let’s examine the behavior of YouTube. We can use Google’s own DNS server (8.8.8.8) to find the IP address for www.youtube.com:
$ nslookup www.youtube.com 8.8.8.8
Non-authoritative answer:
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Name: youtube-ui.l.google.com
Addresses: 2607:f8b0:4009:815::200e
172.217.9.46
172.217.9.46
Aliases: www.youtube.comTry visiting http://172.217.9.46. You don’t get YouTube, do you? You get redirected to www.google.com. The fact that this behavior is different than visiting http://www.youtube.com illustrates why scanning needs to cover IPs and hostnames. If we just scanned the IP address, we’d never actually see the content at www.youtube.com. Conversely, if we just scanned www.youtube.com, we wouldn’t see this or any other different behavior.
If you want to see a more detailed display of the redirection, try using curl (output truncated):
$ curl -I http://172.217.9.46
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/So far, we’ve learned that you need to scan every system, you need to scan every path that leads to a given system, and you can’t whittle that list of scan targets down by sampling. What do you do if your environment is large and/or complex? You may look at these requirements for quarterly scanning and be overwhelmed. Trying to fit all of these targets into a single scan and managing rescans of that target list may seem untenable.
There is good news. The PCI DSS does allow for multiple scan reports to be combined to show compliance with the scanning requirement. ASV Program Guide v3.0 contains some clarification on how that process may look. Essentially, this allows for the flexibility to break up scan scope into groups and demonstrate remediation of discovered vulnerabilities with rescans of the affected hosts, rather than the entire scope.
Can I just scan a sample?
To sum it up no, but there is a path forward. Like any security control, you’ll find that planning and careful examination of your network will make the process go much more smoothly. You should be able to develop a strategy to define your scope and execute your scans and rescans successfully. As an ASV and Qualified Security Assessor (QSA), we work with our customers to help them realize that strategy. If you’d like to talk to us about your situation, please let us know.
