andy_ojha
ServiceNow Employee

‎11-07-2023 07:06 PM

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 

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 

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 

_andy_grTDIR_do_1-1699412660034.png

 

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"