Cloud Host Security: Protecting Running and Stopped VMs

Published:

Mar 21, 2022

Reading time:

7 Minutes

Virtualization is a technology that needs little introduction. For the past several decades, virtual machines (VMs) have functioned as the core, foundational building blocks for enterprises and their business applications and mission critical workloads. 

Even with emerging technologies like containers, Kubernetes, and serverless, cloud virtual machines (VMs) are used widely by organizations – a trend that isn’t going away any time soon.

Flexera’s 2021 State of the Cloud Report detailed cloud VM adoption across major cloud service providers, including the following statistics for AWS, Azure, and Google Cloud:

  • 67% of organizations on AWS have over 50 VMs, with 31% having over 500 VMs
  • 63% of organizations on Azure have over 50 VMs, with 21% having over 500 VMs

36% of organizations on Google Cloud have over 50 VMs, with 5% having over 500 VMs

Chart showing the number of virtual machines per cloud by enterprise from the Flexera 2021 State of the Cloud Report

Latest statistics on VM adoption from Flexera

With hundreds or potentially thousands of VMs running across cloud infrastructure platforms, security teams need to ensure their critical workloads are identified and protected.

Requirements for Cloud VM Security

With cloud VMs being a major building block for enterprise workloads and applications, security requirements, spanning vulnerability detection and prioritization, compliance and governance, and runtime monitoring and protection are essential. 

Key security requirements include:

  • Prioritize vulnerabilities and patch outdated operating systems: Vulnerabilities in the OS could expose workloads to risk or provide a foothold for attackers to access sensitive data or move laterally across your cloud infrastructure. Patching vulnerabilities in a timely and regular manner, made easier when risks are prioritized, ensures the host OS is secure.
  • Identify misconfigurations and harden the host OS: Misconfigurations, such as an over privileged operating system or improperly configured network controls, add risk to workloads. Additionally, workloads that are non-compliant, either from industry compliance regimes or internal frameworks, make passing audits timely and difficult or can even expose the business to fines or penalties from compliance violations. By implementing best practices from the Linux CIS Benchmarks, Windows CIS Benchmarks, or other industry-specific standards, security teams improve the risk posture of their workloads while also ensuring compliance.
  • Continuously monitor workloads at runtime, including file integrity monitoring: Running workloads need to be monitored to ensure attackers are unable to gain access to critical file systems, such as connecting over the network, unauthorized API access, exposing improper access control measures by brute force attempts, or installing malware. Additionally, security teams need to gain visibility into file read and file write activity to be alerted should unwanted activities occur.
  • Incident response and alert investigation: Should suspicious or nefarious activity occur, security teams need to alert on activity to investigate the attack path or attack vectors. This ensures security issues are remediated quickly and the overall risk posture of workloads is improved.

Orca Security Platform: Multi-Cloud Host Security

The Orca Security Platform secures Linux and Windows VMs across AWS, Azure, and Google Cloud to ensure risks are prioritized, compliance is achieved, and runtime telemetry is centralized for actionable risk detection, alert resolution, and incident response. 

Orca’s patent-pending SideScanning technology collects data, with read-only access, from the workloads’ runtime block storage and retrieves cloud configuration metadata via APIs. This allows Orca to detect vulnerabilities, malware, misconfigurations, lateral movement risk, weak and leaked passwords, and unsecured PII – all without any performance impact on your workloads.

Orca tracks all of your VMs, in addition to all of your other cloud assets, to provide a centralized view into their location, configuration status, vulnerability posture, and additional critical telemetry.

A single view into all VMs, both running and stopped, on AWS, Azure, and Google Cloud

Clicking on any VM provides even deeper detail into alert information, prioritized for analysis. Security teams can quickly audit networking information, packages, attack vectors, security logs, and more. This ensures that teams have everything they need to protect their VMs or investigate security issues. 

In addition, all security alerts across both VMs and other assets are mapped to the MITRE ATT&CK Framework and corresponding techniques. This helps security teams better understand the risks and potential threats to their workloads.

Detailed asset view

Orca offers 40+ pre-built compliance frameworks with hundreds of mapped policies covering the CIS Benchmarks, NIST CSF, PCI-DSS, HIPAA, and more. Policies can always be filtered by checks that are Passed or Failed with guidance on how to properly configure or address compliance issues.

Compliance detail view for a Windows VM

Why Securing Stopped VMs is Needed

While many organizations recognize that they need to secure their running workloads, many scenarios exist for auditing the risk posture of stopped VMs. 

This is a use case where agent-based solutions, which require agents to be installed and running on the VM themselves, are unable to provide any insights into the vulnerability posture or compliance status of the workload. Stopped VMs are traditionally a complete blind spot for security teams, but in reality they’re one click in the cloud UI away from running again.

In cloud environments, it’s so easy to instruct your DevOps team with cloud access to stop machines that aren’t in use. Not only does it lower the attack surface and reduce risk, but it reduces the costs for these resources on your cloud spend bill. 

However, many times these VMs are stopped and become an asset that teams are too afraid to delete. For example, teams ask what if that’s needed again or why did we provision this in the first place?

Stopped VMs tracked in the Asset Inventory view along with other cloud assets

Within the Orca UI, security teams can quickly filter for both Running or Stopped VMs and see their status, along with VM name, ID, Cloud Account, Metadata, Attack Vector map, and more. In the screenshot above, Orca shows a simple filtered view for Stopped VMs, of which there are 39 out of thousands of total cloud assets; clicking on any VM allows the user to dive into the same detailed views as highlighted above. This view and information is valuable as highlighted in the scenarios below.

Scenario 1: Development Teams Turning Off VMs to Avoid Patching Them

Patching workloads and applications can be a burdensome process for development and DevOps teams. Usually, teams are much more focused on shipping code and deploying applications, rather than wanting to fix misconfigurations or vulnerabilities. 

Many times, security teams have told us their development teams aim to avoid patching issues by turning off virtual machines. Orca removes this issue by showing both Running and Stopped VMs in a single dashboard.

Scenario 2: Mandated Vulnerability Scan Cadences Requires Starting Stopped Machines

Common vulnerability management strategies include attesting to auditors that you are scanning all machines in your environment every month, quarter, or year. Traditional agent-based scanners require that the machine be started so the agent can use the CPU, RAM, and networking of the host machine. 

However, this leads to starting an aging, unpatched machine just to perform a scan. This sets security teams up for failure – the only way to see vulnerability data is to start a machine that is old and almost certainly unpatched to the most current threats like log4j

Scenario 3: Investigating Stopped Machines to Clean Up Your Cloud Account

When security or infrastructure teams see stopped VMs, eventually they decide it’s best to terminate these machines. 

However, that stopped machine is a complete black box to traditional tools. You can see metadata from the cloud provider, but without a tool like Orca, you can’t see security logs, installed packages, login data, compliance status, or other in-depth details. Also, starting the machine up to do an investigation will likely require a break-glass procedure to access the machine and do an initial security investigation.

With the Orca Security Platform, security teams have the most up-to-date security telemetry and risk prioritization to secure their cloud workloads and cloud native applications.

See Orca’s Cloud VM Security in Action Today

Orca Security protects your entire cloud estate, spanning cloud infrastructure, workloads, data, and identities across the world’s largest clouds – delivering comprehensive cloud security in minutes. To learn more, sign up for our free risk assessment or download our latest data sheet.

Keith Mokris is the Vice President of Product Marketing and Jacob Graves is a Senior Security Engineer at Orca Security.