Large-scale Deployments

If you want to deploy agents across a large-scale environment, your deployment strategy must ensure that all agents are continuously active and stay connected to Tenable.io or Nessus Manager.

Deployment Strategy

When deploying many agents, consider using software to push agents through the network. For example: 

Tenable recommends that you deploy batches of agents over a 24-hour period when deploying a large number of agents. This is especially helpful if you have a limited network bandwidth and need to limit the amount of data your network is downloading at one time.

After you install an agent, it receives its first plugin update once it receives instructions to run an assessment. The agent sets a timer to attempt the next update 24 hours from the initial plugin update time (and update the plugin update date on subsequent successful plugin downloads). Deploying your agents in batches also prevents too many agents from checking for product updates at one time and consuming too much bandwidth.

An agent links to Nessus Manager or Tenable.io after a random delay ranging from zero to five minutes. This delay occurs when the agent initially links, and also when the agent restarts either manually or through a system reboot. Enforcing a delay reduces network traffic when deploying or restarting large amounts of agents, and reduces the load on Nessus Manager or Tenable.io.

Clustering

With Nessus Manager clustering, you can deploy and manage large numbers of agents from a single Nessus Manager instance. For Tenable.sc users with over 10,000 agents and up to 200,000 agents, you can manage your agent scans from a single Nessus Manager, rather than needing to link multiple instances of Nessus Manager to Tenable.sc.

A Nessus Manager instance with clustering enabled acts as a parent node to child nodes, each of which manage a smaller number of agents. Once a Nessus Manager instance becomes a parent node, it no longer manages agents directly. Instead, it acts as a single point of access where you can manage scan policies and schedules for all the agents across the child nodes. With clustering, you can scale your deployment size more easily than if you had to manage several different Nessus Manager instances separately.

Example scenario: Deploying 100,000 agents

You are a Tenable.sc user who wants to deploy 100,000 agents, managed by Nessus Manager.

Without clustering, you deploy 10 Nessus Manager instances, each supporting 10,000 agents. You must manually manage each Nessus Manager instance separately, such as setting agent scan policies and schedules, and updating your software versions. You must separately link each Nessus Manager instance to Tenable.sc.

With clustering, you use one Nessus Manager instance to manage 100,000 agents. You enable clustering on Nessus Manager, which turns it into a parent node, a management point for child nodes. You link 10 child nodes, each of which manages around 10,000 agents. You can either link new agents or migrate existing agents to the cluster. The child nodes receive agent scan policy, schedule, and plugin and software updates from the parent node. You link only the Nessus Manager parent node to Tenable.sc.

Note: All Nessus nodes in a cluster must be on the same version (for example, using the clustering example above, the Nessus Manager parent node and 10 children nodes need be on the same Nessus version). Otherwise, the cluster deployment is unsupported.

For more information, see Clustering in the Nessus User Guide.

Agent Groups

Tenable recommends that you size agent groups appropriately, particularly if you are managing scans in Nessus Manager or Tenable.io and then importing the scan data into Tenable.sc. You can size agent groups when you manage agents in Nessus Manager or Tenable.io.

The more agents that you scan and include in a single agent group, the more data that the manager must process in a single batch. The size of the agent group determines the size of the .nessus file that must be imported into Tenable.sc. The .nessus file size affects hard drive space and bandwidth.

Group Sizing

Product Agents Assigned per Group
Tenable.io

Unlimited agents per group if not sending to Tenable.sc

1,000 agents per group if sending to Tenable.sc

Nessus Manager

Unlimited agents per group if not sending to Tenable.sc

20,000 agents per group if sending to Tenable.sc

Nessus Manager Clusters Unlimited since scans are automatically broken up as appropriate by separate child nodes.

Caution: If you scan multiple groups of agents in a single scan, the total number of agents per scan might not match the total number of agents per group. For example, if you have three groups of 750 agents in Tenable.io, all in one scan, then data for 2,250 agents would be imported into Tenable.sc at one time and may overwhelm it.

Group Types

Before you deploy agents to your environment, create groups based on your scanning strategy.

The following are example group types:

Operating System

Asset Type or Location

You can also add agents to more than one group if you have multiple scanning strategies.

Scan Profile Strategy

Once you deploy agents to all necessary assets, you can create scan profiles and tie them to existing agent groups. The section below describes a few scan strategies.

Operating System Scan strategy

The following strategy is useful if your scanning strategy is based off of the operating system of an asset.

Basic Agent Scan - Linux

In this example, a scan is created based on the Basic Agent Scan template, and is assigned the group Amazon Linux, CentOS, and Red Hat. This scan only scans these assets.

Asset Type or Location Scan Strategy

The following strategy is useful if your scanning strategy is based off of the asset type or location of an asset.

Basic Agent Scan - Production Servers

In this example, a scan is created a scan based on the Basic Agent Scan template, and is assigned the group Production Servers. This scan only scans production server assets.

Basic Agent Scan - Workstations

In this example, a scan is created based on the Basic Agent Scan template, and is assigned the group Workstations. This scan only scans workstation assets.

Note: You may want to configure workstation scans with longer scan windows, as most organizations cannot guarantee when these systems are online (as opposed to servers which are typically on 24/7).

Scan Staggering

While scans with the Nessus Agents are more efficient in many ways than traditional network scans, scan staggering is something to consider on certain types of systems.

For example, if you install Nessus Agents on virtual machines, you may want to distribute agents among several groups and have their associated scan windows start at slightly different times.

Staggering scans limits the one-time load on the virtual host server, because agents run their assessments as soon as possible at the start of the scan window. Oversubscribed or resource-limited virtual environments may experience performance issues if agent assessments start on all systems at the same time.