When looking to secure Linux, you may be wondering: What is the main advantage of an agentless product like Sandfly over agent-based security solutions that exist?
The answer is simple:
It’s difficult for an agent-based product to secure Linux with the same wide coverage Sandfly can provide.
With security, if you don’t have wide coverage, then you aren’t secure. You need to fill all the gaps and not leave any place for hackers to hide. Sandfly leaves fewer gaps for hackers to hide because it works on just about any Linux host instantly with little chance of disruption vs. agent-based systems.
To be clear to those new to the game, an agent-based product requires a constantly running piece of code on an endpoint. An agentless product like Sandfly works by sending over swarms of investigative modules and then disappearing after they are done. Sandfly does not have a constant presence on the remote endpoints, hence agentless.
Let’s go over three reasons why agentless security can provide better coverage for Linux over agent-based solutions.
Reason 1: Linux Kernel Updates Break Agent-Based Security Products
Agent-based products can be effective. However, they are doing intensive operations at the kernel level to profile system calls and spot suspicious behavior. This can lead to problems on Linux that has frequent updates and distributions that are not 100% compatible with each other.
The rapid update open source model has worked for Linux in terms of adding features and patching security problems. But, it’s not very good if you have a product with deep hooks into the kernel that is shifting under you all the time in small ways. Various patches and upgrades can cause big problems for a security agent that is deeply reliant on everything being just right. How these updates may impact an agent-based product is always an unknown.
The above means that any product that is tying into the kernel to monitor for security problems is going to run into two frequent issues:
1) Will a kernel update break the security agent?
2) Will a security agent update break the kernel?
Both of these questions need to be addressed before an update and often you don’t have time to get a good answer. If a security product is causing you to not update due to compatibility questions, something has to give. In the end, many networks find it’s safer to simply not run a security agent than risk breaking critical systems that need to be kept updated and reliable at all costs. Nobody wants to be left holding the bag if things go wrong.
Sandfly’s agentless approach though does not run in the kernel. As a result, our product won’t break your system regardless of what updates or patches are applied. Our approach is very soft touch and ensures critical systems operate without any interruption while also being securely monitored for compromise.
Reason 2: Linux Permutations Limit Agent-Based Security Coverage
The second issue with agent-based solutions is that in trying to ensure compatibility with various Linux distributions and kernels, they must limit how many versions they can actually secure.
For instance, there are about six major distributions of Linux, and another 10+ minor distributions, and many more even smaller distributions. Plus, embedded versions of each, customizations, etc. Imagine testing against all those, and their previous versions, and their patches, and their separate security features. It multiplies quickly and you’re going to break something in that sequence somewhere.
This kind of development and testing is a tedious and complicated matter with an agent-based security product. If a vendor had to work to get their agents working on every version of Linux, plus test against the constant stream of updates, they’d be spending huge sums on R&D and QA on the problem. As a result, vendors simply must limit what versions of Linux they will cover, and what versions of the kernel they will work on as well. They simply have no other choice due to the nature of how it all works. That’s why agent-based security coverage for Linux is often so thin compared to other platforms like Windows. The development and testing issues across all Linux variants is a big problem.
Sandfly again though doesn’t care about any of this. As a demo we will spin up a couple dozen hosts with every major Linux distribution and point Sandfly at the fleet. Within seconds we have added the hosts and can provide immediate security coverage with no impacts. The permutations of Linux are simply not an issue with Sandfly’s agentless approach. The solution just works and we don’t have to worry about making customer’s systems unreliable by interfering with updates and varied kernel versions.
Reason 3: Agentless Security Works Where Agent-Based Can’t
The varied environment Linux provides is where an agentless approach like Sandfly really shines. Simply put, Sandfly can deploy faster and more widely than any agent-based security system around. An agentless approach supplies superior security over agent-based systems for one simple reason:
We’re on systems where agent-based systems can’t go.
Because we’re on the systems where agent-based products can’t work, it makes our coverage better. Wider coverage means better security because now you can monitor more of your network and not give attackers any place to easily hide.
Agentless Security Works Because It’s Always There
Agent-based security products do have their place. However, if they can’t run on a target host due to whatever reason then the security they provide is exactly zero. Coverage matters.
Sandfly ensures that all your Linux systems are always being monitored which means faster detection of serious problems on your network and better protection for your critical assets. Sandfly’s agentless security deploys quickly, doesn’t cause any system instability, doesn’t interfere with patches being applied, and can give you security visibility onto hosts where there was none before. Those are all winning features that help keep your network more secure.