LAST UPDATED August 2, 2021
I’m a big fan of the ThreatX agentless architecture. It simplifies many of aspects of deployment and side-steps a lot of the problems with agent-based architecture.
ThreatX regularly competes against agent-based solutions. In those head-to-head competitions, we often hear prospect perceptions about the problems with agent-based solutions and find them quite interesting. We’ve boiled that down to a few key problem areas:
1 – Support Across Heterogenous Infrastructure
All security agents naturally need to be tightly integrated with the host that they are going to protect. Just like an antivirus agent needs to be tightly coupled to the operating system on a laptop, an AppSec agent needs to be tightly coupled to the application. However, compared to the AppSec agent, the antivirus developers had it relatively easy. In general, they just needed to support (i.e. not break) the many versions of Windows used in the enterprise.
The modern application environment is far more diverse. There are a variety of potential web and application servers that may need to be supported. Does the organization use Apache HTTP, NGINX, Microsoft, Lighttpd or one of dozens of other options? What version of each is in use? The agent may support some and not others. Some features may be available on some and not others. Reliability can also vary. It is important to remember that security developers only have a finite amount of time for development and testing, and some platforms will be supported better than others. This can mean customers can end up in the uncomfortable position of having their production deployments acting as the de facto extended QA for their security vendor.
2 – Architectural Lock-in
Spotty support across heterogenous platforms can handcuff developers. Modern application stacks are constantly evolving, and development teams naturally want to use the right combination of components for the unique demands of their applications. What makes sense today may not be ideal next year. An agent-based approach can take away the dev team’s ability to evolve and adapt. Instead of using the best technology available, dev teams can easily find themselves stuck waiting for new technology to become mainstream enough that it warrants support from their security vendor.
This concept can likewise apply to overall application architecture itself. Based on the architecture, the organization may want to deploy agents at the load balancers, on the server containers, or other locations. As architectures evolve, teams will need to revisit how the security agent supports various options. In either case, development teams can find that their decisions are being dictated by what the AppSec agent can support.
3 – Constant Updates
An agent-based security approach dictates that teams add yet another component that needs to be regularly updated. This is often something that is not obvious during the evaluation phase and only becomes evident during an actual deployment. AppSec agents tend to need very regular updates as they adapt to changes in the security landscape. As a result, it is not uncommon for an agent to be updated even multiple times within a month.
This creates a new component that needs to be constantly tested, evaluated and deployed across the organization. Teams will need to consider if the update requires the server to be rebooted and how to properly stage and balance the updates in order to avoid impacting production users. The regular drumbeat of these updates can quickly lead to update fatigue that create additional burdens on all phases of DevOps.
4 – Potential to Break Things
Tradeoffs have always existed between agents and performance and reliability of the host. AppSec agents are no different. The tight integration between the agent and web/app server or load balancer means that a bug in the agent can easily bring down the application instance itself. Even in the best cases, an agent will naturally introduce an additional component that will consume resources.
This can be of particular concern when it comes to DDoS and especially Layer 7 attacks. These attacks are designed to consume application resources to the point that it impairs the performance or availability of an application. An agent-based approach means that the ability for an organization to defend itself is often directly dependent on the same resources that are under attack.
5 – Complexity Mushrooms at Scale
Most importantly, all of the problems discussed above are amplified at scale. One of the fundamental challenges of AppSec today is that organizations simply have far more applications and instances than ever before. Most organizations struggle to protect even 10% of their applications and agent-based approaches contribute to the dismal deployment track records of our competition. Over and over we hear–even years into a deployment–that only a handful of applications are deployed in blocking mode. When we ask why, it almost always comes down to the difficulty of deploying yet another security agent, at scale.
Once again, this is an area where the proof-of-concept is often far different from the reality of production. It can be fairly straightforward to manage agents on two or three applications, but when the organization needs to protect 2,000 to 3,000 the process will quickly become unmanageable. The organization is back to having to pick and choose which few applications are worthy of security and which of the masses must remain exposed.
These are just some of the issues that teams need to consider as they evaluate their security options. Ideally, your chosen security solution must be able to scale out to all your applications regardless of the components they are built on. Security should integrate and work with the DevOps process without introducing additional testing and rollout burdens. And, as a friend in the business recently said to me, “please, for the love of God, don’t make me deploy yet another end-point agent.”
ThreatX provides a new approach that supports both AppSec and DevOps teams without locking either into architectural decisions and without giving up their autonomy and flexibility.
To learn more, reach out to us and schedule a demo. Let’s talk about the benefits of going agentless.
