You can scan cloud systems for security problems in multiple ways depending on what your instances are running, how long they’re up and whether or not they can run an agent or be accessed with administrative credentials. Network scanning, installed agents, or public cloud APIs can all report findings, but there are tradeoffs. In a recent episode of the Tenable Cloud Security Coffee Break series, we talked about each approach, the appropriate use cases and how Tenable Cloud Security can help.
If you’re managing cybersecurity for your organization, you know only too well the challenges of scanning every type of system you have for weaknesses. Whether they’re laptops, bare-metal servers or on-prem virtual machines, no single approach is ideal for every use case.
The same is true for public-cloud environments. Although network scanning, installed agents or public cloud APIs can all report findings, there are tradeoffs. During a recent episode of Tenable’s Cloud Security Coffee Break series, we sat down with Tenable’s Senior Cloud Security Engineer Ryan Bragg to talk about each approach.
What is cloud vulnerability management?
When we talk about vulnerability management and the pros and cons of using agents vs. going agentless, the focus is on scanning the base operating systems – often Linux and Windows – of cloud instances to identify vulnerabilities. Although the practice of vulnerability management dates back decades, there are different considerations when scanning public cloud workloads.
With long-running virtual machines, it’s perfectly valid in certain cases to perform network scans or to install agents like Tenable’s Nessus or cloud-vendor agents, like Systems Manager Agent (SSM) from Amazon Web Services (AWS.) Network scans and agents provide system telemetry security teams can use to identify and fix problems.
However, in cloud environments, where virtual machines are often short-lived, agents aren’t ideal. Agents can add overhead and complexity that’s less desirable in cloud workloads, many of which aren’t up and running long.
“Every approach has its pros and cons,” Bragg said. “I will never advocate a single approach for all use cases because it really comes down to ‘What is the best approach for acquiring vulnerability data within a given use case?’”
Network scanning in the public cloud
Let’s start with networking scanning. It’s best for public-cloud virtual machines for which OS-level credentials are available to the security team, and where the firewall and security rules permit the scanner to reach targets on all ports and protocols. These tend to be large, long-lived instances.
Network scanning is comprehensive, but it can impact the performance of each target. For networking scanning to work, you need to set up a separate virtual machine to host the Nessus scanner application, and this is usually done within each virtual private cloud (VPC) so the scanner has access to the cloud virtual machines within its VPC and virtual network (VNET) yet the VPC/VNET remains an isolation barrier.
The network scanner also needs to have administrative credentials to access each target. Otherwise, scan results are limited to the external view of a system, which mostly consists of the ports on which a system is listening (e.g., 22, 443), the service versions behind each open port, and the fingerprinted operating system version.
Network scanning use case:
- Large, long-lived virtual machines for which administrative credentials can be shared and used
Advantages:
- The most comprehensive scan type, when administrative credentials are provided
- No agents to deploy
- Supports devices that don’t have or can’t support agents (i.e. network devices)
Disadvantages:
- Requires admin credentials for each target in order to provide comprehensive results
- Network-scanner virtual machines must be deployed in cloud accounts, usually per VPC/VNET, which can be costly
- Scans can impact target performance, though this can be tuned
- Requires wide-open port access from the scanner to the scan targets
- Targets must be running and available at scan time
Agent-based scanning in the public cloud
In cases where network scanning isn’t an option, many security teams turn to agents. Agents run inside each running cloud virtual machine and report findings. Tenable users might use the same Nessus agent they use on-prem, with vulnerability data flowing into the Tenable.io Findings dashboard, shown below.
Users may alternatively take advantage of cloud-vendor agents, such as AWS’ SSM. These, too, must be installed on each target system and can be configured to provide telemetry to Tenable.io. This approach is used in Tenable’s Frictionless Assessment capability.
“The cloud service providers have their own agents for gathering information that they then use in their cloud-native tooling,” Bragg said.
This is a valid approach for larger virtual machines on which security teams allow agents, but not OS credentials. Unlike the network scanning scenario described above, no separate scanner node needs to be deployed, reducing complexity.
Agent scanning use cases:
- Larger public cloud virtual machines for which OS-level credentials are not provided to the security team, but the owner will allow an agent to be installed
- Public cloud virtual machines for which firewall and security rules prevent a scanner from reaching the scan targets via all ports and protocols
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
- Preserves the least-privilege principle, at the network level, for accessing scan targets
Disadvantages:
- Agents are required and must be managed
- System overhead
- Agents require connectivity to an agent manager, usually outbound TCP:443
- Not ideal for ephemeral workloads
- Targets must be running and available
Agentless scanning in public clouds
Today, the evolution of cloud security has led to what’s known as agentless assessment. As the name suggests, the approach uses no network scanners and no agents – third-party or cloud-vendor-provided. Instead, it uses the cloud vendors’ public APIs to gather information about virtual machines’ software bill of materials, then performs an assessment based on the information gathered.
This is a truly cloud-native approach and, unlike agent-based scans, can automatically provide visibility into all the cloud virtual machines and their flaws. Tenable Cloud Security– previously known as Tenable.cs – with Agentless Assessment does this by scanning snapshots of each virtual machine. A single, organization-wide read-only account in AWS or Azure is all that’s necessary.
Unlike the agent approach, virtual machines scanned this way don’t need to be big enough to provide resources for the agent. Running virtual machines are never scanned, just their snapshots. No OS-level credentials or port accessibility are needed either, so this approach scales well and significantly reduces the operational overhead associated with establishing a vulnerability management program in the public cloud.
The vulnerability findings, shown below, were collected and analyzed using this agentless approach.
![Agentless scanning in the public cloud]()
Agentless assessment use cases:
- Public-cloud virtual machines for which OS-level credentials are not provided to the security team and the owner will not allow an agent to be installed; snapshots are available or can be taken
- Ephemeral public-cloud virtual machines
Advantages:
- Cloud-native and API-driven
- No scanners or agents to deploy and manage
- Easy to scale
- No credentials needed
- Works with virtual machines of all sizes
- No impact on virtual machines
- Saves money because scanner virtual machines are not needed
- Access is granted via a cloud-native identity
- Can be used on stopped virtual machines as long as there are available snapshots
Learn more about Agents vs. Agentless and Tenable Cloud Security by watching this Cloud Security Coffee Break episode, and sign up to join the biweekly webinar.
