9.1 Virtual Machine (VM) Hardening, Golden Images & Immutable Infrastructure

9.1 Virtual Machine (VM) Hardening, Golden Images & Immutable Infrastructure

Quick Answer: Under the Cloud Computing Shared Responsibility Model for Infrastructure as a Service (IaaS), the cloud service provider secures the physical host, hypervisor, and underlying virtualization fabric, while the cloud customer retains full accountability for securing the Guest Operating System (OS), runtime applications, middleware, and network access controls. To establish a defensible workload posture, organizations must enforce Virtual Machine (VM) hardening baselines (such as CIS Benchmarks Level 1 and Level 2), construct automated Golden Image pipelines with continuous vulnerability scanning and cryptographic signing, and transition from mutable, manually patched servers to Immutable Infrastructure ("Cattle vs. Pets"). Furthermore, production environments must eradicate direct administrative network exposure (SSH port 22 and RDP port 3389) by deploying outbound-only, identity-federated Session Managers that log all activity without exposing public IP addresses.

In traditional on-premises data centers, server administration was defined by manual configurations, ad-hoc patching cycles, and long-lived physical hosts. In the cloud, compute instances are software-defined, ephemeral, and instantiated via API calls. However, when an enterprise provisions a Virtual Machine (such as an Amazon EC2 instance, Azure Virtual Machine, or Google Compute Engine instance), the virtual machine inherits the full vulnerability surface of a conventional operating system.

The Cloud Security Alliance (CSA) Security Guidance v5 (Domain 8: Cloud Workload Security) and the Cloud Controls Matrix (CCM v4.1) domain IVS (Infrastructure & Virtualization Security) emphasize that compute workloads are the execution engines of business logic and data processing. Compromised compute workloads serve as the primary launching pad for lateral movement, credential theft, and data exfiltration. Consequently, workload security must be engineered systematically into every phase of the workload lifecycle—from baseline operating system configuration to automated deployment pipelines and zero-trust runtime access.

---

The IaaS Shared Responsibility Boundary for Compute

Understanding workload security begins with delineating the demarcation line between the Cloud Service Provider (CSP) and the Cloud Customer under IaaS:

Because the customer exercises sovereign administrative authority over the guest operating system, any misconfiguration, unpatched vulnerability, or rogue daemon running within the VM operating system represents an unmitigated risk entirely under the customer's purview.

---

Virtual Machine Hardening Baselines

Hardening is the systematic reduction of a system's vulnerability surface through the elimination of non-essential software, services, protocols, and default credentials, coupled with the enforcement of defense-in-depth configuration parameters.

┌────────────────────────────────────────────────────────────────────────┐
│                     OS HARDENING TAXONOMY (IaaS VM)                    │
├────────────────────────────────────────────────────────────────────────┤
│  1. ATTACK SURFACE REDUCTION                                           │
│     • Remove legacy daemons (rsh, telnet, ftp, rpcbind, NIS)           │
│     • Remove build toolchains (gcc, gdb, make, strace) from prod       │
│     • Disable unused network protocols (IPv6 if unused, DCCP, SCTP)    │
├────────────────────────────────────────────────────────────────────────┤
│  2. KERNEL-LEVEL HARDENING (/etc/sysctl.conf)                          │
│     • ASLR: kernel.randomize_va_space = 2                              │
│     • SYN Cookies: net.ipv4.tcp_syncookies = 1                         │
│     • Disable IP Forwarding: net.ipv4.ip_forward = 0                   │
│     • Ignore ICMP Redirects: net.ipv4.conf.all.accept_redirects = 0    │
│     • Disable Core Dumps: fs.suid_dumpable = 0                         │
├────────────────────────────────────────────────────────────────────────┤
│  3. FILESYSTEM ISOLATION (/etc/fstab)                                  │
│     • Partition /tmp, /var, /var/log, /var/tmp, /home                  │
│     • Mount /tmp with: nodev, nosuid, noexec                           │
│     • Mount /var/tmp with: nodev, nosuid, noexec                       │
│     • Mount /dev/shm with: nodev, nosuid, noexec                       │
├────────────────────────────────────────────────────────────────────────┤
│  4. ACCESS & IDENTITY RESTRICTIONS                                     │
│     • Disable root login over SSH (PermitRootLogin no)                 │
│     • Enforce public-key authentication; disable PasswordAuthentication│
│     • Implement PAM modules for strong password complexity & lockout   │
└────────────────────────────────────────────────────────────────────────┘

