---
title: "Insight Classifications and Asset Definitions"
canonical: "https://docs.infoblox.com/space/UniversalAssetInsights/1501299200/Insight%20Classifications%20and%20Asset%20Definitions"
format: markdown
---
The following table highlights the importance of identifying and managing discovered assets to address risks and improve overall infrastructure health. It covers classification types and associated asset types, identification methodologies, and the significance of recognizing these assets. By leveraging asset insights, you can implement strategies to mitigate exposure to unmanaged or noncompliant assets, enhance security, reduce costs, and address technical debt across your IT infrastructure, creating a safer and more resilient environment.
For information on viewing asset insights, see *[Managing the Monitoring Lifecycle](https://infoblox-docs.atlassian.net/wiki/spaces/BloxOneDDI/pages/1088454942)*.
| **Classification Type** | **Associated Asset Category** | **Associated Asset Type** | **Definition** | **Insight identification Methodology** | **Why it Matters?** |
| --- | --- | --- | --- | --- | --- |
| Zombie/Orphan | Service | Storage | Zombie/Orphan resources are specifically cloud assets that are not currently attached to any virtual machine or compute instance. These completely disconnected resources continue to generate costs while providing no active value to your organization.
Unattached volumes, often referred to as "Orphan", "Zombie" volumes, are storage resources that are not currently in use by any virtual machine or compute instances. These volumes can incur unnecessary costs if not managed properly. | Here's how we identify and categorize these volumes across AWS, Azure, and GCP:
A volume is considered a zombie if it is not attached to any instance. We categorize the severity based on the duration the volume has been unattached:
- Less than 1 day: Not yet considered a zombie.
- 1 to 7 days: Low severity.
- 7 to 30 days: Medium severity.
- More than 30 days: High severity. | Managing these unattached volumes is crucial to optimize costs and ensure efficient use of resources. By identifying and addressing zombie volumes promptly, you can avoid unnecessary expenses and maintain a streamlined cloud environment. |
| Zombie/Orphan | Network | Public IP address | Unused public IP addresses, often referred to as "Orphan" IPs, are resources that are not currently associated with any active instance or service. These IPs can incur unnecessary costs if not managed properly. | A public IP address is considered a zombie if it is not associated with any instance or service. We categorize the severity based on the duration the IP has been unused:
- Less than 1 day: Not yet considered a zombie.
- 1 to 7 days: Low severity.
- 7 to 30 days: Medium severity.
- More than 30 days: High severity. | Managing these unused public IP addresses is crucial to optimize costs and ensure efficient use of resources. By identifying and addressing zombie IPs promptly, you can avoid unnecessary expenses and maintain a streamlined cloud environment. |
| Zombie/Orphan | Network | Load Balancer | Orphaned load balancers are those that are not connected to any active instances, listeners, or backend services. These load balancers can incur unnecessary costs if not managed properly. | A load balancer is considered orphaned if it does not have any instances, listeners, or backend services attached to it. We categorize the severity based on the duration the load balancer has been orphaned. Here's how we identify and categorize these orphaned load balancers across AWS, Azure, and GCP:
- Less than 1 day: Not yet considered a zombie.
- 1 to 7 days: Low severity.
- 7 to 30 days: Medium severity.
- More than 30 days: High severity. | Managing these orphaned load balancers is crucial to optimize costs and ensure efficient use of resources. By identifying and addressing orphaned load balancers promptly, you can avoid unnecessary expenses and maintain a streamlined cloud environment. |
| Zombie/Resource Utilization Low | Device | Compute Instance | Unused virtual machines, are instances with low CPU, disk, and network usage over an extended period. These VMs can incur unnecessary costs if not managed properly. | A virtual machine is considered a zombie if it has low CPU, disk, and network usage. We categorize the severity based on the duration the VM has been underutilized:
- Less than 1 day: Not yet considered a zombie.
- 1 to 7 days: Low severity.
- 7 to 30 days: Medium severity.
- More than 30 days: High severity. | Managing these unused virtual machines is crucial to optimize costs and ensure efficient use of resources. By identifying and addressing zombie VMs promptly, you can avoid unnecessary expenses and maintain a streamlined cloud environment. |
| Ghost | - Device
- Service | - Compute instance
- Storage | Ghosts are assets that cause dangling or untrusted DNS records due to deletion. These records can result in potential domain takeover, causing significant security risk. | N/A | Managing dangling DNS records is crucial to ensure that the environment is protected from the potential domain takeover. By identifying and addressing these issues promptly, you can secure the environment. |
| Noncompliant/Public Access | Network | Firewall | Misconfigured security groups with overly permissive rules can expose your cloud environment to potential security threats. Specifically, security groups configured to allow inbound traffic from any IP address (0.0.0.0/0) pose a significant risk. | Here's how we identify and categorize these misconfigurations in AWS:
A security group is considered misconfigured if it has an inbound rule allowing traffic from 0.0.0.0/0. This configuration is flagged with a medium severity level due to the potential security risks. | Managing these misconfigured security groups is crucial to protect your cloud environment from unauthorized access and potential attacks. By identifying and addressing these issues promptly, you can enhance your security posture and ensure compliance with best practices. |
| Noncompliant/Public Access | Device | Compute Instance | Exposed virtual machines, compute instances which are configured with public IP addresses and accessible over the internet, can pose significant security risks. | Here's how we identify and categorize these exposed VMs across AWS, Azure, and GCP:
A virtual machine/compute instance is considered exposed if it is configured with a public IP address and is accessible using that public IP. This configuration is flagged with a medium severity level due to the potential security risks. | Managing these exposed virtual machines is crucial to protect your cloud environment from unauthorized access and potential attacks. By identifying and addressing these issues promptly, you can enhance your security posture and ensure compliance with best practices. |
| Noncompliant/Public Access | Service | Storage | Publicly accessible object storage can expose sensitive data to unauthorized access, posing significant security risks. | Here's how we identify and categorize these public storage instances across AWS, Azure, and GCP:
An object storage instance is considered public if it is accessible over the internet without any restrictions. This configuration is flagged with a medium severity level due to the potential security risks. | Managing publicly accessible object storage is crucial to protect your data from unauthorized access and potential breaches. By identifying and addressing these issues promptly, you can enhance your security posture and ensure compliance with best practices. |
| Noncompliant/Unencrypted | Service | Storage | Unencrypted storage volumes can expose your data to potential security threats, making it crucial to ensure that all volumes are encrypted. | Here's how we identify and categorize unencrypted AWS EBS volumes:
A storage volume is considered unencrypted if it does not have encryption enabled. This configuration is flagged with a high severity level due to the significant security risks. | Managing unencrypted storage volumes is essential to protect your data from unauthorized access and potential breaches. By identifying and addressing these issues promptly, you can enhance your security posture and ensure compliance with best practices. |
| | | | | | |
| Managing Misconfigured Security Groups in AWS | | | Misconfigured security groups with overly permissive rules can expose your cloud environment to potential security threats. Specifically, security groups configured to allow inbound traffic from any IP address (0.0.0.0/0) pose a significant risk. Here's how we identify and categorize these misconfigurations in AWS. | A security group is considered misconfigured if it has an inbound rule allowing traffic from 0.0.0.0/0. This configuration is flagged with a medium severity level due to the potential security risks. | Managing these misconfigured security groups is crucial to protect your cloud environment from unauthorized access and potential attacks. By identifying and addressing these issues promptly, you can enhance your security posture and ensure compliance with best practices. |
> Macro (excerpt)
>
> | | | | | |
> | --- | --- | --- | --- | --- |
> | **Current Info: Needs review** | | | | |
> | Managing Missing DNS Records Across Cloud and On-Premises Environments | | | Missing DNS records, including forward (A-Record) and reverse (PTR-Record) records, can lead to connectivity and resolution issues within your network. Here's how we identify and categorize these missing records across AWS, Azure, GCP, and on-premises environments: | A DNS record is considered missing if:
- A-Record: The forward DNS record for a public IP address is not available.
> - PTR-Record: The reverse DNS record for a public IP address is not available.
> - Platforms Affected
> - AWS: EC2 instances with missing A-Records or PTR-Records.
> - Azure: Virtual machines with missing A-Records or PTR-Records.
> - GCP: Compute instances with missing A-Records or PTR-Records.
> - On-Premises: Various devices (bep_devices, dhcp_devices, ipmeta_devices, ngc_devices, ni_devices) with missing A-Records or PTR-Records. |
> | Managing Misconfigured Security Groups in AWS | | | Misconfigured security groups with overly permissive rules can expose your cloud environment to potential security threats. Specifically, security groups configured to allow inbound traffic from any IP address (0.0.0.0/0) pose a significant risk. Here's how we identify and categorize these misconfigurations in AWS. | A security group is considered misconfigured if it has an inbound rule allowing traffic from 0.0.0.0/0. This configuration is flagged with a medium severity level due to the potential security risks. |
> | Managing Exposed Virtual Machines Across Cloud Platforms | | | Exposed virtual machines, which are configured with public IP addresses and accessible over the internet, can pose significant security risks. Here's how we identify and categorize these exposed VMs across AWS, Azure, and GCP: | A virtual machine is considered exposed if it is configured with a public IP address and is accessible using that public IP. This configuration is flagged with a medium severity level due to the potential security risks. |
> | Managing Publicly Accessible Object Storage Across Cloud Platforms | | | Publicly accessible object storage can expose sensitive data to unauthorized access, posing significant security risks. Here's how we identify and categorize these public storage instances across AWS, Azure, and GCP: | An object storage instance is considered public if it is accessible over the internet without any restrictions. This configuration is flagged with a medium severity level due to the potential security risks. |
> | Managing Unencrypted Storage Volumes on AWS | | | Unencrypted storage volumes can expose your data to potential security threats, making it crucial to ensure that all volumes are encrypted. Here's how we identify and categorize unencrypted AWS EBS volumes: | A storage volume is considered unencrypted if it does not have encryption enabled. This configuration is flagged with a high severity level due to the significant security risks. |