vulnerability scanners

The technology and processes behind successful PCI scanning. 

Brand Barney, SecurityMetrics
By: Brand Barney
Likely the most famous requirement of the Payment Card Industry Data Security Standard (PCI DSS) is requirement 11.2, also known as the scanning requirement. Regardless of business size, this mandate requires organizations to “run internal and external network vulnerability scans at least quarterly and after any significant change in the network.”

But requirement 11.2 isn’t just about scanning network components and servers to find vulnerabilities before attackers. It’s about remediating and changing processes to ensure they don’t happen again.

Ultimately, there’s more work in complying with requirement 11.2 than most people think. Here are 8 tips you must understand in order to ensure true PCI scanning compliance.

SEE ALSO: 5 Simple Ways to Get PCI Compliant

1. Understand how vulnerability scanners work.

vulnerability scannersA scan, whether internal or external, doesn’t traverse every network file like an antivirus product. It must be configured to scan certain interfaces, like internal or external IP addresses (ports and services), for vulnerabilities.

PCI scanning technology includes different tools and scripts designed to check for vulnerabilities. These tools vary, but can include Approved Scanning Vendor (ASV) operated tools, command line scripts, GYI interfaces, and open source technologies. Some common tools are scanning tools like Nessus.

At a high level, scanning tools run a series of if-then scenarios on your systems, also known as a scan, which typically takes 1-3 hours, depending on your environment.

These if-then scenarios are designed to identify system settings or actions that could lead to vulnerabilities. For example, if your scan checks for operating system versions and discovers an extremely outdated Windows XP operating system on a workstation, it will flag as vulnerable.

A vulnerability scan is designed to be nonintrusive. It simply scans and provides a logged summary of alerts for you to act on. Unlike penetration testing, a vulnerability scan doesn’t exploit vulnerabilities in your network.

As you review your scan results, you will probably notice CVE (common vulnerability and exposure) numbers in your alerts. I encourage you to familiarize yourself with the National Vulnerability Database to research CVE records to identify and prioritize your risks if your product/company does not offer this for you.

SEE ALSO: Spotting Vulnerabilities: Is Vulnerability Scanning Antiquated?

2. Recognize the big difference between internal & external vulnerability scanners

The PCI DSS requires two independent methods of PCI scanning (internal and external) because they scan a network from different perspectives.

An external vulnerability scan looks for vulnerabilities at your network perimeter or website from the outside looking in, similar to having a home alarm system on the outside of your house. An internal vulnerability scan looks for network vulnerabilities locally (from the inside looking in), similar to having motion detectors inside your house.

One of the biggest misconceptions with internal and external vulnerability scanning among businesses today is this:

“My ASV does my PCI scans, so I’m compliant.”