CIS Benchmarks and DISA STIGs

Enterprise cloud programs do not invent hardening standards from scratch. Instead, they align with internationally recognized security baselines:

• Center for Internet Security (CIS) Benchmarks: Consensus-based configuration guidelines recognized globally. CIS publishes OS-specific baselines (such as CIS Amazon Linux 2023, CIS Ubuntu Linux, CIS Microsoft Windows Server) categorized into two tiers:
  • CIS Level 1 (Baseline Profile): Essential security configurations that can be implemented with minimal impact on service functionality and operational utility.
  • CIS Level 2 (Defense-in-Depth Profile): Highly restrictive configurations intended for sensitive or regulated environments (e.g., PCI DSS, HIPAA, FedRAMP). Level 2 profiles enforce strict auditing, disable legacy subsystem compatibility, and may impact application functionality if not rigorously tested.
• Defense Information Systems Agency Security Technical Implementation Guides (DISA STIGs): Highly prescriptive configuration standards mandated by the United States Department of Defense (DoD), focusing on stringent technical controls, cryptographic requirements, and deep auditing.

OS Minimization: Purging Daemons, Compilers & Debuggers

A primary hardening objective is establishing a minimal operating system footprint:

• Disable Unnecessary Network Services: Standard Linux server distributions historically ship with auxiliary daemons enabled by default (e.g., avahi-daemon, cups, rpcbind, inetd). Cloud workloads serving as web servers or microservices have no requirement for print services, local mail transport agents (MTAs) listening on port 25, or zero-configuration networking. Every listening port increases the potential exploit surface.
• Purge Development Toolchains from Production: Compilers, interpreters, and debuggers (e.g., gcc, make, gdb, strace, nmap, netcat, tcpdump) must never be deployed on production VM instances. If a threat actor achieves arbitrary code execution (such as through a web application command injection vulnerability), the presence of local build tools enables them to download raw C exploit source code, compile local privilege escalation exploits in memory, and compromise the host kernel. Hardened base images strip all compilers and package management build tools prior to release.

Kernel Tuning via sysctl.conf

Linux kernel parameters governing memory safety and network stack behavior should be explicitly hardened in /etc/sysctl.d/99-security.conf:

• Address Space Layout Randomization (ASLR): Setting kernel.randomize_va_space = 2 randomizes the memory addresses of the stack, virtual dynamic shared objects (VDSO), shared memory libraries, and the data segment, neutralizing Return-Oriented Programming (ROP) and buffer overflow exploitation attempts.
• TCP SYN Flood Protection: Setting net.ipv4.tcp_syncookies = 1 forces the kernel to utilize cryptographic SYN cookies when the network socket listen queue overflows, protecting against TCP state-exhaustion Denial of Service (DoS) attacks.
• Disabling IP Packet Routing: Cloud VM instances (unless explicitly acting as software routers or VPN gateways) must never route packets between network interfaces. Setting net.ipv4.ip_forward = 0 prevents the VM from being abused as an unauthorized network bridge.
• Ignoring ICMP Redirects: Setting net.ipv4.conf.all.accept_redirects = 0 and net.ipv6.conf.all.accept_redirects = 0 blocks malicious network nodes from forging ICMP redirect messages to alter the host routing table (man-in-the-middle attacks).
• Restricting Kernel Pointer Leaks & Core Dumps: Setting kernel.kptr_restrict = 2 hides kernel symbol addresses from unprivileged users, and setting fs.suid_dumpable = 0 prevents setuid binaries from dumping memory cores that might contain plaintext cryptographic keys or credentials.

Filesystem Segmentation and Mount Options

An enterprise Linux hardening baseline enforces strict filesystem segregation in /etc/fstab. Placing all directories on a single root partition (/) exposes the system to complete denial of service if logs fill the disk, and allows attackers to execute unauthorized binaries from world-writable directories.

