If you’re just entering the world of PCI DSS compliance, you’re going to learn that ASVs are very important. For even the lowest levels of merchants and service providers, the one thing required other than completing an annual Self Assessment Questionnaire (SAQ) is to conduct quarterly ASV scans.
So what exactly is an ASV?
An ASV is an Approved Scanning Vendor. These are companies approved by the PCI Security Standards Council to conduct vulnerability scans of your Internet facing computers. These vulnerability scans are needed for you to meet requirement 11.2.2 of PCI DSS.
Contents
What’s a Vulnerability Scan?
Hackers and researchers are constantly finding security problems with old versions of computer software. These get reported to the companies that wrote the software, such as Microsoft, who then release fixes for that software. This is partly why Microsoft have their regular “Patch Tuesday“, when security fixes are released for your computer. But it’s not just Microsoft that does this; all the major players release regular security fixes.
If you’re not running the most up to date versions of software on your computers, you make it much easier for the bad guys to break in and steal things of value. For the purposes of PCI DSS, that includes the payment card numbers you’re handling. So it’s really important to stay on top of these updates to keep information secure. Unfortunately, even the biggest companies struggle to keep everything updated in a timely fashion. In some ways it’s actually harder for big companies to do regularly, because they usually have internal change control processes that require lots of testing before applying any updates.
A vulnerability scan, or vulnerability assessment scan, tries to connect to every possible service your computers could be running, to see if they are running out of date or misconfigured software. The vulnerability scan produces a report which lists all of the services it found. For each one, it either shows no issues, or it shows that vulnerabilities were found. When vulnerabilities are found, there is usually a low / medium / high rating assigned to each, to guide you to which need to be addressed first.
Beyond finding old versions of software, vulnerability scans also look for common misconfigurations, such as using expired web server certificates (SSL / TLS certificates), or management services like Microsoft Remote Desktop or SSH open to the Internet.
What should I do with a Vulnerability Scan report?
Being PCI DSS compliant means that you need to have a clean vulnerability scan report from an ASV every quarter. And that means? Every quarter, you need to get a scan report that shows no vulnerabilities found. For some companies that can be quite straightforward, for others it’s harder because they have a large Internet footprint with logs of different systems.
Unfortunately, issues raised in a vulnerability scan report are not always valid. This is partly because a best practice for production configurations is to not give out unnecessary information about what version of software is running. I may know that you have an Apache web server, but I shouldn’t be able to easily tell what version it is.
Because exact version information is not usually available, the vulnerability scanning software used by the ASV has to use rules to decide what to do. Typically, these rules state that if a piece of software may be vulnerable, but we can’t know for sure, treat it as if it is vulnerable. This can lead to false positives, where an issue is reported when it doesn’t really exist.
Types of finding
When you first receive a failing ASV report, you need to identify which issues are real, and which are false positives. Both need addressed, but in different ways. This process of addressing the findings in the ASV report is known as remediation.
Real issues are the more critical, since they represent potential vulnerabilities in your system that could be exploited by the bad guys. These can be addressed either by updating to a fixed version of the software that resolves the issue, or by using some other configuration that prevents any attack from exploiting the vulnerability.
In general it’s always best to run newer, fixed versions of the software. If that’s not possible, you may be able to configure your software to prevent the attack. If an attack requires a certain configuration that you’re not using, then the vulnerability can’t be exploited. An example would be if a service had two different types of password storage it supported, one weak and one strong. If the ASV finding is because you might be using the weak password setting, but you can show you’re configured to only use the strong, that might be sufficient for the ASV to consider this a false positive.
Regardless of whether you address an ASV report finding by updating software or configurations, one thing is very important. Test the change! Ideally you’d test the change first in a dedicated test lab; this option isn’t always available to small merchants. But whatever happens, make sure you test the change, even if it is after the fact.
What are false positives?
False positives may be either an incorrect identification of fixed software as the older buggy version. Or, they may be where the software you have deployed contains a vulnerability, but it can’t be exploited in the configuration you are running.
Where false positives are found, you need to explain to the ASV company why you believe the finding in their report is incorrect. They may request some evidence, such as a log or screenshot showing you patched that server even though it looks like an old version. Once the ASV accepts your evidence, they will create an exception which tells their scanning software to ignore that particular result. These exceptions are usually time limited, so you’ll periodically go through this justification process for the same issues.
What do I do after all remediating all issues?
You’ve fixed all of the real issues found, and reached agreement with the ASV on all of the false positive findings. Now what? The ASV will rescan your network(s) again. Assuming that no new issues are found in the new report, and your fixes worked, the ASV will issue a certificate stating that no issues were found. Keep this certificate; you may need to provide it to the card brands, your acquirer, or other interested parties.
As far as ASV scans are concerned, that’s your work done until the end of the quarter. But it’s not the end of patching! The bad guys don’t take a break, and so neither can you.
For everyone dealing with card payments, vulnerability management needs to be a BAU process. At even the smallest merchants, you need to be installing vendor security updates as soon as you can safely get them onto your systems.
How do I find an ASV?
Working with an ASV is basically mandatory for PCI DSS compliance. The bad news is that you can’t just use any old security consultant who claims he knows how to use OpenVAS for this purpose. You must use a vendor approved by the PCI Security Standards Council – hence them being called Approved Scanning Vendors.
The good news is that there is now a broad range of ASVs to choose from. Compared to many IT security-related services, the prices for basic scanning service are typically quite reasonable. Many of these ASV companies also provide other security services, and some are QSACs too. So if you find one you’re happy working with for your initial ASV scans, this can be a good way to interview them for a bigger part in your IT world.
As you’re required to use an Approved Scanning Vendor, the PCI Security Standards Council maintains a searchable directory of approved vendors. When you look at the list, you’ll note that many of these are Global, but some only serve specific regions. There are registration requirements for each region, so make sure you find one that can actually serve your needs.