Tenable SC cheat sheet

SecurityCenter centralizes scan data from Nessus scanners, NNM, PVS, and LCE; repositories persist results and asset records.

Distributed deployment separates the SecurityCenter application from scanner appliances placed near target networks; scanners report results to the central application.

A scan zone maps scanners to reachable network segments; scans select a zone so only scanners in that zone collect data.

Organizations provide tenant isolation for assets, users, scans, repositories, dashboards, and reports.

Initial sequence: license, network and time settings, organizations, users and roles, scan zones, scanners, credentials, policies, repositories, then scans.

Repository choice controls data intake and retention: local repositories receive live scan results; offline repositories ingest exported scan files.

SecurityCenter administrative access uses HTTPS; restrict administrative reachability to trusted management hosts and networks.

Scanner appliances require connectivity to SecurityCenter and reachability to targets for the protocols used by selected scan policies.

Time synchronization across SecurityCenter and scanners is required for consistent scan scheduling and result timestamps.

A scan policy defines plugin families, plugin settings, port ranges, performance limits, and credential settings used by scans.

Credentialed scanning authenticates to hosts so scanners can perform local checks; uncredentialed scans rely on remote probing only.

Windows credentialed checks commonly use SMB with an account that has local administrative rights for patch and configuration audit.

Unix/Linux credentialed checks commonly use SSH with sudo/root or a least-privilege account permitted to read system state.

SNMP credentials enable network device discovery and configuration checks; use read-only community strings or SNMPv3 credentials.

Scan zones group scanners by network location; a scan using a zone uses scanners that can reach the target address range.

Plugin families can be enabled or disabled per policy; disabling a family removes its checks from scans using that policy.

Safe checks avoid plugins known to be disruptive; enabling unsafe checks can affect fragile systems and must match target sensitivity.

Scan performance settings such as maximum hosts, maximum checks, and timeouts trade thoroughness and speed against target load.

Asset records are built from scan observations; identity can use IP, DNS name, NetBIOS, MAC, and UUID to correlate hosts.

Asset lists are named groups of assets used as scan targets, report and dashboard filters, and access-control boundaries.

Static asset lists contain manually added assets; dynamic asset lists update membership from saved filters or queries.

Repositories store scan results and asset data; every scan must write to a repository.

Local repositories receive live scanner results; offline repositories import scan files for analysis without direct scanning.

Asset search filters can combine IP, DNS, operating system, severity, plugin, and tag criteria.

Tags or asset attributes classify assets by business function, location, or criticality for filtering and prioritization.

Asset identity settings determine whether observations appear as one asset or multiple assets and therefore affect historical reporting.

Organizations are top-level tenant boundaries; assets, scans, repositories, users, and reports belong to an organization.

A user account can hold roles in one or more organizations; effective permissions are evaluated per organization.

Administrator role configures system-wide settings, organizations, users, scanners, and repositories.

Security Manager role manages scans, policies, assets, and users within assigned organizations.

Auditor role provides read-only visibility into scan results, assets, dashboards, and reports without changing configuration.

Analyst role focuses on vulnerability analysis, dashboards, and reports using existing scan data.

User groups simplify permission assignment; group membership grants roles and access to shared objects.

Access to asset lists and repositories limits which scan results a user can view or report on; least privilege grants only the role and organization access required for duties.

Dashboards are collections of widgets that query vulnerability and asset data; widgets inherit dashboard filters and scope.

Report templates define sections, filters, and output formatting; reports can be generated on demand or scheduled.

Report formats include PDF, HTML, CSV, and RTF; format choice depends on audience and data reuse.

Severity levels are Critical, High, Medium, Low, and Info; severity derives from plugin/CVSS data and can be recast.

VPR combines severity with exploitability and threat intelligence to prioritize vulnerabilities beyond raw CVSS.

Asset criticality can weight prioritization; high-criticality assets with high VPR are addressed before low-criticality assets with similar findings.

Accept-risk rules mark findings as accepted for a defined period, removing them from active remediation queues.

Remediation is confirmed by rescanning or plugin-based mitigation; absence on a consistent later scan indicates resolution.

Trend dashboards compare vulnerability counts over time; valid comparison requires identical filters, asset scope, and repository selection.