• Dedicated Partitions: The directories /tmp, /var, /var/log, /var/tmp, and /home should reside on separate logical volumes or virtual disks.
• Mount Flag Enforcements:
  • nodev: Prevents the creation or execution of character and block special devices (device nodes) on the partition, blocking unauthorized hardware interface access.
  • nosuid: Ignores Set-User-Identifier (SUID) and Set-Group-Identifier (SGID) bits, preventing attackers from abusing local binaries to escalate to root privileges.
  • noexec: Prohibits the direct execution of any binary on the mounted filesystem. Applying noexec,nosuid,nodev to /tmp, /var/tmp, and /dev/shm ensures that even if an attacker successfully uploads a malicious shell script or compiled binary into a temporary world-writable directory, the kernel refuses to execute it.

---

The Golden Image Pipeline: Automated Image Construction

Manual server hardening does not scale in cloud-native operations and introduces human error. The Cloud Security Alliance mandates the deployment of an Automated Golden Image Pipeline (often called an Image Factory). A Golden Image (an Amazon Machine Image [AMI], Azure Compute Gallery Image, or Google Cloud Machine Image) is a pre-configured, tested, patched, and cryptographically verified virtual machine template used to launch instances across the enterprise.

┌────────────────────────────────────────────────────────────────────────┐
│                     AUTOMATED GOLDEN IMAGE FACTORY                     │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│   [Base OS ISO / Upstream AMI]                                         │
│                │                                                       │
│                ▼                                                       │
│   ┌───────────────────────────┐                                        │
│   │ Automated Builder Engine  │ (HashiCorp Packer / EC2 Image Builder) │
│   └────────────┬──────────────┘                                        │
│                │                                                       │
│                ▼                                                       │
│   ┌───────────────────────────┐                                        │
│   │ Provisioning & Hardening  │ (Ansible / Chef / Shell Scripts)       │
│   │ • Apply CIS Level 2 rules │                                        │
│   │ • Install security agents │ (EDR, Vulnerability Scanner, Logging)  │
│   │ • Strip dev tools & caches│                                        │
│   └────────────┬──────────────┘                                        │
│                │                                                       │
│                ▼                                                       │
│   ┌───────────────────────────┐                                        │
│   │ Automated Security Audit  │ (InSpec / OpenSCAP Compliance Scans)   │
│   └────────────┬──────────────┘                                        │
│                │ Passes CIS Validation?                                │
│        ┌───────┴───────┐                                               │
│       Yes              No ──► [Pipeline Fails & Alerts Security]       │
│        │                                                               │
│        ▼                                                               │
│   ┌───────────────────────────┐                                        │
│   │ Vulnerability CVE Scan    │ (Static Disk Analysis for CVEs)        │
│   └────────────┬──────────────┘                                        │
│                │ 0 High/Critical CVEs?                                 │
│        ┌───────┴───────┐                                               │
│       Yes              No ──► [Pipeline Fails & Quarantine]            │
│        │                                                               │
│        ▼                                                               │
│   ┌───────────────────────────┐                                        │
│   │ Cryptographic Signing     │ (KMS Private Key / Cosign / Attest)    │
│   └────────────┬──────────────┘                                        │
│                │                                                       │
│                ▼                                                       │
│   ┌───────────────────────────┐                                        │
│   │ Private Image Catalog     │ (Distributed to Authorized Accounts)   │
│   └───────────────────────────┘                                        │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

Pipeline Tooling: HashiCorp Packer and Cloud Image Builders

Modern image construction is declared as Infrastructure as Code (IaC):

• HashiCorp Packer: An open-source tool that automates the creation of identical machine images for multiple cloud platforms from a single configuration file (HCL or JSON). Packer spins up an ephemeral VM, executes configuration management playbooks, captures the volume snapshot, registers the target AMI/VHD, and terminates the temporary VM.
• Cloud-Native Image Builders: Managed services such as AWS EC2 Image Builder or Azure VM Image Builder provide fully managed pipelines that natively integrate with cloud IAM, AWS Systems Manager, and native vulnerability scanning services.

Pipeline Stages: Construction, Validation, Attestation & Release

