Sensor Security

See the following sections to learn more about sensor security and encryption when using the Tenable One Vulnerability Management platform:

Sensor Overview

Sensors access Tenable One Vulnerability Management through the following site: <port> - sensor.cloud.tenable.com:443. All sensors (Tenable Nessus scanners, Tenable Agents, Tenable Network Monitor) need access to cloud.tenable.com:443.

Note: If you are connecting to Tenable One Vulnerability Management through Tenable Nessus scanners, Tenable Agents, Tenable One Web App Scanning scanners, or Tenable Network Monitors (NNM) located in mainland China, you must connect through sensor.cloud.tenablecloud.cn instead of sensor.cloud.tenable.com.

Depending on how you deploy and set up Tenable Nessus scanners and Tenable Network Monitor - you need to access their respective user interfaces for initial setup:

  • Tenable Nessus — <IP>:8834

  • Tenable Network Monitor — <IP>:8835

    Note: If you are deploying Tenable Nessus or Tenable Network Monitor with Tenable Core, you also need access to the underlying virtual appliance interface: <IP>:8000.

Tenable One Vulnerability Management uses a user interface, driven by Tenable's customer-facing APIs, for all operations. The sensors that connect to Tenable One Vulnerability Management play a major role in your security, collecting vulnerability and asset information. Protecting this data and ensuring the communication paths are secure is a core function of Tenable One Vulnerability Management.

Nessus sensors connect to the Tenable One Vulnerability Management platform after securely authenticating and linking to Tenable One Vulnerability Management (see Linking Keys in the following section to learn more). Once linked, Tenable One Vulnerability Management manages all updates to ensure the sensors are always up to date.

Sensors always initial the traffic between sensors and Tenable One Vulnerability Management, and the traffic is outbound-only over port 443. Traffic is encrypted via SSL communication using TLS 1.2+ (or version 1.2 when in NIAP mode) with a 4096-bit key. This removes the need for firewall changes and allows you to control the connections via firewall rules.

Note: To learn more about NIAP mode, see the following topics in their respective product user guides:

Linking Keys

Tenable One Vulnerability Management uses a linking key as an initial authentication token for sensors. The linking key allows you to create the initial link between your sensor (a Nessus scanner, Nessus Agent, or Tenable Network Monitor) and Tenable One Vulnerability Management.

When the Tenable One Vulnerability Management platform receives a link request from a sensor, it validates the presented linking key with valid linking keys. If it finds that it matches a valid linking key, Tenable One Vulnerability Management allows the sensor to link.

Upon linking, Tenable One Vulnerability Management randomly generates, saves, and sends a 256-bit length key to the sensor. This key is unique to the sensor.

Once the link process is complete, the sensor no longer needs or uses the linking key. Any future authentication is performed in the following ways:

  • Sensor-to-platform authentication

    After the initial linking process, the sensor provides the 256-bit key to identify and authenticate its requests. These requests include, but are not limited to, requesting jobs, scan policies, plugin updates, scanner binary updates, and providing information back to Tenable One Vulnerability Management, such as scan results or sensor health data.

  • Sensor-to-platform job communication

    Sensors check in to Tenable One Vulnerability Management every so often (different sensor types have different check-in frequencies). When a scan job is launched, Tenable One Vulnerability Management generates a policy and encrypts it with a randomly generated 128-bit key. The sensor requests the policy from the platform. The policy is stored on disk, but the key resides only in memory. The controller uses the key to encrypt the policy, which includes the scan credentials.

Data Encryption

Tenable One Vulnerability Management encrypts all data in all states with at least one level, using no less than AES-256:

  • Data at rest — Tenable One Vulnerability Management stores data on encrypted media using at least one level of AES-256 encryption. Some data classes include a second level of per-file encryption.

  • Data in transport — Tenable One Vulnerability Management uses TLS version 1.2+ with a 4096-bit key to encrypt data during transportation (including internal transports).

  • Backed up or replicated data — Tenable One Vulnerability Management stores volume snapshots and data replicas with the same level of encryption as their source: no less than AES-256. All replication is done within AWS. Tenable does not back up any data to physical, off-site media or physical systems.

  • Index data — Tenable One Vulnerability Management stores index data on encrypted media using at least one level of AES-256 encryption.

Tenable can rotate all the stored, encrypted data to a new key. Alternatively, you can switch to a new site to use a new key (in other words, Tenable does not reuse keys when provisioning a new site). Tenable manages the keys with AWS Key Management.