Let’s explore the technologies on which each viewpoint is based. Why do professionals with so much in common land on opposite sides of this debate? What are the priorities and concerns that drive these opposing preferences, and are they really different?

The agreement

First, let’s get one thing out of the way: What’s NOT up for debate is the importance of identifying security vulnerabilities in IT infrastructure. Even security engineers who don’t yet have a scanning solution in place know that their organization is at risk. Cybercrime is on the rise:

• The number of ransomware attacks doubled in frequency from 2020 to 2021 (Verizon), and reports so far indicate that they’re doubling again in 2022.
• A recent study found that cybercriminals can penetrate 93% of company networks (betanews.com).

Also rising is attackers’ exploitation of CVEs and configuration gaps. Gartner predicts that, through 2023, 99% of cloud security breaches will rely on known vulnerabilities and misconfigurations.

Vulnerability scanning isn’t optional. If you’re not doing it, you’re just not doing it yet.

Vulnerability scanning methods

At its foundation, the agent-based versus agentless debate is about access and timing: How and when does the scanner access the system it’s scanning? Agent-based scanning relies on software that runs in real time on the actual machine it’s scanning, whereas agentless scanning does not.

Agent-based vulnerability scanning

Scanning agents are relatively simple. The agent is software that you install on the system you want to assess. That agent executes on the system, reading configuration files, checking ports and protocols, and collecting live data for alerts and reports—all on the scan target.

This approach has compelling advantages, and also enough disadvantages to inspire agentless scanning.  

Agentless vulnerability scanning

There are different approaches to agentless scanning, each with its pros and cons. What they all have in common is that they don't run on your scan target. There are three common types of agentless vulnerability scanners:

Remote access vulnerability scanning executes outside the target system. It collects real–time information by connecting to the scan target through an operating system shell.

Cloud shell vulnerability scanning also runs in real time, outside the target system. What’s different is how it connects. This type of tool gains access through a cloud shell, a command-line environment specifically for managing cloud infrastructure. Every cloud solution has its own shell, such as AWS CloudShell or Azure Cloud Shell.

Image snapshot scanning assesses a copy of the target system rather than the system itself. It never interacts with the scan target.

‍

The disagreement

Why are there so many different approaches to assessing infrastructure vulnerabilities? Executing an agent directly on the scan target is such a simple approach that it seems like a no-brainer. There are so many advantages, including:

• All information gathered is on the current state of your actual system.
• There’s no remote login required, which means no new end point, no remote connection management, and no lag or connectivity issues.
• The scanner can access all the necessary system elements with few security limitations.
• There are no snapshots required, which saves time and cost.

Agents are powerful and fast. They give you the up-to-the-minute truth. So why doesn't everyone use them?

The challenges of agent-based vulnerability assessment

Some people don’t like installing an agent on their running virtual machines. You might not be comfortable with the minimal control you have over the agent. You’ve carefully configured each machine to do its specific job and you don’t want an agent taking up its resources. After all, some agents are resource hogs. It’s reasonable to worry about what happens at peak demand while some agent is performing a deep scan of your operating system. This could mean a slow or unresponsive website, a failed business transaction, or any type of operation slow-down.

Let’s consider scale as well. To assess the vulnerability of all the virtual machines in your infrastructure, you must install the agent on each machine. You have to sink time into installing, maintaining, and updating all those agents. Also, the sum of resources they consume has a cost. If an agent hogs processing on one machine, think about its impact on 100, 1000, or 10,000.

Now imagine the agent has a memory leak. It’s certainly been known to happen. After suffering performance issues, you identify a memory problem on the virtual machine and reveal that the vulnerability scanning agent is the leak source. To mitigate the problem, now you frequently have to stop the agent and restart it. That’s enough of a chore on one system but, again, let’s think about this scenario at scale.

Sometimes you don’t have the option of installing agents on infrastructure assets. Many businesses rely on a third party for their IT infrastructure needs. That third party might not allow agents on their systems—in fact, installing one could void the business contract.

Remote vulnerability scanning

