Hi, team! Customer question: "We are using Tenable.sc as our scanner (plugin ver. 3.6.4). We are seeing some detections associated to Vulnerable Items like this:
VIT0113003
We have the detections come in with much of the same information but it seems like there are duplicates. They all matched on MAC Address and with the two that have the same IP address (10.20.15.100) the only difference is one had a FQDN attached to it and the other did not. When resolving these vulnerabilities via patching the one with the FQDN was auto-resolved but the one missing the FQDN did not automatically resolve. We have had to turn on the auto-close stale detections to resolve this issue otherwise the detections would remain open forever and the Vulnerable Item would not report as fixed. On the other hand auto-closing stale detections is skewing our reporting as we have some assets that only get turned on when needed and thus do not get scanned frequently so the vulnerabilities would report as Closed Stale in this situation but still be vulnerable."
Is this likely because they don't have the CI matching working properly? How should I troubleshoot this?
thank you,
Nancy
Hey there - this is somewhat a common observation, depending on the data in the 3rd party scanner at hand.
Two areas to look at:
1) Detection Keys
Would first start by looking at the Detection Keys on the instance, for Tenable.SC
- Table = sn_vul_detection_key_config
- https://docs.servicenow.com/bundle/vancouver-security-management/page/product/vulnerability-response...
Especially if this is an older installation of VR that was upgraded over time - enhancements were made to the Detection Key Config, in particular for the Tenable integration to exclude the Proof value from the Detection Key:
- Would spot check on the instance, by going to that table (sn_vul_detection_key_config.list), and verifying the value for Proof on Tenable.SC, and also the Update Status field
- If Proof = False, but Update Status = Pending - this signals we might have older Detections that were created before an upgrade that have not been "cleaned up" to remove Proof from the Detection Key
- This could lead to the experience on the screenshot
- If Proof = False, but Update Status = Pending - this signals we might have older Detections that were created before an upgrade that have not been "cleaned up" to remove Proof from the Detection Key
2) Discovered Item Uniqueness for those Detections
Not ruling out the CI Matching, but somewhat related to the concept above with the Detection Keys (for Asset ID)
- If the 3rd party scanner has multiple Hosts / Assets that theoretically map to the same CI in ServiceNow, we will see different Discovered Items represented for each of these (Source ID, on the Discovered Item representing the unique factor here
- Sometimes, this may happen if hosts / devices get hit with unauthenticated scans, if IP Addresses change, if there are non-persistent hosts in the mix (e.g. virtualized systems spun up and spun down quickly, but using the same Name, FQDN, etc)
On that list of Detections, it would also help to add the "Discovered Item" record
- This would signal another Detection Key, that would introduce uniqueness across those Detection Values
If there are non-persistent hosts in the mix - it could yield the behavior shown in that picture.
------------------------------------------------------------------------
Definitely agree with the challenge of finding the sweet spot for the Stale Detection Closure - especially with hosts spun up and down very quick (non-persistent).
- A neat feature enhancement could be a "rules" driven State record closure
- This could allow for more granular rules -> a smaller threshold for non-persistent gear, and larger threshold for traditional infrastructure / on-prem, etc.
Suggest checking these two items to start, that may get you closer to the root cause of these Detections, and narrowing in to why they are created, and an explanation behind "duplicate"
