I have been getting questions about interpreting the new CVE detection status in the Forward Networks Vulnerabilities application. This post explains the thought process behind the change and sheds light on how to interpret the new statuses.

As you may know, most vulnerability scanners (especially the black box kind) rely on the OS version a network device is running to flag it as vulnerable to a CVE (or not). The information on whether a certain OS is vulnerable is typically publicized both in the CIS NVD database and vendor advisories. 

While relying on the OS version casts a wide net and typically does identify all the potentially vulnerable devices, it often identifies hundreds of vulnerabilities - many more than those that need to be prioritized for patching.

The reason this approach identifies too many devices (false positives) is that it is unable to understand the configuration of the devices. For example, some of the devices may not enable the vulnerable module. A common example is a web management console which is subject to many Apache web server vulnerabilities.  However, if a web management is not enabled on a device, such device would not be vulnerable. 

Historically, Forward Networks has been able to identify truly vulnerable devices and help the teams focus on addressing / patching those devices and their vulnerabilities. 

While the vast improvement over the generic vulnerability scanners, the older implementation of Forward Networks vulnerability detection had certain ambiguities. Specifically, the devices identified as having OS Match vulnerabilities could be vulnerable because the vulnerabilities in their OSes were always present, regardless of the configuration or possibly vulnerable, because Forward Networks has not yet implemented configuration analysis for those operating system or the configuration analysis did not complete. Further, Forward Networks treated equally the patched devices with  OSes that did not have any known CVEs and the devices with vulnerable OSes but not vulnerable configurations by omitting both from the CVE list. Differentiating between these two cases would have helped with upgrade planning and results comparison between Forward networks and other vulnerability scanners.

In the Forward App versions up to 25.3, the CVE detection decision tree is as follows:

Release 25.4 addresses all of the above issues by making the CVE detection status more precise. Rather than two statuses, OS Match and Config Match, the new release publishes five detection statuses: Conig Confirmed Vulnerable (Vulnerable), Config-Independent Vulnerability (Vulnerable) , Config detection not supported (Possibly vulnerable), Config cannot be confirmed (Possibly vulnerable), and Config not vulnerable (Not vulnerable in the current configuration).

CVEs that affect no operating systems found in customer environments are not listed. This decision was made for two reasons:
 

1. It would introduce a lot of irrelevant information into the product. For example, CVEs that only affect IOS would never affect any network devices. There is no reason to mention them.
2. It would bloat both the Forward CVE database and the UI with hundreds of pages non-actionable CVEs.

On the contrary, including the CVEs that affect devices with the same OS, but not affect certain devices in their existing configuration is helpful because:

1. It help reconcile the results from black-both vulnerability scanners like Qualys or Tenable that produce results only on the basis of the OS version
2. It helps identify devices that could become vulnerable after a relatively minor configuration change.

Here is a decision diagram for the new detection:

Questions on CVE detection in Forward? Ask me in the comments below.