Tenable.sc – missing property on Asset Import causing multiple hosts to map to same Discovered Ite

[cjchalmers]

Hi all,

We are currently implementing Vulnerability Response / USEM using the OOTB Tenable.sc integration and are seeing unexpected CI correlation behaviour.

Environment:

• ServiceNow: Australia

• Vulnerability Response Integration with Tenable: 30.5.3

• Tenable.sc: 6.8.0

The main symptom is that detections from multiple unrelated Tenable hosts are ending up against the same Discovered Item / Source CI, and therefore ultimately against the wrong CMDB CI.

For example, a detection for:

• AZVM-INFRA-002

• IP 10.110.8.6

was associated with a Source CI mapped to:

• GUP10137

• IP 10.238.103.213

The correct AZVM-INFRA-002 CI does exist in the CMDB.

Tracing this backwards, we found that the Tenable.sc Asset Import records contain:

Host Uniqueness = repositoryID,hostUUID

The OOTB Tenable.sc Asset Transform calls:

host["ID"] = new sn_vul_tenable.TenableSCUtil().generateUuid(source);

and TenableSCUtil.generateUuid() uses the attributes specified in u_uniqueness / u_host_uniqueness to generate the host ID.

For hostUUID, the script effectively looks for:

u_hostuuid

However, in our instance:

sn_vul_tenable_sc_asset_import

does not contain a u_hostuuid field at all.

A dictionary check gives:

u_hostuuid exists: false
u_uuid exists: true
u_uniqueness exists: true
u_host_uniqueness exists: true
u_repository exists: true
u_dnsname exists: true

ServiceNow documentation for the Tenable.sc asset import also states that u_uuid is not populated from the Tenable API and that u_uniqueness is used to create the unique UUID for the asset.

The apparent effect is that where uniqueness is:

repositoryID,hostUUID

and hostUUID cannot be read, the generated host ID appears to reduce to the repository ID only.

This would fit what we are seeing: one Source CI in repository 6 currently has thousands of detections covering hundreds of distinct host identities.

We also have an ongoing Azure migration, with some hosts moving between scanner environments and some non-credentialed scanning, so we are investigating that in parallel. However, we also see the behaviour with hosts that have not been migrated.

Has anyone seen this behaviour with Tenable.sc + VR/USEM 30.5.x?

In particular:

• Is u_hostuuid expected to exist on sn_vul_tenable_sc_asset_import?

• If not, how is hostUUID expected to be supplied to generateUuid()?

• Is this a known schema/version issue with the Tenable integration?

• Could we be interpreting the repositoryID,hostUUID uniqueness logic incorrectly?

• Is there a recommended way to repair/reprocess Discovered Items after the source identity issue is resolved?

We have deliberately not modified the OOTB transform or created the missing field manually, as we first want to understand the expected product behaviour.

Any pointers or similar experiences would be appreciated.

[Dan_Junqueira]

Hi @cjchalmers 

This is a really good investigation, and based on what you’ve found I would be suspicious of the identity generation as well.

The ServiceNow documentation confirms that u_uuid is not populated directly from the Tenable.sc API and that the value used to uniquely identify the asset is generated using the configured u_uniqueness attributes.

So if your configuration says:

repositoryID,hostUUID

but hostUUID is effectively unavailable when generateUuid() runs, I can see how you could end up with multiple hosts generating the same source identity within the same repository.
The fact that you have thousands of detections from different hosts associated with a single Discovered Item makes that worth investigating before looking at the CI Lookup Rules themselves.

One thing I would check is the actual raw asset payload/import row for two different affected hosts and confirm exactly where Tenable.sc is returning the host UUID. I would then compare that with what generateUuid() is actually reading at runtime.

I would not create u_hostuuid manually or modify the OOTB transform yet. If the Store application is expecting an attribute that does not exist in the schema for your installed version, that feels more like something to raise with ServiceNow Support, particularly with the exact Tenable integration version you are running.

I’d give Support exactly what you already have:

• integration version

• Tenable.sc version

• configured u_host_uniqueness

• dictionary result showing u_hostuuid is missing

• two raw source records from different hosts

• the UUID generated for each

• the resulting Source CI/Discovered Item
  
  

That should make it much easier to establish whether this is a version/schema issue or whether hostUUID is expected to come from somewhere else.

Regarding cleanup, I would also fix the source identity issue before doing any reconciliation.

ServiceNow does provide functionality to reapply CI Lookup Rules, and when the CI on a Discovered Item changes, the related detections and Vulnerable Items can be updated as well.

However, in your case the problem looks like it may be one level earlier: several source hosts have potentially been collapsed into the same Discovered Item. Reapplying CI Lookup Rules alone may therefore not be enough to separate them again.

I would fix the UUID generation first, rerun the Tenable.sc asset import with a small controlled set of hosts, confirm that they create distinct Discovered Items, and only then decide how to repair the existing population. For a large number of already-collapsed records, I’d probably get ServiceNow Support involved before deleting/rebuilding them.

Your Azure migration could certainly make CI matching more complicated, but if you can reproduce this with hosts that never moved environments, I agree that it shouldn’t be treated as the primary explanation.

Please update the thread if Support confirms what hostUUID is supposed to map to in this version, I think that would be useful for anyone running Tenable.sc with the newer VR/USEM integrations.

Hope this helps. If it does, please mark the response as useful.