How are CVE's matched in SNTC?

[davidoliver1]

My question is how does SNTC match CVE's to a device.  Is it simply the devices code version and/or model of the device?  CVE's normally list code version that is vulnerable to an attack on something that is running on the device such as SNMP for example.  They give commands to run to see if you are running the process that is compromised.  I would like to know if we turn on CLI collection in the CSPC, will it be able to figure out that we ARE NOT running the compromised process on a device and in return remove the CVE from the device in the SNTC portal?  My problem is we get a lot of false positives with CVE vulnerabilities on devices because I think the portal is simply matching on device and/or code version (hence my original question).  I end up running manual processes on devices to show that the device is indeed not running the compromised process.  I would like to show a clean CVE audit report to my security team, but I can't if the CVE's keep showing up for devices that are not really compromised to the vulnerability.  I also don't want to do knee-jerk reactive upgrades to switch code when I don't have to to simply get the CVE off the list when it wasn't compromised in the first place.  Thanks in advance to anyone who can clear this up for me or have other ideas about the CVE's.

[Chris Camplejohn]

The minimum matching is based on SW Type (I.e. IOS, IOS-XE, etc.) and SW Version.  But additionally, where applicable, the matching can be on a "feature" from the running configuration, the imagename (for IOS), the Chassis PID, the Module PIDs or in the case of IOS XR, the SMUs installed.  Other CLI besides the running configuration are not currently checked today, but are planned for in the future.

[davidoliver1]

I figured as much on your first sentence. Can you elaborate a little more on the "feature" from the running-config though? Is there a document on this I can refer to?
TIA.

[Chris Camplejohn · Accepted solution]

Not sure about a document. But the way it works is that we write rules that parse through the running configuration. These are called "features" in the inventory results. We then use those for PSIRT checks. For example, if a PSIRT applies if you have BGP enabled, we might have a feature rule with the regex looking for "^router bgp". Then if your device doesn't have that regex or that "feature", you would be "Not Vulnerable" to that PSIRT even if your SW Version is vulnerable to the PSIRT.

[davidoliver1]

Thats exactly what I am looking for.  I will need to enable CLI discovery then.  I only have SNMP turned on.

[Chris Camplejohn]

You just need to add the CLI credentials (either telnet or SSH). The collection will automatically collect the needed CLI.