Tenable SC key terms

The central management appliance that stores scan results, schedules scans, runs dashboards and reports, and coordinates registered scanners. It does not perform scanning itself; the scanners do the network work and return results to it.

A regularly published bundle of plugins, each containing the checks used to detect a specific vulnerability, compliance setting, or inventory item. Tenable.sc downloads it and distributes the appropriate subset to registered scanners.

The process of updating plugins on a system with no internet access: an offline update file is downloaded elsewhere, uploaded to Tenable.sc, and then pushed out to the scanners it manages.

A scanning engine registered to Tenable.sc that performs the actual network scans, runs plugin checks, and returns results. It is managed centrally and may be a dedicated appliance or a Nessus Manager.

A Tenable component that collects and normalizes log and event data from hosts and network devices. Tenable.sc can query it for passive and log-based evidence that complements active scan results.

A one-time code issued by Tenable.sc that authorizes a scanner to register with that specific installation. A separate activation code from Tenable licenses the scanner itself.

A saved configuration defining what a scan does: which plugin families and plugins run, which credentials are used, port ranges, performance settings, and any compliance audits. Scans are launched by pairing a policy with targets.

A prebuilt starting configuration supplied by Tenable for common purposes, such as host discovery, basic network scan, or credentialed patch audit. Templates are copied and customized into user-defined policies.

A logical grouping of scanners and IP address ranges that controls which scanners may scan which targets. Zones let you place scanners close to the networks they serve and limit scan traffic crossing network boundaries.

A scan in which the scanner authenticates to targets with supplied credentials, enabling local checks that reveal missing patches and misconfigurations invisible to unauthenticated remote probing.

A stored set of authentication details, such as SSH keys or passwords, Windows/SMB accounts, SNMP strings, database logins, or ESXi accounts, that a policy uses to log in to targets. Credentials are managed separately and referenced by policies.

An individual check file that tells the scanner what to look for and how to report it, including severity, description, solution, and references. Plugins are grouped into families and refreshed through the feed.

A category that groups related plugins, such as Windows, Cisco, or Databases. Policies can enable or disable entire families, and analysis views can filter results by family.

The phase of a scan that determines which target addresses are alive before vulnerability checks run. Ping methods, port lists, and fragmentation options are configured within the policy.

A policy setting that suppresses plugins known to crash or destabilize fragile services. Enabling it lowers the chance of an outage during scanning at the cost of skipping some checks.

A script written in a supported audit language that verifies host configuration against a benchmark. It is uploaded to the scanner, runs as part of a policy, and produces pass, fail, and informational results.

A lightweight program installed on a host that scans that host locally and reports results to a linked manager. It is useful for roaming endpoints or systems that cannot be reached by network scanning.

A container that stores vulnerability and event data collected from a defined set of assets. Each organization has at least one, and asset lists, dashboards, and reports read their data from it.

A single host tracked inside a repository, usually identified by IP address, that accumulates vulnerability records, open ports, and attributes over successive scans.

A named group of IP addresses, ranges, or discovered assets used as scan targets and as filters in analysis, dashboards, and reports. Lists may be static or refreshed dynamically.

An asset list whose membership is computed from filters, such as severity, plugin, or a discovered attribute, so its contents change automatically as new scan data arrives.

An asset list built by combining other asset lists using union, intersection, or difference logic, allowing precise targeting without re-entering addresses.

Settings that determine how long vulnerability and event records remain in a repository before being purged, controlling storage growth and how far back trend reporting can reach.

The result of a plugin firing against a host, including plugin ID, port, protocol, severity, and first and last seen dates. The full set of records for an asset forms its risk picture.

A top-level container that separates users, assets, repositories, policies, and results from other organizations on the same Tenable.sc. A user can belong to several organizations with a different role in each.

A named set of permissions assigned to a user within an organization, such as Security Manager, Auditor, Scan Operator, or Credential Manager, defining what that user may view, scan, or change.

A collection of users administered together for role assignment, object sharing, and reporting. Groups reduce effort when many users need identical access.

Controls that determine which users, groups, or organizations may view or use a specific object, such as a policy, scan, asset list, dashboard, or report. Objects not shared remain visible only to their owner.

Configuration that lets users sign in with directory credentials from Active Directory or another LDAP server instead of local accounts, optionally mapping directory groups to Tenable.sc roles and groups.

An account or organization setting that permits sign-in only from specified source addresses or ranges, limiting exposure if credentials are lost or guessed.

The built-in administrative account that sits outside organizations. It creates organizations, manages scanners and feed updates, and otherwise controls the entire Tenable.sc installation.

A page of arranged components that summarizes security posture, such as top vulnerabilities or asset counts. Each dashboard is driven by a repository and filters and can be shared with other users.

A single visual element on a dashboard, such as a table, chart, matrix, or text block, each configured with its own query and display options.

A formatted export of vulnerability or asset data in a format such as PDF, HTML, or CSV. Reports can be generated on demand or scheduled and delivered by email or saved to a share.

Vulnerability Priority Rating, a score from 1 to 10 that blends technical severity with threat intelligence, known exploitation, and finding age to indicate how urgently a vulnerability should be remediated.

A standardized score from 0 to 10 describing the technical severity of a vulnerability based on exploitability and impact. It appears in plugin output and is one input to the priority rating.

The rating band of Info, Low, Medium, High, or Critical assigned by a plugin and used throughout analysis, dashboards, reports, and risk rules to classify findings.

A rule that marks a specific vulnerability on specific assets as knowingly accepted, removing it from active risk counts while preserving the underlying record for audit purposes.

A rule that overrides the severity of a vulnerability, for example lowering it where a compensating control exists or raising it for a business-critical asset.

The interactive view where findings are filtered and grouped by asset, vulnerability, plugin, or port, and where users drill into individual records and apply workflow actions.