As part of our PCI-DSS compliance process we get scans done by a third party. Based on the form and wording of the output, it's pretty clear they're using Nessus for most of their heavy lifting. Same as we use internally, actually.

What is the value-add for having an external entity do the scans for us? Do they tune them differently?

3 Answers 3


You may be getting zero value-add. I suggest finding a new vendor.

And when soliciting potential new PCI ASVs, ask them what they do, questions like:

Which vulnerability scanners will you use to assess our systems?
Do you use the commercial or free versions of the vulnerability scanners?
We use Nessus internally, what more will you do to bring value?

And if you truly want greater assurance you are running systems free of known vulnerabilities then make it clear to each ASV candidate that you expect them to do more than simply run a Nessus scan.

Request they use multiple commercial backed vulnerability scanners. For example, I may do the following when wearing a PCI ASV hat:

  • execute multiple rounds of full TCP/UDP port scans (typically using custom tuned nmap runs, scanning on different days and different times to minimize congestion hazards that can hurt accuracy)
  • fire off a tuned round of Qualys scanning
  • fire off a tuned round of Nessus w/professional feed scanning
  • for each SSL based site, check for issues using https://www.ssllabs.com/
  • manually spot check any exposed web applications for common vulnerabilities (the point of this is if I find one or two form fields with easy vulnerabilities then it usually means the app has many more vulnerabilities and I’ll let the client know they need to do more work)
  • manually spot check any non-standard exposed services or applications

You can't expect a quality PCI ASV to match the above if you're only paying $99 (I'm not saying you are). But if you want more then shop around and be open to fair pricing.

  • A nice list of questions to ask! Good stuff. Commented Jan 14, 2011 at 15:14

Taking into consideration the fact that you are doing these scans in the context of PCI-DSS compliance, your value-add in relation to compliance can be summed up by my personal favorite saying:

AviD's Law of Regulatory Compliance:

"PCI compliance reduces the risk of the penalties of non-compliance".

In other words - the value-add of having an external scanning vendor over your internal tools (even if its the same tools), is that that is what the regulation requires.
That's why there's such a popping ASV business - their income is pretty much ensured by PCI. Take a look at McAffee's HackerSafe program (or did they change the name?): completely worthless from a security point of view, but equally valuable from a compliance point of view - since an ASV scan = ASV scan.

Now, if you want to get additional security value out of your whole compliance program, aside from simply "compliance", well that's another issue. (For elaboration on this, see my answer on "Does PCI compliance really reduce risk and improve security?"
The other answers here point you in the right direction, but one simple truism: Any vendor that simply runs tools, is not worth the price of coffee to have a sales meeting with.
Cheaper to get your own tools and run them yourself - since you can usually ignore most of the results, anyway :).

  • 1
    PCI does require 3rd party ASV, and we dutifully go through and flag the same false-positives from year to year. I suspect fulfilling that requirement is the biggest value-add we get. Commented Jan 14, 2011 at 15:04
  • 2
    @sysadmin1138 That's precisely AviD's point - particularly, the spirit of his "Law".
    – Iszi
    Commented Feb 25, 2014 at 18:23

Nessus is very good at what it does, but a 'proper' security scanning vendor would not just deliver you a Nessus report. At the very least, you need to go through the report and validate to remove false positives - you probably do this internally anyway, but unless you request it a vendor may not.

There is a major disconnect in what customers expect and what vendors offer. We have been working with various vendors and industry bodies to generate a taxonomy to try and remove some of this disconnect.

Apologies if this Security Testing Taxonomy is a bit beyond scope of question. It is meant to inspire discussion between you and your vendor so you can understand what they will provide:


The purpose of this stage is to identify systems within scope and the services in use. It is not intended to discover vulnerabilities, but version detection may highlight deprecated versions of software / firmware and thus indicate potential vulnerabilities.

Vulnerability Scan

Following the discovery stage this looks for known security issues by using automated tools to match conditions with known vulnerabilities. The reported risk level is set automatically by the tool with no manual verification or interpretation by the test vendor. This can be supplemented with credential based scanning that looks to remove some common false positives by using supplied credentials to authenticate with a service (such as local windows accounts).

Vulnerability Assessment

This uses discovery and vulnerability scanning to identify security vulnerabilities and places the findings into the context of the environment under test. An example would be removing common false positives from the report and deciding risk levels that should be applied to each report finding to improve business understanding and context.

Security Assessment

Builds upon Vulnerability Assessment by adding manual verification to confirm exposure, but does not include the exploitation of vulnerabilities to gain further access. Verification could be in the form of authorised access to a system to confirm system settings and involve examining logs, system responses, error messages, codes, etc. A Security Assessment is looking to gain a broad coverage of the systems under test but not the depth of exposure that a specific vulnerability could lead to.

Penetration Test

Penetration testing simulates an attack by a malicious party. Building on the previous stages and involves exploitation of found vulnerabilities to gain further access. Using this approach will result in an understanding of the ability of an attacker to gain access to confidential information, affect data integrity or availability of a service and the respective impact. Each test is approached using a consistent and complete methodology in a way that allows the tester to use their problem solving abilities, the output from a range of tools and their own knowledge of networking and systems to find vulnerabilities that would/ could not be identified by automated tools. This approach looks at the depth of attack as compared to the Security Assessment approach that looks at the broader coverage.

Security Audit

Driven by an Audit / Risk function to look at a specific control or compliance issue. Characterised by a narrow scope, this type of engagement could make use of any of the earlier approaches discussed (vulnerability assessment, security assessment, penetration test).

Security Review

Verification that industry or internal security standards have been applied to system components or product. This is typically completed through gap analysis and utilises build / code reviews or by reviewing design documents and architecture diagrams. This activity does not utilise any of the earlier approaches (Vulnerability Assessment, Security Assessment, Penetration Test, Security Audit)

  • We belong to a consortium of higher-ed .edu's that bands together to get an ASV in to scan our networks and share the cost. We don't have a say in the vendor. We give them a list of IP's, they give us access to a web front-end where the results were uploaded and we can flag severities and remediation. That site is a clear value add. OS-detection didn't happen, as evidenced by the blinking red alerts they threw for our (now gone) NetWare servers. We have yet to undergo a full-on Security Audit with review. Commented Jan 14, 2011 at 15:13
  • Great answer. Could you clarify the "credential-based scanning" part? What sorts of false positives would it eliminate?
    – nealmcb
    Commented Jan 15, 2011 at 22:36
  • 1
    @nealmcb - running scanning tools without creds ends up providing both false positives and negatives, some of which can be reconciled by letting the scanning tool use credentials eg an area of a web app which requires user log in may respond differently for different users.
    – Rory Alsop
    Commented Jan 16, 2011 at 1:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .