Agents - a bad idea

I'm guilty of blog echo here. I'm echoing a post on taosecurity that echos a post on Matasano. Sorry. Sort of.

For a while now I've felt the obvious drawback of adding software to a production device - anything adds complexity, which undermines reliability and security. Whether that additional software adds enough in return is the question.

Matasano examines this credo in detail, with empirical evidence supporting the idea that you need to minimize agents. Agents are used for antivirus, desktop inventory and configuration management (especially for security functions like patch management, firewall and host-based IDS).

Read the Matasano post. Among other problems with agents:
1) Vendors are still in early-mid 1990's mode as far as responding to vulnerability reports. That is, they ignore them.

2) Agents are complex and invasive processes, creating a massive attack surface. This is not a theoretical problem; there's an extensive history of actual vulnerabilities in agent-based tools.

3) This inviting attack surface is present across an enterprise, typically. That is, there's a huge monoculture target waiting. The biodiversity analogy suffers from the same weakness all argument by analogy does, but it's still useful: where there's no genetic diversity, a population, if vulnerabile, is universally vulnerable to an infectious agent.

4) Further, most agents report to centralized servers, which themselves present inviting targets. Own that server, own the enterprise. Yikes.

So what's the alternative? Software vendors develop agents to control and collect data on otherwise unmanagable numbers of machines. There may not be built in mechanisms externally available to take care of this stuff. I think, for the most part, these mechanisms are present in modern OS's. Essentially, the agent and its problems are already provided, so don't add more. Also, I think the pull method, where an agent periodically checks in and requests updates and reports status, is more robust than the push method, where a central server issues directives. In both cases, owning the server is tantamount to control, but there are some beneficial corner cases for the pull method. In the pull method, you could still provide a malicious update on the server that the client's agent would pull down and act on in good faith. But that's a little trickier than the Stalinist, push method. Also, a pull method doesn't create a new, listening service that can be attacked without controlling the server.

I believe cfengine and puppet both follow this approach, but I haven't used either.

Of course, the element of authoritarian direct control is part of the appeal of these systems. So push will probably win over pull due to its superficial appeal.