1. Upstream Ingestion: The pipeline fetches the latest official, vendor-supported minimal operating system image.
2. Automated Provisioning: Configuration management tools (such as Ansible, Chef, or Puppet) apply security baselines: disabling unnecessary services, configuring /etc/sysctl.conf, establishing /etc/fstab mount restrictions, creating logging configurations (forwarding to Amazon CloudWatch, Azure Monitor, or enterprise SIEM), and installing enterprise endpoint detection and response (EDR) agents.
3. Compliance Verification (Automated Testing): Automated auditing frameworks (such as Chef InSpec or OpenSCAP) execute automated validation scripts against the newly configured instance. If any required CIS control fails (e.g., if a world-writable directory is detected or an unauthorized port is open), the pipeline halts immediately, discarding the build.
4. Static Vulnerability Scanning: Before the image is published, automated vulnerability scanners analyze the underlying disk volume for known Common Vulnerabilities and Exposures (CVEs) across all installed software packages. Any unpatched High or Critical severity CVE triggers an automated pipeline failure.
5. Cryptographic Signing & Provenance Attestation: To prevent unauthorized tampering or injection of rogue images into the production catalog, the pipeline cryptographically signs the image metadata using a private key managed in a Hardware Security Module (HSM) or cloud Key Management Service (KMS). The cryptographic signature and build provenance (identifying commit hash, build timestamp, and pipeline ID) are recorded in an attestation register.
6. Catalog Distribution & Sharing: The finalized image is encrypted using a customer-managed key (CMK) and shared strictly with authorized enterprise accounts and project subscriptions via private image catalogs (such as AWS AMI sharing or Azure Compute Gallery).

Image Versioning, Lifecycle & Deprecation Governance

Golden images are not permanent assets. The cloud workload environment evolves constantly as new zero-day vulnerabilities emerge:

• Semantic Versioning: Golden images must adhere to strict semantic versioning (e.g., golden-linux-v2.4.1), where patch releases represent routine vulnerability remediations and minor/major versions represent OS or architectural updates.
• Continuous Vulnerability Monitoring of Dormant Images: An image stored in an AMI catalog may be free of CVEs on Day 1, but by Day 14, three new Critical vulnerabilities may be disclosed against its installed packages. Enterprise cloud posture tools must continuously evaluate stored golden images against updated threat databases.
• Automated Deprecation and Tombstoning: Enterprise governance policies must enforce an image expiration window (typically 30 to 60 days). When a new golden image is released, preceding versions are marked as Deprecated (blocking new instance launches while allowing existing workloads to run). After an additional grace period (e.g., 30 days), legacy images are deregistered and tombstoned, preventing developers from launching workloads from stale, vulnerable baselines.

---

The Immutable Infrastructure Paradigm: "Cattle vs. Pets"

One of the most profound architectural shifts championed by CSA Security Guidance v5 is the transition from Mutable Infrastructure to Immutable Infrastructure.

┌────────────────────────────────────────────────────────────────────────┐
│                     MUTABLE VS. IMMUTABLE PARADIGM                     │
├────────────────────────────────────────────────────────────────────────┤
│  MUTABLE INFRASTRUCTURE ("PETS")                                       │
│  • Servers are long-lived, uniquely named, and individually nurtured   │
│  • Administrators log in via SSH/RDP to execute manual updates & fixes │
│  • Software patches applied in-place over months and years             │
│  • Result: Catastrophic Configuration Drift & "Snowflake Servers"      │
│  • Forensic complexity: Hard to distinguish normal updates from malware│
├────────────────────────────────────────────────────────────────────────┤
│  IMMUTABLE INFRASTRUCTURE ("CATTLE")                                   │
│  • Instances are ephemeral, standardized, disposable, and numbered     │
│  • Zero in-place patching; zero direct interactive SSH/RDP logins      │
│  • Every update requires baking a new Golden Image via pipeline        │
│  • Replacement via Automated Rollout (Blue/Green or Rolling Refresh)   │
│  • Result: Zero Configuration Drift; 100% reproducible environments    │
│  • Security assurance: Compromised instances can be instantly destroyed│
└────────────────────────────────────────────────────────────────────────┘

The Failure of the "Pet" Model: Configuration Drift & Snowflake Servers

In the legacy "Pet" model, servers are treated as unique, precious entities with high emotional investment. When a software bug or security vulnerability occurs, an engineer connects via SSH or RDP and manually tweaks configuration files, restarts daemons, or installs patches. Over time, this operational habit causes Configuration Drift:

• Systems drift away from their documented baseline.
• No two servers in an application cluster remain identical, creating "Snowflake Servers."
• Security teams cannot determine whether an unusual binary or modified configuration file represents legitimate emergency maintenance by a systems administrator or unauthorized persistence established by an Advanced Persistent Threat (APT).
• Disaster recovery becomes nearly impossible because reconstructing a drifted snowflake server from scratch fails.

