Navigating Public Cloud Vulnerability Management: When To Choose Network Scanners, Agents or Agentless

There are various approaches to managing vulnerabilities on cloud workloads, and knowing which vulnerability scan method to use is critical to your success. However, there isn’t a universally correct choice. How can you identify the best approach for you?

While network-based, agent-based, and agentless vulnerability scans all identify vulnerabilities, there are tradeoffs, and the ideal approach depends on your specific use case, requirements and constraints. This blog explores the different methods and discusses their application to virtual machines and containerized workloads.

Cloud vulnerability management overview

^{(Tenable Cloud Security: Vulnerability management dashboard widgets)}

Cloud vulnerability management focuses on scanning the base operating systems, such as Linux and Windows, and other software installed on cloud instances to identify vulnerabilities. Although vulnerability management has been done for decades, your public cloud workloads may benefit from a different approach.

Traditional scan methods like network scans and agent installations, such as Tenable’s Nessus Agents, may be viable options for long-lived virtual machines in some public cloud environments. However, these methods are not ideal for short-lived virtual machines and containerized workloads. It all comes down to understanding the best approach for acquiring vulnerability data for a given use case.

Scanning public cloud virtual machines

You may have public-cloud virtual machines that closely resemble on-premises virtual machines in their deployment method, configuration and lifespan. Conversely, you may have virtual machines that have more cloud-native characteristics. Many organizations have both. This is often determined by where on the cloud security maturity journey that deployment is.

Choosing the best vulnerability scanning method for your public-cloud virtual-machine use case will depend on factors like the lifespan, size and accessibility of the virtual machine.
 

^{(Tenable Cloud Security: Virtual machines with vulnerabilities)}

Network-based scanning

Network-based scanning entails deploying a separate scanner virtual machine within each virtual private cloud or virtual network, thereby ensuring isolation while providing necessary access. Administrative credentials are necessary for comprehensive results; otherwise, scans are limited to external views, such as those provided by open ports, service versions and operating system versions. 

This approach is suitable for public-cloud virtual machines with OS-level administrative credentials and network accessibility such that the scanner can reach targets on all ports and protocols. Each network scanner is typically deployed as a large, long-lived virtual machine. These scanner virtual machines add to a customer’s cloud operational costs.

Advantages:

• The most comprehensive scan type when administrative credentials are provided
• No agents to deploy
• Supports devices that can’t be scanned with agents, such as network devices
• Consistent scanning method for those also scanning on-premises workloads

Considerations:

• It requires administrative credentials for each scan target.
• Scanner virtual machines must be deployed in cloud accounts, usually per Virtual Private Cloud (VPC) / Virtual Network (VNET), which can be costly.
• Scans can impact scan target performance, though this can be tuned.
• Requires wide-open port and protocol access from the scanner to the scan targets.
• Targets must be running and available via IP address at scan time.
• Network-based scans are manually scheduled activities.

Common use case:

• Long-lived virtual machines with administrative access and network accessibility

Agent-based scanning

Agent-based scanning involves installing agents, such as Nessus agents or cloud-provider agents, on each target virtual machine. Agents run within each cloud virtual machine and report findings only for the virtual machine on which they are running.

This approach is suitable for larger virtual machines where agents are permitted but OS credentials are not provided. Agents eliminate the need for hosting separate scanner virtual machines, thus reducing complexity and costs. Agents’ installation and configuration can usually be automated during the deployment of public-cloud virtual machines. 

Advantages:

• No scanner virtual machines to deploy and maintain
• Reduced cost compared with deploying a scanner virtual machine per VPC/VNET
• No credential management required
• Microsegmented environments supported

Considerations:

• Agents are required on each workload and they must be managed.
• Agents require connectivity to an agent manager (usually outbound TCP:443).
• Targets must be running and available at scan time.
• They’re not ideal for ephemeral workloads.
• Agents cannot perform remote-only checks.
• There are minimum system requirements (2CPU/1GB RAM).
• Agent-based scans are manually scheduled activities.

Common use cases:

• Long-lived virtual machines where OS-level credentials are not provided
• Virtual machines in highly segmented/microsegmented environments

Agentless

Agentless scanning is a cloud-native approach leveraging the cloud service provider’s public APIs to gather information about virtual machines. This method entails creating cloud entitlements that permit access to authenticated cloud provider APIs. Agentless eliminates the need for network scanners and agents.

This approach is suitable for most public-cloud virtual machines, regardless of credential management or segmentation level. Agentless leverages APIs to connect to your virtual machines and to create a snapshot of their storage volumes. These volumes are then mounted to an ephemeral virtual machine that runs the vulnerability scan. It provides visibility into all virtual machines and their flaws without impacting running virtual machines. OS-level credentials and port accessibility are not necessary, which reduces operational overhead and increases scalability.