If you’re not allowed to install agents or you see agents as software that endangers your running system, you might prefer a remote method of assessing your system’s vulnerability to cybercrime. For many assets, such as servers and virtual machines, this means remotely accessing an operating system shell (such as SSH or WinRM) to perform assessments. A program that exists outside of the system commands the shell to retrieve the information it needs.

Remote scanning addresses many concerns that operations professionals have about agent-based scanning. There’s no software on the scan target and no opportunity for the business loss that a bloaty agent can cause.

To remotely scan, the outside program needs a user account and an open port into the system. Of course, these are new security end points—means by which an attacker can penetrate the system. So in the process of identifying vulnerabilities, you’re actually creating new opportunities for security gaps! SSH is highly secure, but there are still problems that can occur with the user account, authentication, internet exposure, and so on. Many security professionals just aren’t comfortable with an open invitation to an operating system.

Cloud shell vulnerability scanning

Most cloud solutions offer shells that allow you to interact with their systems as if you’re directly on those systems. These cloud shells are similar to remote shells, but they don’t require you to open anything remotely. There’s no need for a separate user account because cloud shells use existing system management accounts.

Cloud shells are easy. You can instance-connect to update, manage, and configure all of your cloud resources. In a way, vulnerability assessment using a cloud shell is like the best of agent-based and remote scanning. There’s no agent taking up resources on the actual target system, but the scan has nearly all the access that such an agent would have. There’s no risky connection with new protocols; the cloud shell is a natural part of the system.

However, there is still opportunity for error with cloud shell vulnerability scanning. Although there isn’t the internet exposure risk and authentication risk of remote scanning, there is still risk through the user; every user is an entry point into the system.

Snapshot vulnerability scanning and side scanning

If you’re entirely opposed to the risks introduced by any access to a running system, you might prefer snapshot vulnerability scanning. With this approach, you assess a copy of the target instead of the target itself. The investigation doesn’t interfere at all with the scan target’s operation.

Snapshot scanning creates a full copy of the target’s entire hard drive and scans that copy. It explores all the files, accounts, tools, and configurations on the hard drive. You learn what packages are installed and what software vulnerabilities exist.

The limitation of snapshot vulnerability scanning is that the system copy isn’t live. You assess the system at rest. You can’t see live behaviors that put the machine at risk, such as opening certain ports.

Side scanning addresses that limitation. You don’t just take a snapshot of the target, you actually start the operating system on that image. You can see what systems run, what ports open, what processes run, what the kernel modules are, and other information that you’d have trouble accessing on a system at rest.

Is side scanning a perfect representation of everything happening on the target machine? No, but it’s very, very close—close enough for many teams, and far closer than a non-running snapshot scan.

Some proponents of snapshot scanning insist that it’s possible to learn all you need to know from an at-rest copy. But you would have to manually piece together the startup routine of the system, something beyond realistic expectations.

What troubles opponents of snapshot and side scanning is the time factor. Because it takes time to copy (and with side scanning, start up) the images, these scans don’t assess the current state of the target systems. This might sound like a nit pick, but with the speed at which infrastructure can change and grow today, it’s actually a reasonable concern for many organizations.

What’s right for you?

So which approach is the winner? Well this is why the debate is never settled: The real question is which approach is right for you. Your organization’s particular needs and priorities determine the best solution.

For example, suppose that, for your financial corporation, security is your top priority. You might prefer agent-based vulnerability scanning because it doesn’t introduce new risk of security breaches.  

As another example, if you maintain the infrastructure for a high-traffic e-commerce company, performance and reliability might be greater priorities for you. In that situation, every millisecond or wait time means lost customers and income. Agentless vulnerability assessments might better suit your needs.

Mondoo does both

Mondoo’s full-stack security platform supports both agent-based and agentless vulnerability scanning.

Mondoo’s agent eases some of the worries that come with agent-based scanning:

• We built it in a highly performant language, Go.
• It’s a single binary; you’re not installing any mystery files on your system.
• It’s lightweight in execution.

If you prefer not to use an agent, you can implement Mondoo over a remote connection via SSH,WinRM, or EC2 Instance Connect and SSM. You can run a volume scan on an EBS snapshot or container image—either running or at rest.

‍