Understanding Cyber Exposure requires that the data collected by Tenable.io is trusted and verifiable. Tenable.io provides several plugins that assist in understanding the scan status and provides a level of trust for risk managers. This dashboard brings together all the plugins used to verify successful authentication of assets during vulnerability scans, giving security administrators visibility into areas of concern so that the appropriate actions can be taken.
Authentication can be defined as connection to a system by providing credentials in order to gain access. Tenable.io scans systems by using different network protocols (SSH, SMB, HTTPS, SNMP, etc.) to gain access to the target asset. For example, logging into a remote host via SSH using a username and password is a method of authentication. Each asset can allow authentication using several protocols. Assets with more than one available authentication protocol, for example a Windows server running a SQL server, could report both authentication success and failure. Understanding this fact during analysis is key to understanding if the system was successfully scanned or not. While in many cases the successful authentication of an asset may seem binary, there are many examples of successfully scanned systems with authentication failures. The system administrator should review all of the failures and investigate the services which are enabled on the asset for a complete analysis.
Local checks are a feature in Tenable.io scans, which enable the scanner to perform security checks on the target asset. Some general checks function without full administrator credentials, but when all possible general checks are completed, Tenable.io verifies privilege escalation in order to perform more accurate local checks. The local checks always require authentication and often require elevated privileges. Local checks for major operating systems with security advisories numbering in the thousands are often grouped into their own plugin family, but local check plugins also exist in other families such as Firewalls or Misc.
Local checks require authentication and occur after successful authentication has been established. In order to utilize local checks, the following criteria must be satisfied:
- The target device or operating system must be identifiable by Tenable.io
- Local check plugins must be available for the identified device or operating system
- The information needed to enable local checks for the particular device or operating system must be obtainable from the target asset
- Except in particular circumstances, such as scanning localhost, remote authentication must first be successful before local checks are enabled
To ensure that scans are complete and accurate local checks are required. Users enable local checks by providing credentials with elevated privileges, or administrative access, or by deploying Nessus Agents. Without elevated access, the ability for Tenable.io to identify comprehensive risk on an asset is diminished. The more access to a system Tenable.io has, the more complete the vulnerability detection.
With this dashboard provides the organization with a clear and simplified method to track and troubleshoot authentication related problems. By grouping authentication plugins into diagnostic context, the dashboard shows administrators areas of concern to focus on. This helps to address the See and Act components of the Cyber Exposure Lifecycle. Tenable.io provides a comprehensive picture of the network and scales to large dynamic environments. Built on leading Nessus technology, Tenable.io discovers unknown assets and vulnerabilities, and monitors unexpected network changes before they turn into breaches.
This dashboard contains the following widgets:
Scan Authentication Summary: This matrix provides a summary of hosts that have been scanned successfully with credentials, operating systems discovered, and failed attempts to successfully authenticate to the remote asset. Nessus tracks errors or failures related to otherwise valid credentials to highlight issues that may result from incomplete scan results. For hosts that have successful scans, additional status information is provided in regards to good scans and scans that have errors, such as valid credentials, with insufficient privileges. OS Discovered data is displayed by confidence level, where the confidence level is high (95-100) and all other confidence levels (0-94). Failed credentials are broken down into those which failed because Local Checks are not enabled, or possible failure of protocol negotiation during the authentication process. Additionally, hosts which failed because no credentials were provided are displayed.
Windows Access Checks: This matrix provides the administrator with an indication of the scan health of Windows systems. The plugins used in the matrix report on the tests Nessus requires to perform the detailed checks on systems. These plugins check for permission and access to various aspects of Windows and set required entries in order for Nessus to perform local checks.
SMB Authentication Detection: This table provides a summary view of all the SMB plugins, which are used to understand the success of Windows asset scan. SMB is the primary protocol used when scanning a Windows device. There are several plugins that use SMB to report on software installation, BIOS enumeration, and many more core attributes.
Summarize Local Checks Status: This matrix provides summaries of overall local checks status. When Nessus detects problems during a scan, these plugins provide a list of the issues/errors logged along with the reporting plugin and protocol if available. Additionally, the plugins provide summaries of particular types of auth/local check issues that have been reported by other plugins and report the plugins that encountered these issues.
Authentication Searches: The cells in this matrix provides a series of useful queries used to understand and troubleshoot authentication problems. In order to conduct an authenticated scan against an asset, Tenable.io / Nessus use different protocols, (such as SMB, SSH, HTTPS, SNMP). Each of the plugins could be triggered on each protocol used during the scan. This means an asset can have an authentication success and authentication failure. Use these queries as a first step in troubleshooting scan success and the overall health of vulnerability collection activities.
Summarize Authentication Status: This matrix provides an overall authentication summary of the systems that have been scanned. The plugins used provide summaries of overall authentication status for the target. A given target should trigger at least one of these plugins.
Local Authentication Information: This matrix brings focus to the plugins used to authenticate to a remote host, and gather the information necessary for local checks, and enable local checks. Their output and audit trails provide details of any problems that were encountered.
SSH Authentication Detection: This table provides a summary view of all the Secure Shell (SSH) plugins used to understand the success of Linux or network device scanning. There are several plugins that use SSH to report on software installation, BIOS enumeration, and many more core attributes.