Do we need an ‘agent or agentless’ tooling stack to secure cloud workloads

• Traditional security tools [that aren’t built to be cloud-native] don’t provide adequate context to perform an investigation and security response.
• Organisations need a unified model of agentless plus agent-based to address the challenges of finding, focusing, and fixing container security issues.

Lifting and shifting workloads to the cloud without tooling changes is a losing proposition and results in reduced visibility, lack of control plane context and limited workload context that weakens the security posture of the organisation, an industry expert said.

“Visibility is critical across your cloud and container platforms, but traditional security tools [those that aren’t built to be cloud-native] don’t provide adequate context to perform an investigation and security response,” Jake Williams, Executive Director of Cyber Threat Intelligence – SCYTHE – and Senior Instructor at SANS Institute, said.

When it comes to container security and visibility in the cloud, he said that there are two primary models – agent-based and agentless.

“Many organisations spend an inordinate amount of time trying to decide which model is superior,” he said.

Sure, agentless is the new hotness, he said, but what are you giving up and do you need agents or agentless?

Despite some strengths and weaknesses of each approach, he said that the outcomes are superior when using a combination of agent-based and agentless cloud-native security tooling.

“The two technologies aren’t mutually exclusive. Organisations that have moved to the cloud without deploying cloud-native monitoring tools should examine these scenarios and ask whether they would have similar outcomes to the observations in the first scenario.

Inevitable focal point

“Those wanting to avoid those outcomes should strongly consider deploying a cloud-native tooling stack using a combination of agentless and agent-based technologies to maximise their ability to rapidly find, focus, and fix security (and operations) issues in their cloud environments and the spectrum of workload types that exist within modern architecture,” Williams said.

Prioritisation isn’t the end of the journey; however, he said that they (security experts) need to remediate discovered issues. Just like a good doctor, “we need to treat the causes rather than just address the symptoms. Remediation must happen at the source.”

When investigating visibility solutions for cloud platforms, and workload monitoring more specifically, he said the question of agent-based vs. agentless becomes an “inevitable focal point”.

Given the speed with which DevOps teams change deployment parameters, he said that testing to find every edge case with an agent simply isn’t realistic.

Although agentless technologies like to claim they can do everything without an agent, he added.

Limited visibility

While an agent-based technology stack has direct visibility into the runtime of the system it runs on, comparable agentless solutions are limited to polling or taking trigger-based actions.

Polling models suffer from limited visibility between polling intervals, not to mention the difficulty of choosing an appropriate polling interval.

Trigger-based actions are limited to the types of triggers (events) the monitored platform can send (and the timeliness with which it does so).

Agentless also implies that a target cloud service or workload an organisation wants to monitor and control is fully API enabled. This API enablement isn’t necessarily a given, depending on the underlying technology stack or the cloud provider’s offering.

Given these limitations, should organisations transition from agent-based to agentless solutions, even if it means preventing potential availability issues caused by agents?

“In most cases, we would argue that they definitely should not. Because agentless solutions rely on existing features of the monitoring target to provide telemetry, they often miss important telemetry that agent-based solutions catch,” Williams said.

Moreover, he said the additional data collected by agent-based solutions often prove pivotal in establishing context.

“An additional point worth mentioning is the extreme rarity of availability issues caused by agent-based solutions in today’s environments. Most anecdotes in this area can be traced to immature capabilities, improper deployments, or other extremely self-inflicted circumstances.”

However, he said that agentless solutions are required to capture data that agent-based solutions cannot.

Organisational stress

If the organisation has workloads configured in AWS, agent-based solutions can (and should) capture telemetry inside containers, but what about understanding the AWS control plane?

Because the control plane doesn’t offer the capability to run an agent, “we should think of this as an ideal use case for agentless technology.”

“We’ve witnessed multiple organisations stress over changes for inordinate periods, extending the length of a threat actor’s access to their environments. This is understandable. After all, although nobody wants to deal with a threat actor in the environment, causing a self-inflicted outage in a critical service is often a résumé-updating event (especially during an incident when tensions are already high),” Williams said.

By considering circumstances where agent-based and agentless technology each excel and don’t, he said that it becomes clear that organisations need a unified model of agentless plus agent-based to address the challenges of finding, focusing, and fixing container security issues.

Related posts:

• The need for predictive tools to combat complex security threats is greater than ever
• Oxeye discovers smuggling vulnerability in GoLang-based applications
• Why taking charge of cloud security is a number one priority for Middle East businesses?