This option in the Option Profile is used for configuring light port vulnerability scans that you want to run as authoritative scans. Here we'll tell you about it's behavior and specific use cases.
Scan authoritativeness affects the way the system closes previously detected findings (those having a status New, Active or Reopened) based on the results of the current scan.
In an authoritative scan, previously open findings will be closed if the QID is included in the scan (when option profile Vulnerability Detection is set to Complete or Custom with search list including the QID) AND either of these conditions is met:
1) The QID was executed and the vulnerability was found to be corrected, OR
2) The QID could not be executed because the port the vulnerability was previously detected on is no longer open or reachable by the scanner, or the port is not in the list of ports scanned
In the case where 2 instances of the same vulnerability existed on multiple ports, for example a web server released QID on 80/tcp and 443/tcp, each instance of the vulnerability is evaluated independently according to the conditions stated.
Non-authoritative scans do not update the status of a QID if the port is not included in the list of ports to scan.
- Light port scans are non-authoritative by default, i.e. vulnerability status is updated for vulnerabilities found on scanned ports only. You can make light port scans authoritative by enabling the Authoritative Option for light scans in the option profile.
- Scans with TCP and/or UDP ports set to standard or full ports lists are always authoritative and can not be made non-authoritative.
If you run light port scans on target hosts with the authoritative option you should continue to run scans the same way. If you change to run standard or full port scans on the same targets, you could get unexpected vulnerability status and trends.
It is not recommended that you run light scans with the authoritative scan option if you've standardized on full and standard scans in your organization. This could cause vulnerability status to be changed unexpectedly.
A vulnerability was previously discovered in a web server on port 80/tcp. To remediate the issue the service was shut off. Scans that include the specific QID in the search list (or use Complete Vulnerability Detection) but are not Authoritative, will not close the vulnerability on subsequent scans because the port is no longer open and therefore the QID cannot be executed. Authoritative scans will force-close the vulnerability.
Certain QIDs like Shadow Brokers QID 91345 have an authenticated check and a remote check, which means the scanner will post the Port it was found on in the Results section but will not tag the asset’s details (i.e. host-based data) with a port.
From the scan processing point of view, when your light port scan uses a custom port list, the scanners will look at all current vulnerabilities on a host that are found on one of the custom ports being scanned, and then will mark it as Active, Fixed, Reopened depending on the scan results.
If a detection is found during an authenticated scan, then only another authenticated scan can close that vulnerability regardless of authoritativeness. An unauthenticated scan does not have the same access as an authenticated scan, therefore should not result in closing out a QID.