Learn the fundamentals of vulnerability scanning, especially for PCI compliance requirements.
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 prevent vulnerabilities from creeping in again.
See also: 5 Simple Ways to Get PCI Compliant
Ultimately, there’s more work in complying with requirement 11.2 than most people think. Here are 8 tips to get you started:
A vulnerability 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 (such as ports and services), for vulnerabilities.
Vulnerability scanners include different tools and scripts designed to check for vulnerabilities. These tools vary but can include Approved Scanning Vendor (ASV) operated tools, command line scripts, GUI interfaces, and open source technologies. An example of a commonly accepted industry scanning tool is Nessus by Tenable.
At a high level, scanning tools run a series of if-then scenarios on your networks (also known as a vulnerability scan), which may take 1-3 hours for a quick scan or 10+ hours for a larger scan. It’s important to remember that scan times will vary depending on your environment.
These if-then scenarios are designed to identify system settings/configurations and actions that could lead to exploitable 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 this OS as vulnerable.
A vulnerability scan is designed to be non-intrusive. It simply scans, alerts, and provides a logged summary of suspected vulnerabilities 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 scanning vendor does not offer this for you.
See also: Pentesting vs. Vulnerability Scanning: What's the Difference?
The PCI DSS requires two independent methods of PCI scanning: internal and external.This is 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 believing that:
“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. It’s always best to double check that your internal scanning is being performed and that you are following your vulnerability management procedures.
There are a variety of tools to help you comply with the internal vulnerability scan requirement.
For example, you can:
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 a tool, 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. Remember, you are responsible to maintain your PCI DSS compliance.
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 and 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 ultimately responsible for complying with the PCI DSS.
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, for example, 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, they’re not independent of the scanned system.
It doesn’t matter if you only have one IT professional who does the job of 15 employees. If they manage the system, they shouldn’t be administering the scans.
Each organization, no matter their size, is supposed to run quarterly internal and external scans. If you only had a single target, you’d need to run 2 scans per quarter, or eight scans per year.
Many businesses religiously run four external vulnerability assessments each year, but neglect to run any internal vulnerability assessments because they’re considered inconvenient or they just simply forget. 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 and compliant state.
See also: Perimeter Scan Vs. External Vulnerability Scan
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 likely 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.
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:
If you’re still scratching your head, here are some examples of significant changes:
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:
Scanning after significant changes should be done within a reasonable amount of time. For instance, 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.
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.
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. But the real question is, how he effectiveness of your vulnerability management process will either increase or decrease based on the effort, time, and resources you devote to it.
.svg)
