Using NNT Vulnerability Tracker will enable you to quickly and easily identify what vulnerabilities lie within your existing software and configuration settings. At NNT, we believe that providing our customers with vulnerability scan results that are as accurate as possible is imperative.
Highlighting areas of concern and limiting the number of false positives that are reported is key and there are a number of different functionalities present within the software that enables us to do exactly that.
Quality of Detection (QoD)
Quality of Detection (QoD) is a value between 0-100 % that describes the reliability of an executed vulnerability detection/product detection.
Within Vulnerability Tracker, the option to specify a QoD percentage can be found when creating new scanning tasks (Fig 1.) – when carrying out this task, a user will specify a minimum QoD % that they would like to scan a specific device for which means that only detected vulnerabilities that meet or exceed that percentage will be included as part of the scan results. The default minimum QoD % is set to 70% but this option is fully customizable and an end-user can choose to increase or decrease this as they see fit. The higher the QoD %, the less likely it is that the reported vulnerability is going to be classed as a ‘false positive’, making the results more accurate.
Fig 1. NNT Vulnerability Tracker – Creating Scan Task
There are different factors that come in to play when deciding what level of QoD is assigned to a given vulnerability. Some of these have been listed below for you to review:
- QoD – 100% - The detection happened via an exploit and is therefore fully verified.
- QoD – 95% - Remote active checks (code execution, traversal attack, SQL injection, etc.) in which the response shows the likely presence of the vulnerable application or of the vulnerability. “Likely” means that only rare circumstances are possible in which the detection would be wrong.
- QoD – 80% - Remote banner check of applications that offer patch level in version. Many proprietary products do so.
- QoD – 70% - Remote checks that do some analysis but which are not always fully reliable.
Whilst using Vulnerability Tracker, there are two different approaches that can be taken when scanning a target device:
- Non-Authenticated Remote scan
- Authenticated Scan using local security checks
A Non-Authenticated Remote Scan will use the same techniques and protocols that a potential attacker could use to gain access to a target from the outside. It’s worthwhile mentioning, that although this is the least intrusive method of scanning a system, it doesn’t give an end-user a true indication as to what vulnerabilities are present on their system(s), especially relating to installed software and their configuration. This means that the number of vulnerabilities that are included as part of the results of a scan could be limited.
Due to the reasons outlined above, we also offer an Authenticated Scan of a system that can utilize local security checks. Using this method allows for the software to log into a target system in order to test it for vulnerabilities using credentials that are configured and saved on the GSM. These credentials can be used on a number of system types like Windows using SMB and Linux using SSH for example.
Using an Authenticated Scan will enable a user to identify more vulnerabilities on a given system as the software is able to scan it from both the outside and the inside, making the results more accurate. The software will be able to detect and determine the different levels of risk for internal vulnerabilities but it will not introduce any changes to the system it is scanning and the additional checks that can be made on the system also depend on the permissions of the user being used to authenticate, so this is something that needs to be taken into consideration.
A user can predefine a set of credentials (Fig 2.) and then attach them to a scan target (Fig 3.), ready for when they create an appropriate scan task.
Fig 2. NNT Vulnerability Tracker – Creating Credentials
Fig 3. NNT Vulnerability Tracker – Assigning Credentials to Scan Target
Scanners - OpenVAS vs CVE
When scanning a system for vulnerabilities, there are two predefined scanners that can be used:
- OpenVAS Default
The CVE scanner is mainly used to forecast possible security risks based on the information that the software has already obtained about a given system. The CVE scanner takes information gathered on previous scans (that were run using the 'OpenVAS default' scanner) about operating systems and installed software (CPEs), open ports etc. and then runs this information against the database of CVEs. Any match will then be reported as a potential vulnerability, regardless of whether the reported piece of software is actually vulnerable. So, to conclude, when this scanner is used, the software is not actually scanning the target but only looking for matches in the CVE database. This type of scanner should not be used to assess whether or not an actual vulnerability is present but instead used to provide an end-user with an idea of potential vulnerabilities.
Using this scanner will increase the amount of false-positive vulnerabilities that are included as part of the scan results so, therefore, we would always advise that when creating a scan task, an end-user always opts to use the OpenVAS Default scanner (Fig .4). This will ensure that an actual scan of the system is carried out, no previously gathered information will be taken into consideration so therefore only the most accurate and reliable results will be displayed.
Fig 4. NNT Vulnerability Tracker – Configuring GSM scanner as part of a new scan task.
To conclude, using any or all of the options outlined above will help you decrease the number of false positives results that are present in your result scans, ensuring that you are only notified of key areas of concern that require you to implement workarounds, mitigations or vendor fixes.