If your ASV currently performs your external quarterly scans, understand they are likely not handling your internal quarterly PCI scanning as well. You may have an internal vulnerability scanning tool or appliance (like SecurityMetrics' Vision) set up inside your network by your ASV, but chances are they’re not handling your internal vulnerability scanning requirements. Always best to double check that your internal scanning is really being performed.

There are a variety of tools to help you comply with the internal vulnerability scan requirement.

For example, you can:
  • Purchase an internal vulnerability scanning appliance from your ASV, or another service provider
  • Download an open source internal vulnerability scan tool from the Internet
  • Purchase and download Nessus 
Keep in mind the tool you use will still need to be configured by an expert after you purchase or download it. If you purchase an appliance,  IT support service is typically included in the purchase. If you download, you might be stuck researching best practice configuration tips through online forums.

The point to remember is this: your organization is 100% in charge of internal vulnerability scanning, from initial download/purchase, to configuration, to actual scanning, to alert analysis, to vulnerability management.

3. Make sure an ASV runs your external scan.

External scans must be performed by an ASV. No exceptions. You can find a list of over 100 ASVs on the PCI Council website, so you have plenty of options.

Being an ASV is no small feat. In a yearly recertification process, each ASV is required to run their PCI scanning tool on Council-approved sites riddled with vulnerabilities to test which vulnerabilities the tool finds or misses.

Just because an ASV runs your scan doesn’t mean your organization is free and clear. What happens after the performed scan and subsequent scan report is totally up to you. You’re in charge of fixing any located vulnerabilities. You’re in charge of rescanning. You’re in charge of complying with PCI DSS.

Need an external scan from an ASV? Talk to us! 

4. Ensure your internal scanner is independent & qualified.

The PCI DSS states internal vulnerability scanners should be handled by a qualified person independent of the scanned device or component. The Council doesn’t want a conflict of interest if the scanner is the same as the person remediating any discovered vulnerabilities.

For example, if you need to run an internal scan on your firewalls, you can choose a qualified security professional, your ASV, or a qualified employee who isn’t over firewall administration to run the scans. Even if your firewall administrator is qualified, he’s not independent of the scanned system.

It doesn’t matter if you only have one IT guy who does the job of 15 employees. If he’s not independent from owning the system, he shouldn’t be administering the scans.

5. Find out if you’re running the right number of scans.

Each organization, no matter their size, is supposed to run quarterly internal and external scans. If you only had a single target, that would be eight total scans per year, two per quarter.

Many businesses religiously run four external vulnerability assessments each year, but neglect to run any internal vulnerability assessments because they’re considered inconvenient. Others treat vulnerability scanning as an occasional and isolated spot check process, largely focused on addressing immediate issues.

Just remember: You aren’t 100% PCI DSS compliant with requirement 11.2 unless you run at least four external vulnerability scans per year (one per quarter), and four internal vulnerability scans per year (one per quarter), and all of them are in a passing state.

SEE ALSO: Perimeter Scan Vs. External Vulnerability Scan

6. Confirm your scope to assure you’re scanning all required systems.

Technically, the PCI DSS only requires you to run vulnerability scans on in-scope networks, processes, and systems. But that means you really need someone to help you understand and define your PCI scope, or your scans might be overlooking important networks. It’s important to know what should be scanned if you plan to attest PCI compliance.

Most small organizations don’t need to worry about this problem because they have a completely flat network. Flat networks are devoid of segmentation, which means the entire network must be scanned.

Complex networks that take advantage of segmentation to reduce scope must pay attention to how their scope changes throughout the year, and adjust vulnerability scans accordingly.

7. Run scans after network changes.

pci scanning
You are required by the PCI DSS to run scans quarterly, and after any significant change. So what defines a significant change?

The PCI DSS says a significant change depends on how your environment is configured. But in general, “if an upgrade or modification could allow access to cardholder data or affect the security of the cardholder data environment, then it could be considered significant.”

My three rules of thumb are these:
  1. If you add or change something that could potentially bring in new vulnerabilities, scan!
  2. If your risk analysis states the risk is high, scan!
  3. If you’re not sure, or it’s a grey area, scan!
If you’re still scratching your head, here are some examples of significant changes that might help you understand when you should scan:
  • Adding new servers or system components
  • Changing interfaces
  • Moving cardholder data to a new server
  • Upgrading products
  • Changing your firewall product
  • Adding middleware (like JBOSS)
  • Removing/instituting new systems that house cardholder data
  • Adding encryption applications
  • Changing network topology
  • Changing firewall rules
Don’t fret about the small changes. If you did, you’d be scanning for vulnerabilities 24/7. The small changes should be covered by your eight internal and external scans each year.

Here are some examples of non-significant changes:
  • Switching file integrity monitoring products
  • Changing antivirus products
  • Removing terminated administrative employees from configurations
Scanning after significant changes means within a reasonable amount of time. If you make significant changes to your system the Friday after your quarterly external scan, don’t wait until your next quarterly external scan to run another test! Test your changes and scan that weekend.

8. Realize network vulnerability scanners aren’t going away.

Because PCI scanning is considered by many as an inconvenient requirement, there are plenty of naysayers. Scan cynics claim the process is archaic, bogs down systems, can’t keep up with the rate of new vulnerabilities, and takes more time than it’s worth.
Let me make this 100% clear: vulnerability scanning isn’t foolproof, but it’s not going anywhere.
There’s a reason vulnerability scanning is mandated by the PCI DSS. Scans are one of the best methods to locate vulnerabilities on any organization’s system. If you treat your quarterly scans like a point in time, of course they won’t be effective for your security posture. The effectiveness of your vulnerability management process will either increase or decrease based on the effort, time, and resources you devote to it.

Brand Barney (CISSP, HCISPP, QSA) is a Security Analyst at SecurityMetrics, has over 10 years of data security experience, and will totally geek out if you mention Doctor Who. Brand loves to play jazz piano and daydreams about being as great as Dave Brubeck or Thelonious Monk. Connect with him on Twitter or check out his other blog posts.

PCI DSS learning center, SecurityMetrics