VR: Tenable Integration creating assets in Unclassed Hardware

[sath]

Hi,

Tenable Integration on VR module is creating records on Unclassed Hardware table if it doesn't match with the existing CI.

And those records come in with minimal information so when that same record is enriched in Tenable, will it be sent to ServiceNow to update that new information on CI record?

Also, we are checking the possibility of stopping the creation of Unclassed Hardware records on our instance? If it doesn't find any match with the existing record, we do not want Tenable to create the record under Unclassed Hardware class. How do we achieve this requirement?

Any inputs are appreciated. Thank you.

[kmohammed]

Hi Sath,

To answer your two questions in order:

1. Yes — enrichment should be re-imported and re-matched.

The Tenable import does not create a CI directly; it creates a Discovered Item keyed to the Tenable asset. CI Lookup Rules then run against that Discovered Item. When Tenable enriches the same asset, the next import updates the same Discovered Item and the lookup rules run again. If the enriched payload now matches an existing CMDB CI (for example by FQDN/hostname, IP, MAC, or serial number, depending on your lookup rule order), the Discovered Item and its Vulnerable Items will associate to that matched CI going forward.

What to check after a re-match: do not assume the old Unclassed Hardware CI is automatically deleted. Review the Discovered Item history and, if an orphaned Unclassed Hardware record remains with no live Vulnerable Items, retire/delete it through your normal CMDB data-quality process so you do not end up with a duplicate CI for the same asset.

2. Yes — you can stop automatic creation of Unclassed Hardware CIs, but understand the trade-off.

In the Tenable/Vulnerability Response integration configuration, turn off the option that creates a CI when no match is found (the unmatched-CI creation setting for that integration). With it off, a Discovered Item that finds no match stays in Unmatched state and no Unclassed Hardware CI is created.

The trade-off is visibility: those vulnerabilities will not be attached to a CI, so assignment and remediation routing that depend on CI ownership will not work for them. You should instead report on Unmatched Discovered Items regularly and fix the root cause — usually CMDB coverage gaps or lookup rules that are too narrow, or Tenable data that lacks the identifiers your rules expect (hostname/FQDN/IP).

In practice, most teams keep creation on while they clean up lookup rules and CMDB data, and only turn it off once unmatched counts are low and they have a process to work the unmatched queue. Otherwise you are hiding the problem instead of fixing it.