Advantages:

• Cloud-native and API-driven
• No scanners or agents to deploy and manage
• No credential management or port accessibility required
• Works with virtual machines of all sizes
• No impact on virtual machines
• Saves money by eliminating the need for scanner virtual machines
• Access granted via cloud entitlements
• Can be used on stopped virtual machines

Considerations:

• Agentless is typically a capability of cloud security tools, not traditional vulnerability management tools.
• Agentless results are typically CVE-based.
• Agentless usually does not provide the same level of detail as network-based or agent-based approaches.
• Agentless scans are automatically performed, usually once daily.

Common use cases:

• Virtual machines where OS-level credentials are not provided and agents are not permitted or desired
• Short-lived virtual machines

Scanning public cloud containerized workloads

Containerized workloads are very different from virtual machines and scanning them for vulnerabilities requires adapting to their ephemeral nature. Choosing the best vulnerability scanning method for your public cloud containerized workload use case will depend on factors like how the containers are orchestrated and your vulnerability management requirements.
 

^{(Tenable Cloud Security: Containerized workloads with vulnerabilities)}

Network-based scanning

Network-based scanning is usually not applicable to containerized workloads. Some vendors, including Tenable, detect if a scanned host is running Docker, but they do not scan the containers running on the Docker host for vulnerabilities. 

Kubernetes agent-based scanning

Agent-based scanning takes on a different meaning when referring to containerized workloads. Traditional vulnerability scanning agents are not well suited to running on a container due to the agent size, resource requirements, and network connectivity requirements. 

However, Docker containers are typically managed by a container orchestration platform such as Kubernetes. Kubernetes agent-based scanning provides deep visibility and real-time security by deploying a lightweight sensor on each Kubernetes workload via a Helm chart, making it ideal for continuously monitoring containerized workloads. 

Advantages:

• No thick agent software to deploy or manage
• Deployed via Helm chart
• Works with cloud-managed Kubernetes (e.g., EKS, AKS, GKE) as well as self-managed Kubernetes and Red Hat OpenShift environments
• Kubernetes agent-based scans are automatically performed, usually hourly 

Considerations:

• Kubernetes agent-based scanning is typically a capability of cloud security tools, not traditional vulnerability management tools
• Kubernetes agentless results are typically CVE-based

Common use cases:

• Containerized workloads within a Kubernetes or Red Hat OpenShift Container orchestration platform

Agentless

Containerized workloads in public cloud environments are typically managed by a container orchestration platform such as Kubernetes. Kubernetes nodes – the hosts on which containers run – are virtual machines running in public-cloud environments. Therefore, the agentless method is the same as the one described earlier in the “Scanning Public Cloud Virtual Machines” section, with the added benefit of identifying the containers running on the Kubernetes nodes. This method will also identify the software bill of materials (SBOM), and the vulnerabilities associated with each container running on the Kubernetes node.

Advantages:

• Cloud native and API driven
• No scanners or agents to deploy and manage
• Supports cloud-managed Kubernetes nodes
• Access is granted via cloud entitlements
• Can be used on stopped Kubernetes nodes (virtual machines)

Considerations:

• Agentless is typically a capability of cloud security tools, not traditional vulnerability management tools.
• Agentless results are typically CVE-based.
• Agentless scans are less frequent than Kubernetes agent-based scans.

Common use cases:

• Containerized workloads within a cloud-managed Kubernetes container orchestration platform (e.g., EKS, AKS, GKE)

A note about container images

Containers are the running instances of a container image. This blog is focused on public-cloud workloads, and container images are not workloads. However, it is worth noting that the images themselves can also be scanned. This is usually accomplished by scanning the container image within the CI/CD pipeline, and by integrating with a container image registry to scan all the container images stored within. 

Summary

Choosing the right vulnerability scanning method for public-cloud workloads is crucial and depends heavily on specific use cases and requirements. Each method offers unique advantages and considerations for both virtual machines and containerized workloads. It is essential to understand these differences and to align them with your workload lifespan, accessibility, and overall vulnerability management strategy. Tenable offers all these methods to help you identify, contextualize, prioritize and remediate vulnerabilities in any environment anywhere. 

For more information on vulnerability management in the cloud watch the webinar “A Cyber Pro’s Guide to Cloud-Native Vulnerability Management: Start, Scale, and Secure with Confidence” and read the data sheet, “Vulnerability Management Built for Multi-Cloud Environments”.