The "Cattle" Model: Standardized, Ephemeral, and Replaced

In the immutable "Cattle" model, compute instances are treated as interchangeable, disposable units. The fundamental rule of immutable infrastructure is: $\text{Never update a running instance in-place. Always destroy and replace.}$

When a security patch, kernel update, or configuration change is required:

1. The change is committed to version-controlled Infrastructure as Code (IaC) repositories.
2. The automated Golden Image pipeline builds, scans, and publishes a new versioned base image.
3. Cloud orchestration engines (such as Auto Scaling Groups or Virtual Machine Scale Sets) execute an automated replacement strategy:
   • Rolling Instance Refresh: The orchestration engine launches new instances running the updated golden image, verifies their health checks, directs traffic to them via the Application Load Balancer, and terminates legacy instances one by one.
   • Blue/Green Deployment: An entirely separate, parallel environment (Green) running the new image is provisioned and tested. Once validated, load balancer traffic is shifted instantaneously from the legacy environment (Blue) to Green, and Blue is terminated.

Decoupling Compute from State

Immutable infrastructure is only possible when compute workloads are stateless. If an application writes transaction records or uploaded user files directly to the local VM virtual disk (e.g., /var/www/uploads), terminating the VM destroys corporate data. Therefore, immutable cloud architecture requires state decoupling:

• Persistent Relational/NoSQL Data: Offloaded to managed cloud database services (e.g., Amazon Aurora, Azure SQL, Google Cloud Spanner).
• User Sessions & Application State: Offloaded to distributed in-memory caching tiers (e.g., Redis, Memcached).
• Object Storage: Unstructured files and assets uploaded directly to cloud object storage (e.g., Amazon S3, Azure Blob Storage) using pre-signed URLs.
• Decoupled Logging: Application and system logs streamed instantaneously off-box via local logging forwarders to centralized log management platforms (CloudWatch, Datadog, Splunk) before instance termination.

---

Eliminating Direct Administrative Access (SSH/RDP Retirement)

Traditional systems administration relied on opening TCP port 22 (SSH) for Linux administration and TCP port 3389 (RDP) for Windows administration. In a cloud environment, exposing these ports directly to the internet—or even to internal corporate networks—presents severe architectural liabilities.

The Vulnerabilities of Traditional SSH/RDP Bastion Hosts

1. Public IP Exposure & Constant Scanning: Bastion hosts exposed on public subnets face continuous internet-scale automated port scanning, brute-force dictionary attacks, and zero-day protocol exploits.
2. Static Credential Sprawl & Private Key Management: Distributing static SSH private keys to hundreds of developers leads to compromised credentials stored on unencrypted developer laptops, lost keys, and non-existent key rotation policies.
3. Orphaned Authorized Keys: When contractors or employees depart the enterprise, removing their public keys from /home/user/.ssh/authorized_keys across thousands of running virtual machines is nearly impossible without automated configuration management.
4. Inadequate Auditability: Standard SSH connections encrypt the network payload end-to-end, preventing network inspection engines from observing commands typed by an administrator. Logging relies entirely on local host syslog, which can be modified or deleted by an administrator possessing root privileges.

Modern Session Proxy Architecture: Outbound-Only, Identity-Aware Access

To neutralize these risks, CSA Security Guidance v5 mandates the elimination of direct SSH/RDP network ingress in production. Enterprises transition to Cloud-Native Session Managers, such as AWS Systems Manager (SSM) Session Manager, Azure Bastion, and Google Cloud Identity-Aware Proxy (IAP) for TCP Forwarding.

