Scan Best Practices

Introduction

Every organization has unique needs for their vulnerability management program. These requirements can vary from the scanner used (cloud or on-premises), the places where a sensor is deployed, technology in your environment, and other conditions of your vulnerability management program. The following information contains deployment best practices that should apply to everyone and assist in situations where continued overages occur.

General Best Practices

Role-Based Access Control (RBAC)

Familiarize yourself with Access Control and RBAC for controlling scan and view permissions for assets. Misconfigured access controls or User Groups can cause scan failures and asset or vulnerability deficiencies in dashboards and reports.

Credentialed Scanning

Tenable recommends running credentialed scans whenever possible. Credentialed scans provide your organization with a more accurate snapshot of your current environment, allowing you to quickly and safely collect information about your network and systems. You can use this information to fill in the gaps in your security architecture and make better decisions on how to improve your information security program.

Credentialed scans can also perform a wider variety of checks than non-credentialed scans, which provide you with more accurate scan results. This ensures extensive scanning of your network to determine local exposures or compliance violations. See Credentialed Scans in the Tenable Nessus Agent User Guide for more information about the benefits of credentialed scanning.

Proper Inventory of Assets

An accurate inventory of the existing assets in your network is the first step towards effective vulnerability management. To learn more, review asset inventory best practices and asset inventory analysis and review.

Deleting Assets

You can delete assets via the user interface, but they remain on the license for 90 days or until the Asset Age Out time has aged out. If the asset is found again before the 90 period or the Asset Age Out expiration, it counts as an additional licensed asset. With this in mind, if you expect to detect the asset again in the future, it is best to add this asset to the global exclusion list to avoid any licensing issues or enable Asset Age Out to purge deleted assets as early as seven days after they were deleted. For more information, see Delete Assets.

You can tag all assets that need to be deleted and use the API to bulk delete those assets. For instance, you could tag assets and use an automated script to delete assets with the “delete” tag on a custom time interval. If you know these assets may be found again (for example, honeypot networks), it is best practice to add these affected assets to the global exclusion list to avoid licensing issues or reduce your target scope to omit them.

Agent Scanning

Agents are a great way to capture vulnerability data on assets that are mobile or highly sensitive. It is essential to understand that an agent scan cannot interrogate the potential external exposure such as TLS vulnerabilities. If these types of vulnerabilities on these types of assets are important to your program, you should pair this with a network-based scan. If a credentialed vulnerability scan is not possible, you can use a non-credentialed scan. However, it is important to understand that non-credentialed scans on agents may produce an additional licensed asset. See the following section for more information.

Scan Hygiene

Before scanning, Tenable recommends reviewing the Tenable Vulnerability Management Scan Tuning Guide. Tenable Vulnerability Management limits the total number of scan schedules to 10,000. A scan schedule includes a scan template (including discovery and assessment settings), a list of scan targets, and (optionally) credentials and compliance audits. You can reuse can schedules, and doing so groups the scan results under the History tab of the given scan schedule.

It is best practice to reuse “on-demand” scan schedules, reduce clutter or confusion when looking for scan schedules, and adhere to good scan hygiene. There is little to no benefit to creating new “on-demand” scan schedules each time a new set of assets needs to be scanned. Instead, simply change the targets of the scan and use the history to see older data. Keep in mind, unless you avoid sending the data to the workbench, all of the changes found during the scan are reflected in the workbenches, reducing the need to review old scan results.

It is common to ask, “What changed since the previous scan?” This question can drive attention to the previous scan. However, you should note that each scan updates the assets with the newest information. You can use the asset Activity tab to identify when a Tenable sensor detected the asset. Furthermore, each vulnerability indicates when the vulnerability or plugin was first seen and last seen. The difference between those two dates typically helps in identifying what has changed since a previous scan.

Lastly, it is best practice to use remediation scans for re-scanning the asset outside of its predefined scan cycle. You can initiate remediation scans from the action button on the vulnerability details page. This is the most convenient way to manage remediation scans and helps keep scan hygiene clean.

API Scan Creation Best Practices

If you use the API to automate scan creation, it is still equally important to maintain scan hygiene. If you cannot reuse the same scan schedule for your workloads, Tenable recommends that you make scan deletion a part of your automated scan procedure. Instead of creating a new scan policy for every new scan, consider using the alt_targets parameter when launching a new scan as outlined in the API documentation.

Maintaining scan hygiene helps reduce the number of scans sent back on each request to the /scans endpoint and may speed up the endpoint.

Duplication Challenges and Remedies

Non-credential scans may not get enough data during the scan to uniquely identify an asset. A common example of this is an asset with multiple interfaces. The following sections describe different examples of this with potential resolutions.

Server with Multiple NICs

Non-credentialed scans may not collect enough data to merge the two network interfaces found during a scan.

Resolution:

  • Scan the asset with credentials to uniquely identify the asset and de-duplicate the multiple NICs.

  • Exclude any extra IP addresses for the asset if they do not provide any reporting value. You may use network scanning to “pen test” an asset, and visibility into different vulnerabilities or open ports on a different network interface may provide insight and value. To correct any reporting accuracy issues, delete the asset using the user interface or API.

  • To remove duplicates that were deleted, enable Asset Age Out to mirror your scan schedule.

Firewall and Layer 3 Switches

Non-credentialed scans cannot collect enough data to uniquely identify a firewall or Layer 3 switch in the event that multiple interfaces are scanned. In order to do so, Tenable Vulnerability Management would have to crawl the device’s system configuration to see the interface IPs. However, even with credentialed scans, Tenable Vulnerability Management does not crawl the configuration file and gather this data.

Resolution:

  • When multiple interfaces are found in a scan, identify which ones are duplicates in value and add them to the exclusion list.

    • Example: In the case of a firewall with three interfaces, and therefore three IP addresses, exclude two of the IP addresses and delete them using the user interface or API.

  • To remove duplicates that were deleted, enable Asset Age Out to mirror your scan schedule.

Agents and Non-Credentialed Scans

Non-credentialed scans may not collect enough data to merge the two findings (agent scan and non-credentialed scan). A well-hardened server does not provide enough data to identify the asset uniquely. However, Tenable's algorithm de-duplicates the asset reducing the license count where there is more data.

Resolution:

  • For assets that are well hardened or do not provide enough data for Tenable’s algorithms to merge assets confidently, you should add credentials so that Tenable can collect the data necessary to merge the assets confidently.

Ephemeral Assets

Ephemeral assets or assets that are terminated and rebuilt before the 90-day period has aged out creates a new asset each time they are rebuilt or deployed. Many asset attributes may change after the asset has been terminated, making it difficult to merge the asset with its previous version.

Resolution:

  • Use the cloud connectors. The cloud connectors not only help identify ephemeral assets in the cloud, but they also detect their termination and remove the corresponding license.

  • For situations where you cannot use a cloud connector, you need to leverage the Asset Age Out feature. The Asset Age Out feature purges assets automatically if they are not found within the configured time period.