Nessus and OpenVAS

Objective 3.3 in this course covers discovery tools — CompTIA names Nessus, Nikto and OpenVAS specifically. Because CompTIA names them they are examinable by name, and this lesson is the applied lab for the objective.

Why this matters

These are the two general-purpose vulnerability scanners CompTIA names, and they solve the same problem from different directions — one commercial, one open source. Expect questions that assume familiarity with how a scan is configured and how its output is read, rather than trivia about menus.

Everything from lessons 15 to 19 applies to both. This lesson is about driving them well and knowing where their answers come from.

The lesson

Policies, plugin families and scan templates

Both tools organise checks into groups and let you select which run. The vocabulary differs; the structure does not.

• A policy or scan configuration is the reusable definition: which checks, which ports, what timing, which credentials.
• Plugin families group checks by technology or by kind. Selecting families deliberately is how you keep a scan proportionate — there is no value running every database check against a network switch.
• Templates are starting points: a fast discovery sweep, a full assessment, a compliance audit, a specific check.

Two settings deserve attention every time, because they carry the risks from lesson 8:

• Anything marked dangerous, intrusive or denial-of-service. These attempt things that can take a service down. Off unless the scope names them in writing — the same rule as lesson 12's script categories.
• Timing and concurrency, which is what actually breaks fragile devices.

And save the policy with the results. A finding is only reproducible if somebody can re-run the scan that produced it, which is lesson 14's point about reproducibility applied to a GUI.

Running both against the same lab host and diffing

The applied lab for objective 3.3, on the lab host from lesson 2 where you know the truth.

Scan the same host with both tools, configured as equivalently as you can, then compare. You are looking for four categories, and each teaches something different:

1. Found by both — the highest-confidence findings. Two independent implementations agreeing is the corroboration lesson 18 asks for.
2. Found by one only — usually a feed-coverage difference. This is the concrete demonstration that one scanner's silence is not evidence.
3. Different severities for the same issue — see below.
4. Found by neither, but you know it is there — the most valuable category, because it is the shape of everything a scan will miss on a real estate.

Then repeat authenticated, per lesson 16, and watch all four categories change.

Severity as the tool assigns it, versus as you assign it

Both tools attach a severity, usually derived from a CVSS base score. Lesson 6 made the argument; here is where it bites.

The tool's severity knows the vulnerability and knows nothing about this client: not whether the host is internet-facing, not what data it holds, not whether a compensating control breaks the attack path, not whether the system is decommissioned next month.

So the tool's number is an input. Your severity is the output, and the report carries the base score, your adjustment, and the reason. Writing the reason down is what makes it survive the challenge in lesson 5 — in both directions, since you will raise as often as you lower.

The two tools also disagree with each other on the same issue, which is a useful thing to have seen before a client asks why.

Exporting findings into a report pipeline

Both export structured formats, and lesson 14's rules apply.

• Export structured, not PDF, so the results can be parsed, deduplicated across tools, and merged with what you found by hand.
• Keep the raw export. It is the evidence behind the finding and it is what a re-test compares against.
• Deduplicate across scanners on the underlying issue rather than on the tool's own identifier, since the two name things differently.
• Never paste a scanner's description straight into the report. It is generic by construction; lesson 6 requires impact stated for this client.

The pipeline should also be honest about coverage: carry the hosts targeted, hosts completed, feed version and authentication status through to the report, because lesson 19 showed those decide what the findings mean.

Licensing and what the free tiers withhold

Worth knowing, and occasionally examinable in the form of "which tool suits this situation".

Nessus is commercial with a free tier limited in the number of hosts it may scan and in some functionality; professional use generally needs a licence. OpenVAS is open source, with its feed available in a free community form and a commercial feed alongside it.

What matters professionally:

• Check the licence covers commercial use before scanning a client. Using a home-use tier on a paid engagement is a licensing breach, and it is your firm's problem rather than the client's.
• Free feeds can lag. Which is a coverage limitation under lesson 19 and belongs stated rather than discovered.
• Host limits silently shape scope. A tier capping hosts will simply not scan the rest, which is exactly the "hosts targeted versus hosts completed" discrepancy that lesson 19 says to check.

The professional framing: the tool's limits become limitations of your assessment, and a limitation you did not disclose is one the client will assume was not there.

What to take into the exam

• Select plugin families deliberately; dangerous and denial-of-service checks stay off unless the scope names them in writing.
• Save the policy with the results, or the finding is not reproducible.
• Running two scanners exposes feed-coverage differences — one tool's silence is not evidence.
• The tool's severity is an input; yours is the output, and the reason is what defends it.
• Export structured, keep the raw output, and carry coverage metadata into the report.
• Licence limits and free-feed lag become limitations of your assessment, and must be disclosed.