┌────────────────────────────────────────────────────────────────────────┐
│               MODERN IDENTITY-AWARE SESSION PROXY ACCESS               │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│   [Security Administrator]                                             │
│            │                                                           │
│            ▼ 1. Authenticate via Web Console / CLI                     │
│   ┌────────────────────────────────────────┐                           │
│   │ Enterprise Identity Provider (IdP)     │                           │
│   │ • Enforces Phishing-Resistant MFA      │                           │
│   │ • Evaluates Device Compliance & Context│                           │
│   └──────────────────┬─────────────────────┘                           │
│                      │                                                 │
│                      ▼ 2. Issues Short-Lived Scoped Token              │
│   ┌────────────────────────────────────────┐                           │
│   │ Cloud Control Plane Session Service    │                           │
│   │ (AWS Systems Manager / Azure Bastion)  │                           │
│   └──────────────────┬─────────────────────┘                           │
│                      │                                                 │
│                      │ 3. Secure TLS Tunnel via Control Plane          │
│                      │    (No open inbound ports on VM!)               │
│                      │                                                 │
│                      ▼                                                 │
│            ┌────────────────────┐                                      │
│            │ Cloud Private Subnet│                                     │
│            │                    │                                      │
│            │   ┌─────────────┐  │                                      │
│            │   │ Compute VM  │  │ ◄─── Inbound Security Group: DENY ALL│
│            │   │  ┌───────┐  │  │                                      │
│            │   │  │ Agent │──┼──┼───── Outbound HTTPS (TCP 443) only  │
│            │   │  └───────┘  │  │      to Cloud Systems Manager API    │
│            │   └─────────────┘  │                                      │
│            └────────────────────┘                                      │
│                      │                                                 │
│                      ▼ 4. Centralized Command Auditing                 │
│   ┌────────────────────────────────────────┐                           │
│   │ Immutable Log Stream (S3 / CloudWatch) │ (Key-stroke logging,      │
│   │ & SIEM Security Analytics              │  session video capture)   │
│   └────────────────────────────────────────┘                           │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

Technical Mechanics of Cloud Session Managers

• Zero Inbound Security Group Openings: The target virtual machine resides in an entirely isolated private subnet with zero inbound rules enabled in its Virtual Firewall / Security Group. Port 22 and port 3389 are closed.
• Outbound-Only HTTPS Telemetry: A lightweight agent installed on the VM (e.g., the AWS SSM Agent) establishes an outbound-only, TLS 1.3 encrypted connection over TCP port 443 to the cloud provider's regional management API endpoints (or via private VPC Endpoints / Private Link). The VM initiates all traffic; no external packet ever touches the VM from the outside.
• IAM and Federated Authentication: Access is governed entirely by the cloud provider's IAM engine. Administrators authenticate against corporate Single Sign-On (Entra ID, Okta) using Phishing-Resistant MFA. Granular IAM policies dictate exactly which instances an engineer may access based on resource tags (e.g., Allow access ONLY if tag:Environment == 'Development').
• No Stored SSH Keys: Authentication does not use long-lived SSH keypairs. The session proxy dynamically multiplexes terminal commands across the outbound HTTPS control channel or injects short-lived, single-use ephemeral cryptographic certificates.
• Complete Session & Keystroke Auditing: Because the session proxy terminates at the cloud control plane, every individual keystroke, command invocation, and terminal response is captured in real time, cryptographically signed, and streamed to immutable cloud object storage (e.g., encrypted S3 buckets with Object Lock) and SIEM platforms for forensic auditability.

---

Comparison: Traditional Mutable Maintenance vs. Modern Immutable Hardening

---

Common Pitfalls & Real-World Anti-Patterns

1. "Baking" Secrets into Golden Images: Embedding static API keys, database credentials, or private certificates directly into the golden image filesystem during the Packer build phase. Once an image is published, anyone with access to the image can extract the credentials. Mitigation: Images must be completely generic; secrets must be fetched dynamically at runtime from managed secret vaults (e.g., AWS Secrets Manager, HashiCorp Vault) using temporary instance IAM roles.
2. Patching Running Production Systems in Emergencies: During a critical zero-day disclosure, administrators panic and SSH into production instances to manually update packages. This instantly reintroduces configuration drift and invalidates disaster recovery playbooks. Mitigation: Fast-track the emergency build through the automated Image Factory pipeline and execute an automated rolling refresh.
3. Failing to Automate Image Deprecation: Maintaining dozens of obsolete AMIs/VHDs in the cloud account catalog. Developers spinning up testing or disaster recovery environments inevitably select outdated, vulnerable images. Mitigation: Enforce automated image tombstoning policies that automatically deregister images older than 60 days.
4. Permitting "Temporary" SSH Inbound Security Group Rules: Engineers open port 22 to 0.0.0.0/0 in security groups for "quick debugging" and forget to remove the rule, leaving the production instance exposed to the internet. Mitigation: Enforce preventative Cloud Security Posture Management (CSPM) and Service Control Policies (SCPs) that instantly block and remediate any security group rule permitting public ingress on port 22 or 3389.