Tenable Nessus Scanning — Templates, Plugins & Credentialed Scans

① Scan templates & policies — intent vs controls

Every Nessus scan starts with a scan template — a pre-configured starting point that defines the intent of the scan. Tenable groups templates into three categories: Discovery (find hosts and open ports, OS fingerprinting, no vulnerability checks), Vulnerabilities (the workhorse category — Basic Network Scan, Advanced Scan, Credentialed Patch Audit, Web App Tests), and Compliance (CIS benchmarks, DISA STIGs, PCI DSS config audits). You pick a template, then optionally clone it to a scan policy and tune it.

A scan policy is the saved technical configuration behind a scan. It controls port scanner selection (SYN, TCP connect, UDP), host discovery methods, scan timeouts and performance throttles, credential attachments for Windows / SSH / databases, and exactly which plugin families or individual plugins run. One policy can be applied to many scheduled scans. The key split: the template gives you a sensible starting shape; the policy is where you deliberately tune that shape for your environment.

② Plugins & plugin families — the actual checks

Plugins are the individual security checks that Nessus runs against a target. Each plugin tests for one specific condition — a missing patch, an open service with a known CVE, a weak cipher, a misconfiguration. Tenable ships plugins daily; they carry a Plugin ID, a name, a severity rating, a CVE reference and remediation guidance. There are tens of thousands of active plugins, so you never manage them one-by-one in production.

Plugin families — the right lever to pull

Plugins are grouped into plugin families by category: examples include Windows, Linux Local Security Checks, Web Servers, Databases, SCADA, Backdoors, Policy Compliance, and Port Scanners. In a scan policy you enable or disable entire families — and then optionally toggle individual plugins within a family. The interview point: disabling irrelevant families (e.g. SCADA on a web server estate) shortens scan time and reduces noise without losing meaningful coverage. Enabling a family without the right credentials (like Linux Local Security Checks without SSH creds) only runs the subset of plugins that work unauthenticated.

③ Credentialed vs uncredentialed scanning — what each sees

An uncredentialed scan (also called a network or unauthenticated scan) probes the target from the outside: it checks open ports, banner versions, network-reachable services, and vulnerabilities that an attacker without valid credentials could exploit. This is your attacker-facing view — fast to set up, no credential management, but blind to what lives inside the OS.

A credentialed scan authenticates to the target — via WMI/SMB for Windows, SSH for Linux/UNIX, or JDBC for databases — and runs local security checks: installed patches, software inventory, registry settings, file permissions, service configurations. Tenable consistently shows that credentialed scans surface significantly more vulnerabilities than uncredentialed scans on the same host, because most CVEs require local access to detect. Supported credential types include Windows (domain or local account), SSH (password or key-based), SNMPv3, Oracle, MySQL/MSSQL/PostgreSQL, and HTTP/FTP/Kerberos-based auth.

Best practice is both: an uncredentialed pass shows the external attack surface; a credentialed pass shows the full local exposure. Only the credentialed view feeds a complete patch management programme.

④ Scan zones, agents vs scanners — coverage without blind spots

Scan zones (called scan zones in Tenable Security Center, and scanner groupings in Tenable Vulnerability Management) are logical groupings that map IP ranges to specific Nessus scanner instances. A zone ensures scan traffic stays local: an internal scanner covers the 10.x.x.x data-centre range; a DMZ scanner covers the DMZ; a cloud scanner covers the AWS subnet. Without zones, a single scanner routes all traffic across the WAN, hammering firewalls and producing false negatives where connectivity is slow or blocked.

Agents vs network scanners — pick the right sensor

A Nessus network scanner reaches out over the network to target hosts — it is ideal for infrastructure you always own and can reach, like servers, network devices and cloud instances with stable IPs. A Nessus Agent is a lightweight daemon installed on an endpoint; it runs checks locally (as root/SYSTEM), reports results back to the manager, and works whether or not the host is on the corporate network. Agents are the right call for laptops and remote workers (off-net when a network scan runs), transient workloads (containers, auto-scaling), and environments where you cannot open inbound scanner connectivity. Agents do not run network-based plugins (port scans, banner grabs) — those still need a network scanner. For most enterprises: agents for endpoints, scanners for infrastructure.