Choosing the Right Architecture for Your Nessus Agent Deployment

As organizations adapt to work-from-home mandates, we detail the three most common configurations for securing your remote workforce using Nessus Agent deployments.

In several of our recent blog posts, we’ve discussed the various reasons that organizations, including government agencies, might deploy Nessus Agents to protect their newly distributed workforces. As part of the changes precipitated by emergency remote work mandates, it’s important to maintain vulnerability metrics for your entire organization. These scans are crucial to protecting assets that have changed location from the office to employees’ households, as well as new assets like personal laptops and phones being introduced into your enterprise IT environment.

Nessus Agents are a perfect way of conducting this due diligence. They enable local scan policies on devices that are not dependent on a connection to the office network. Outside of a work-from-home situation, Nessus Agents are also excellent alternatives for gathering vulnerability information on hosts that have frequently changing credentials and assets that have been hardened to prevent external login.

Three ways to set up your Nessus Agent deployment

There are several ways to architect a Nessus Agent deployment depending on your specific needs. Detailed below are a few of the most common use cases.

1. Standalone Tenable.io

Tenable.io has the native capability to communicate with Nessus Agents over the internet. This is ideal for prospective or current Tenable.io customers that want to deploy agents quickly and utilize Tenable-provided, cloud-facing scanners as an “eye in the sky” for assets not typically visible to internal scanners. The diagram below depicts this configuration, which requires no additional deployment outside of the Nessus Agents on each host. You can read our recent blog for further instructions on how to configure Nessus Agents with Tenable.io.

2. Tenable.io as proxy to on-premise Tenable.sc

Tenable.io can also be used as a proxy for Nessus Agents to Tenable.sc. This is a great scenario for organizations that have limited resources for managing additional infrastructure, or those that may not control the external pieces of their network. In this configuration, the Nessus Agent gets its scan instructions from the user’s Tenable.io container and aggregates the data back to Tenable.io. From this point, the data is ready to be ingested into an internal Tenable.sc console for a holistic view with the rest of the internally-available data. 

This solution is great for customers who want to have external visibility of their data without a VPN connection to the internal network. They enjoy simplified scanning of their external assets with the available cloud scanning capabilities found within Tenable.io, as well as easy agent data aggregation and the mature reporting structure of Tenable.sc. You can visit our Tenable Community article for easy step-by-step instructions on how to link your Nessus Agents across Tenable.io and Tenable.sc.

3. Standalone Tenable.sc

If you are using the Tenable.sc platform, Nessus Manager can act as a proxy for Nessus Agents. There are two ways to architect this setup: 

Placing Nessus Manager in the demilitarized zone (DMZ)

This scenario is beneficial for organizations with lots of devices that are off the corporate network and don’t reliably connect to a VPN for internal access. This is becoming a much more prominent method of operation as single sign-on (SSO) solutions and forward-facing web applications replace the need to use a VPN for the majority of a person’s workday. 

A firewall rule can be made between the internal Tenable.sc console and the Nessus Manager residing in the DMZ. This allows Tenable.sc to collect the data without creating additional risk of exposure. Additionally, customers can change the management port so the administrative interface of Nessus Manager isn’t exposed to the Internet. This ensures that any device with an agent and internet connection can still reach the Nessus Manager, and removes the limitation of needing a VPN solution to collect scan data.

Placing Nessus Manager inside the organization’s network

Another option for Nessus Manager is to deploy it within your enterprise network, usually on the same segment as the Tenable.sc console. This is advantageous for organizations that have employees who reliably connect to a VPN, or any organization that wants to maintain vulnerability data within its network. In this situation, you can scan devices for real-time vulnerabilities as they connect to the VPN, without the worry of missing an active scan cycle from a Nessus Agent. This strategy reduces the likelihood of an active Nessus scan saturating a VPN link. Instead, each host uses its own resources and the results are staggered back to the network.

A note on large-scale deployments

Every piece of guidance is enhanced by additional documentation, and Nessus Agent deployment is no exception. For large scale considerations, Tenable provides documentation that contains helpful tips around the scaling relationship between Nessus Agents and Nessus Managers, scan staggering and automated deployment mechanisms. As always, the Tenable Community is another great place to post questions and read about the experience of other security managers.

Editor's note: this blog post was updated on May 18, 2021.

Pour en savoir plus

• For more information on the latest research findings and vulnerability advisories during the COVID-19 response, visit our Tenable resource page on protecting your remote workforce.