Tenable SC common mistakes
Tenable SC · Understand the traps and how to avoid them.
Standing up the Tenable.sc server and immediately creating scans, without deploying separate Nessus (or PVS/NNM) scanners and linking them back to SC.
Candidates carry over Nessus/nessusd habits from standalone scanning and assume the SC appliance itself performs the scan; in Tenable.sc all active scanning is executed by managed scanners in scan zones, and SC only orchestrates and stores results.
What to do instead
Before any scan: install the scanner(s), register each one in SC (Scanners > Add Scanner with the linking key), confirm the link status shows as connected, and only then assign it to a scan zone. Treat the SC server as a manager/repository host, not a scanner.
Finishing the initial setup wizard and going straight to scanning without completing baseline tasks: updating Nessus plugins through SC, confirming license/feed status, setting correct system time/NTP, and creating at least one Organization and administrative structure.
The setup wizard is treated as the finish line; the post-install checklist (plugin feed, scanner plugin sync, time sync, org/group model) is skipped because nothing visibly breaks until results look stale or scans time out.
What to do instead
Work a written commissioning checklist after the wizard: verify license and feed status, push a plugin update and confirm scanners picked it up, validate NTP/time sync on SC and scanners, and design Organizations/groups before creating any scan, policy, or user.
Building scan zones that do not match the actual scanner placement or that contain overlapping/non-contiguous IP ranges, then expecting a scan to cover targets that belong to a different zone or to be scanned only once.
Zones are mentally modelled as 'server groups' or 'departments' rather than as the IP-range-to-scanner mapping they actually are; overlapping ranges are assumed to be harmless.
What to do instead
Define each zone strictly by the IP ranges its assigned scanners can reach, keep ranges non-overlapping between zones, and confirm the zone contains at least one linked scanner before launching a scan against those targets.
Adding credentials to a scan policy (or only to a single scan) and assuming every subsequent scan is automatically credentialed, without testing the credential or checking the results to confirm local checks actually ran.
Credentials appear 'configured' in the UI, so the assumption is that credentialed scanning is now in effect; failures (wrong domain format, missing sudo/root, wrong SNMP community or version, blocked ports) are silent until someone reads the output.
What to do instead
Store and test credentials before using them, apply them deliberately at the right level (policy for reuse, or scan-level override), then validate by confirming host-based/local plugin results and checking the credential status reported for hosts rather than trusting the presence of a credential entry.
Choosing a repository type that does not match the data source - for example pointing network scans at an Offline repository, or expecting an Asset Data repository to hold vulnerability findings.
The repository is dismissed as a storage label, so the distinctions (scanner-fed local repository, imported .nessus offline repository, asset/metadata repository, PVS host repository) are not mapped to the workflow before the scan or import is configured.
What to do instead
Decide the data source first, then pick the type: local repositories for scanner-based scans, offline/upload repositories for imported scan files, asset repositories for imported asset metadata, and host/PVS repositories for passive data. Verify the repository is selected on the scan itself, not just created.
Leaving repository IP acceptance and purge/retention settings at defaults so results are silently discarded at import, or historical data disappears sooner than expected after a retention window is enabled.
Defaults look innocuous and the effects are not visible during a test scan against one host; the acceptance list and auto-purge behaviour only bite in production or when reviewing trends over time.
What to do instead
Before first use, confirm the repository's accepted IP ranges cover every scanned/imported range (or are explicitly set to accept all), and review purge settings (age thresholds, delete vs archive) against the reporting retention requirement.
Assuming asset lists are inventories that can be edited to 'remove' a host, or assuming a host outside a user's asset list still shows up in that user's results.
Asset lists are confused with asset records in a repository; in practice asset lists (static, dynamic, combination) are membership filters used for scoping access and reports, and removing a host from a list does not delete its vulnerability data.
What to do instead
Separate the two concepts: use asset lists for scoping and grouping (dynamic filters refresh membership automatically; static lists require manual upkeep), and use asset deletion/purge within the repository to actually remove data. When results look missing, check membership in the applicable asset list first.
Assigning Administrator broadly (or handing out Security Manager or Auditor interchangeably) because the role names sound similar, then being surprised that a user cannot create scans, cannot change anything, or can change too much.
The role model is learned by name rather than by permission: roles differ in what objects they can create/modify and at what scope, and organizational/group membership further restricts what a role can actually touch.
What to do instead
Map each role to the job function before assigning: Administrator for platform administration, Security Manager for scan/policy management, Scan Operator for running existing scans, Auditor for read-only evidence review, Credential Manager for credential objects, Security Analyst/Executive for analysis and reporting views. Verify the combined effect of role plus group/organization membership, not the role alone.
Creating scans, dashboards, and report definitions under a personal account without sharing them, then expecting other users or stakeholders to see them - or sharing with a group and assuming a user who is not a member will get access.
There is an implicit assumption that objects are globally visible once created; SC object visibility depends on ownership plus explicit sharing with users/groups and the recipient's asset-list scope.
What to do instead
Decide the intended audience at creation time, share the object with the specific users/groups that need it, use appropriate permissions (view vs full control), and confirm the recipient's group membership and asset-list scope so the shared object actually contains data for them.
Prioritizing remediation purely by CVSS base severity (critical/high) and by raw finding counts, ignoring Tenable's risk metrics and exploit context when ranking work.
CVSS is the familiar number, so the extra dimensions provided for prioritization (vulnerability priority rating, asset criticality, exposure, exploit-available indicators) are treated as noise or overlooked entirely.
What to do instead
Rank by the combination of vulnerability priority rating, asset criticality and exposure, and whether a known exploit exists, then filter dashboards/reports on those fields so the 'top risk' view reflects real exposure rather than severity counts alone. Where a metric is not present in the deployment, fall back explicitly and say so.
Scheduling reports and building dashboard components without checking the underlying filters, asset list scope, and delivery configuration - resulting in empty or partial reports that are only discovered after distribution.
The report definition and schedule are set up as a configuration exercise; the interaction between the user's asset scope, the report's filters (severity, asset list, repository, time window) and mail delivery is not validated end to end.
What to do instead
Run the report on demand first and inspect the output, confirm the report owner has visibility of the intended repositories/asset lists, verify the time window and filters return data, and test delivery (mail server reachability, recipients) before enabling the schedule. Apply the same filter check to every dashboard component.