Securing Exposed Virtual Machines: Classification Definitions

In today's IT environments, whether cloud-based, on-premises, or hybrid, ensuring the security and efficiency of infrastructure is critical. Insights into cost savings, security risks, and technical debt are essential to maintaining a robust and optimized IT ecosystem.

One key area of concern is the management of virtual machines (VMs) configured with public IP addresses and exposed to the internet. These configurations can serve as entry points for unauthorized access, data breaches, and cyberattacks. Such vulnerabilities are not limited to cloud platforms like AWS, Azure, and GCP; they are also relevant to on-premises environments where similar risks exist.

This table highlights the importance of identifying and managing exposed VMs to address risks and improve overall infrastructure health. It covers how to recognize exposed VMs, assess their impact, and implement strategies to mitigate exposure. Proactively tackling these challenges enables organizations to enhance security, reduce costs, and address technical debt across their entire IT infrastructure, creating a safer and more resilient environment.

Classification	Overview	Identification and Severity Levels	Why it Matters

Classification

Overview

Identification and Severity Levels

Why it Matters

Managing Unattached (Zombie) Volumes Across Cloud Platforms

Unattached volumes, often referred to as "zombie" volumes, are storage resources that are not currently in use by any virtual machine or compute instance. 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.

Managing Unused Public IP Addresses Across Cloud Platforms

Unused public IP addresses, often referred to as "zombie" IPs, are resources that are not currently associated with any active instance or service. These IPs can incur unnecessary costs if not managed properly. Here's how we identify and categorize these zombie IPs across AWS, Azure, and GCP:

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.

Managing Orphaned Load Balancers Across Cloud Platforms

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. Here's how we identify and categorize these orphaned load balancers across AWS, Azure, and GCP:

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:

Less than 1 day: Not yet considered orphaned.
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.

Managing Unused Virtual Machines Across AWS

Unused virtual machines, often referred to as "zombie" VMs, are instances with low CPU, disk, and network usage over an extended period. These VMs can incur unnecessary costs if not managed properly. Here's how we identify and categorize these zombie VMs on AWS:

A virtual machine is considered a zombie if it has low CPU, disk, and network usage for the past 30 days. 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.

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 these missing DNS records is crucial to ensure proper network functionality and connectivity. By identifying and addressing these issues promptly, you can maintain a reliable and efficient network environment.

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.

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 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.

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 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.

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.

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.