Deployment, Architecture, and Initial Configuration
Deployment models
Tenable SC (formerly SecurityCenter) is a management server plus one or more Nessus scanners. Optional components - Log Correlation Engine (LCE) for log/event correlation and Nessus Network Monitor (NNM, formerly the Passive Vulnerability Scanner) for traffic analysis - enrich but never replace active scanning. In an all-in-one deployment the scanner is co-resident; in a distributed deployment scanners sit close to the targets and connect outbound to the SC on TCP 443. Because the scanner initiates the connection and registers with a one-time registration key generated on the SC, a scanner can live in a DMZ or behind NAT with no inbound firewall rules.
Build order
License and plugin feed first, then organizations, scanners, scan zones, repositories, credentials, users. Repositories are the containers for scan results and must be bound to at least one organization before they can store data; scan zones need IP ranges and at least one scanner.
Traps
- A scanner that never registers never becomes available, and scans fail with no scanner available.
- Repositories bound to the wrong organization are invisible to that organization's users - a classic cause of empty reports.
- Air-gapped deployments need offline plugin update bundles; the feed date in the UI is the fastest way to spot a stale feed.
- Clock skew between SC and scanner breaks result correlation, so enforce NTP.
Rule of thumb: configure top-down - license, organization, scanner, scan zone, repository, credentials, users - and confirm each layer before adding the next. Worked example: a DMZ scanner is unreachable from the SC, so you generate a registration key, install the scanner, point it at the SC address, and it dials out on 443 and shows Connected.