Cloud CI Lookup Rule Identifying Non-Ephemeral Servers as Virtual Machine Instances

[usmanalisye]

Currently we are seeing some non-ephemeral servers also getting identified through Cloud CI lookup rule as Virtual Machine Instances.

To properly separate ephemeral and non-ephemeral assets, we need some guidance from your infrastructure/cloud team on how these assets are identified in your environment.

Can you please help us understand:

• how ephemeral assets are differentiated in Tenable/cloud sources

• whether any tags, naming conventions, autoscaling indicators, VDI non-persistent flags, or Kubernetes/container identifiers are available

• and what attributes should be used to identify persistent vs temporary assets

This will help us make sure:

• only ephemeral assets use Cloud CI lookup logic

• and remaining server CIs continue through normal lookup rules like MAC/IP/Hostname matching.

[pavani_paluri]

Hi @usmanalisye ,

Right now, your Cloud CI lookup rule is picking up some servers that aren’t really ephemeral and treating them like short‑lived VMs. To separate the two, you need to know how your cloud and Tenable sources actually mark or describe ephemeral assets.

Tags/labels → things like `AutoScalingGroup`, `SpotInstance`, `Ephemeral`, or `Temporary`.
Naming patterns → auto‑generated names (`ip-10-0-0-123.ec2.internal`, `aks-nodepool-xyz`) vs. human‑assigned names for persistent servers.
Autoscaling membership → if it belongs to an AWS Auto Scaling Group, Azure VM Scale Set, or GCP Managed Instance Group, it’s almost always ephemeral.
VDI flags → non‑persistent desktops often carry a “nonpersistent” flag.
Kubernetes/container IDs → pods and containers have short‑lived identifiers and labels.

Work with your infra/cloud team to confirm which of these signals are consistently applied in your environment.
Update your Cloud CI lookup rule so only assets with ephemeral indicators (tags, autoscaling, container IDs) use the Cloud CI logic.
Let all other servers continue through your normal matching rules (MAC/IP/Hostname).

ephemeral assets can be separated by looking at tags, naming conventions, autoscaling membership, and container/VDI flags. Persistent servers should stick with your standard CI matching.

Mark it helpful if this helps you to understand. Accept solution if this give you the answer you're looking for

Kind Regards,

Pavani P

[usmanalisye]

Currently, we do not have much information yet from the infrastructure/cloud teams regarding how ephemeral vs non-ephemeral assets are identified in their environment.

As per the client requirement, priority should be given to persistent server CIs compared to cloud/ephemeral identification. Because of this, we are evaluating whether the standard lookup rules (MAC/IP/Hostname/etc.) should execute first for server matching, and only unmatched or true ephemeral assets should continue through the Cloud CI lookup logic.

Could you please suggest the best approach in this situation when clear ephemeral indicators or tagging information are not available from source systems?

Also, have you seen any recommended approach where:

server CI classes are prioritized first
and Cloud CI lookup is used only as fallback for unmatched/ephemeral assets?

Your guidance would be very helpful for us to proceed further.

Thank you.

[usmanalisye]

Currently, we do not have much information yet from the infrastructure/cloud teams regarding how ephemeral vs non-ephemeral assets are identified in their environment.

As per the client requirement, priority should be given to persistent server CIs compared to cloud/ephemeral identification. Because of this, we are evaluating whether the standard lookup rules (MAC/IP/Hostname/etc.) should execute first for server matching, and only unmatched or true ephemeral assets should continue through the Cloud CI lookup logic.

Could you please suggest the best approach in this situation when clear ephemeral indicators or tagging information are not available from source systems?

Also, have you seen any recommended approach where:

server CI classes are prioritized first
and Cloud CI lookup is used only as fallback for unmatched/ephemeral assets?

Your guidance would be very helpful for us to proceed further.

Thank you.