Is It An Agent? Sicura's Answer.

The Number One Question We Get Asked

Whenever we explain Sicura to a potential customer, partner, or just someone interested in what we’re doing, we always get this question: “Is it an agent?” It’s such a predictable question that it makes us smile, but the answer isn’t simple - and neither are the reasons people are asking it. Since it’s so frequent, we decided to explore the question of agent versus agentless, what it’s really asking, and why customers should shift their thinking around the topic of agents. 

So, what is an agent?

An agent is just something - anything - that can perform an operation. A human doing an operation is an actor; a program or piece of software doing that same action is an agent. Any software that can make a change to your system is technically an agent. Which is why the question of “is it an agent” is so silly - of course it is an agent! Otherwise what would be the point of the software? 

However, when folk ask whether Sicura or any software is an agent, they’re often actually asking whether it’s a daemon or not. A daemon is an agent with a persistent connection to a system. Daemonized services are those that maintain a connection and have the ability to make changes on a system. When people ask, is it an agent, they’re usually asking about daemonized services. A familiar example would be a virus scanner that can repeatedly access and scan your system - it needs that persistent connection to run and share the data. 

There are valid reasons to be skeptical about adding new agents and/or daemons to your infrastructure. Here are the most common ones that drive customers to seek agentless options: 

• Resourcing
  The persistent connection can create problems in that it requires resourcing. If you’re looking at a very resource intensive system, and a daemon is constantly running and using additional resources, you have to measure if it’s worth it or not. A “no new agents” policy might be aimed at preserving resources for existing systems. 
• Traffic
  If the daemon is sending data from one system to another, that generates a lot of network traffic. Sending that data costs money if you’re on AWS, Google Cloud, Azure, or another cloud provider. Limiting agents is seen as a way to limit that increased throughput and the resulting costs. 
• Monitoring Burden
  If a daemon is constantly running and making changes, someone at your organization needs to monitor it to know what those changes are. Any change comes with risk, both operational and security. The “burden of always knowing” can lead teams to resist adding anything new to their systems, even if new tools could help ease that burden. 
• Inventory Management
  Every piece of software requires tracking and management in the organization’s inventory and asset management program. Does the software have a license, and if so how many licenses do we have? What usage is already paid for and what could trigger additional costs? These questions must be answered, but often organizations don’t even have a handle on their existing internal inventory. 
• Attack Surface
  In addition to the monitoring burden on security teams, damoenized services increase an organization’s  exposure to attack because an attacker could gain access to the entire system via the external tool. Security teams need to know and understand the extent of access and damage possible if an agent was compromised. For example, the Solar Winds breaches were caused by hackers infiltrating external software with an agent connected to the victims’ systems. 

So when a potential customer asks, “is it an agent?” they’re likely not actually asking if Sicura is a piece of software with the ability to make a change. Rather they’re looking for a quick way to assess the burden that will be placed on their teams by using this tool. Organizations lacking in sufficient staff and resourcing will implement policies limiting or banning new agents outright.

So, is Sicura an agent? 

The short answer is: it depends. Sicura can operate in both “agent” and “agentless” modes depending on the preferences, infrastructure, and use case of the customer.

If you’re using the Sicura Console to scan your system against compliance policies and make changes to get it to a compliant state, then yes, Sicura is an agent. In this use case Sicura runs as a daemon, installed on your system and connected to the Console web app. The daemon is what allows you to trigger a scan from the Console, perform remediation tasks from the Console, and manage multiple (up to thousands) of servers from a single point dashboard. Sicura as an agent drives efficiency and centralized capability. 

However, if you’re in a sophisticated IT organization with existing pipelines to manage your workflow, then no, Sicura is running agentless. Sicura tells your pipeline what remediation task to perform via APIs, and Sicura itself is not actually running the task or making any changes to your system. This use case allows users to interact with Sicura’s capabilities in their own existing tooling. For a brand new system, your pipeline could query Sicura for a complete policy and deploy that Greenfield server exactly in that image. For modern organizations using ephemeral architecture, it’s not worth adding the Sicura agent to a container that’s only going to exist for a few seconds. This use case of Sicura is more flexible, lightweight, and integrated into the tools an organization is already using. 

Agents used to be cool

Back in 2009 when we started development of Sicura inside the intelligence community, agents were in vogue. The ability to make multiple changes on multiple systems from a centralized location was novel and exciting, with the value proposition being ease and centralization. Sicura was originally built as an agent-based solution because it began as a framework on top of Puppet, itself an agent-based language and platform. Using Sicura to “do compliance with Puppet” required the agents running on each server to connect to the centralized daemon to learn what to do and what Puppet code to enforce. This was in line with best practices and bleeding edge technology at the time.

Since we started building Sicura over a decade ago, technology has evolved, as it tends to do. Agents are no longer in vogue because better ways of managing servers have been developed. The transition from on-prem to cloud is a major achievement or goal of every Fortune 500 company. Ephemeral architecture is what the cool kids are doing today - servers and containers are spun up for mere seconds to complete a single task, then destroyed - to limit costs and improve efficiency. Now you can build infrastructure in seconds or hours, not days - let alone waiting a month for a patching cycle. 

Sicura has shifted towards an API-based, task-focused product to align with these broader shifts. By focusing our efforts on refining the capability to translate policies to code, customize them to user and organizational specifications, and run remediation tasks via APIs, Sicura fits into contemporary security and IT practices without leaving legacy systems behind. 

So why do people keep asking if Sicura is an agent? 

We understand why folks keep asking about agents. However, the resistance to agents is the wrong solution to a different, real problem. Organizations that lack a good way of managing their infrastructure and inventory resist adding new agents, but what they really should be doing is cleaning up and modernizing that infrastructure so it’s not so unwieldy. If you’re at capacity and you truly cannot handle another agent because of the costs or monitoring burden, you almost certainly have bigger issues you need to deal with. 

With a tool like Sicura, which saves IT and security teams time, makes organizations more efficient and compliant, and saves customers millions each year - adding one additional agent will actually do more for limiting all those burdens than any internal agentless policy. 

If you’re interested in modernizing the management and security of your infrastructure - with or without another agent - get in touch.