Agent vs Agentless Security: Which One Is Better?

The move to the cloud has resulted in a shift in how we do security. Things move fast in the cloud, and you may not have the access you’re used to. The Shared Responsibility Model explains how this dynamic environment works. It describes what operational areas you need to cover and what your service provider covers. And yes, security is an operational concern.

Using this model, we can see what security controls might be applied to a service. For example, are you using an infrastructure as a service (IaaS) offer? You might be able to put controls in the network or deploy them to the operating system. Or are you sticking to software as a service (SaaS)? You’re going to have to rely on controls provided by the service itself.

This is the technical reality of security in the cloud. So why is there so much content out there debating agent vs. agentless deployments?

Agentless For The Win?

Those advocating for an agentless only (e.g., no code running on your virtual machines or containers) approach line up between two main points:

• Agentless is simple
• Agentless provides data for services where agents aren’t possible

These are good arguments for an agentless approach.

Data in agentless solutions is either pushed from the service or pulled by the solution. Push is ideal as it is usually faster, but can be less efficient in high volumes. Pull solutions can see a delay between data creation and collection, but can handle higher volumes well.

Whether you’re using the push or pull method, you’re getting data that is then analyzed by your solution. This connection is set up once with minimal permissions and then just works. That’s the simple part. That’s a big win for your security practice. The second point, providing data for services where agents aren’t possible, is also spot on. The Shared Responsibility Model tells us that this is the only solution with some service types.

The Anti-agent View

Part of the argument for agentless is about how bad agents are. “Agents are hard to deploy.” “Agents negatively impact system performance.” “Have you ever tried to get the operations team to agree to deploy an agent?!?”  These are all valid points to consider, but let’s look a little deeper.

Agents can be difficult to deploy. But there are ways to make it simpler. Automation and having a strong CI/CD pipeline are just a couple of examples.

Agents can impact performance. The more an agent does, the more resources it’ll consume. That’s a constant with any computation, it takes resources. The key is to find a balance that works for your solution.

Working across teams is hard. People-problems always are. Does that mean you should rule out an entire architecture because you would have to work together? No. Especially when you factor in what you can actually gain from agents.

The “agents are bad” argument just doesn’t add up — there are a lot of positive outcomes to consider.

How Agents Help

Agents deploy directly in your virtual machine, container, or even function. This gives them a level of visibility that isn’t possible from another location. Want to know all the processes running in a container? There needs to be some program running to provide that information. That’s called an agent.

Curious about what files are open within the operating system? You’ll need an agent to get that information out. Want to stop a process from executing? Figure out what user deleted a file? If any process has injected code into another? Push application and operating system logs for central analysis?

You guessed it, you need an agent.

If there is information running within a workload, code needs to be running on that workload to gain access. Even in situations where there are claims about getting this level of depth without an agent, there’s an agent. It’s just running on the side.

What About The Agent Downsides?

We know what we gain with an agent. What about those arguments against the approach? The good news is that most of those arguments have stayed from the use of old technology. There have been a lot of improvements in the past few years.

For resource consumption, an agent gathering data only consumes a small amount. The trade off you’re making is a small amount of processing and network bandwidth for greater visibility. Not only that, but these agents now run entirely in user space reducing the overall impact and risk.

For agents that take an active role in the workload (e.g., preventing processes from running, stop network traffic, etc.), the resource consumption and impact increases slightly as you would expect. They are burrowing deeper into the workload.

On the deployment front, things are better by leaps and bounds. Tools like Ansible, Chef, AWS Systems Manager, Google Cloud Workloads, and Azure Run Command all make it easy to deploy agents on existing workloads.

For new workloads, agents should be included as part of the core build in your CI/CD pipeline.

All of these approaches align with how other software is deployed to your workloads. Long gone are the days of agent-specific deployment methods.

As to the team collaboration issue, that’s a big part of a DevOps philosophy. Teams should discuss the pros and cons of each part of their workload. Then work to solve the problems at hand.

If everyone involved can’t see the advantage of a security agent, was the best tool selected for the job?

Vim vs. Emacs?

There are pros and cons to an agentless approach and to an agent approach. So which one is best?

Honestly? Neither. It’s a ridiculous premise.

Security is a data problem. As we’ve learned, some of the data is accessible only through an agentless approach. Some of the data is only accessible via an agent. Your security solution should have access to all of the relevant data. That means a combined agent and agentless approach.

Your security solution should help you make sure that what you’ve built works as you intend and only as you intend. The more data you have, the better you are able to ensure that things are working as planned. How to get the data is a technical question.When there is a choice between methods, choose the one that better aligns with your specific requirements.

If that’s agentless, agent-based, or something we haven’t thought of yet, go for it. The outcome is what matters.