The principle of least privilege (PoLP) is a cornerstone of IT security. With IT environments becoming increasingly distributed, PoLP and zero trust are now more important than ever — and with the rise in supply chain attacks, it is important to ensure that these principles extend to your security solutions as well.

But agent-based security solutions require full permissions over the machine they’re installed on. That means the same cloud security solutions you depend on are increasing your organization’s risk exposure and potentially opening up the back door to supply chain attacks. With it being Cybersecurity Awareness Month — under the theme “Do your part. #BeCyberSmart.” — there’s no better time to demand more from your security vendors.

What is the Principle of Least Privilege (PoLP)?

The PoLP has been a core security best practice for many years and states that you should only give identities permissions and access to the resources required to do their job and nothing more.

Zero trust takes this a step further and says you should never trust any user or service implicitly. Once a user’s identity is proven, they gain access to only the specific resource they need at that time.

Practicing these principles is critical in the age of distributed IT to protect against increasingly common supply chain attacks. We have all seen how supply chain attacks can have devastating consequences: SolarWinds and CodeCov showed the world how one breached service can expose tens of thousands of organizations.

Security agent: Guardian or foe?

Security vendors with agent-based solutions choose the easy path and build their agents to only support ‘administrative permissions’ installation. Customers don’t have a choice: these agents don’t work without administrative permissions.

But you don’t have to take my word for it. If you look at the installation guide for almost any agent, you’ll see that it runs as a privileged service with the ability to do virtually anything on the installed environment. This practice goes directly against the principle of least privilege.

By their nature, security tools require wide access, but that doesn’t mean they require unlimited access. Consider the following scenarios:

• A security tool that scans a host for vulnerabilities or malware doesn’t need the same permissions as the host.
• A security tool protecting a server with access to privileged data stores doesn’t also need access to those data stores.
• An agent running on a server that’s exposed to the Internet doesn’t also need to communicate with the Internet.

Ideally, security agents should not inherit the permissions of the protected asset, but run with the minimal permissions required to perform their task — both from a privilege and networking point of view.

Even if you trust the security vendor, being overly permissive can lead to catastrophic events. The vendor may be hacked as a means to get to your environment or (much more likely) the vendor’s solution may incorporate an open source tool that later turns out to be malicious and is running in your entire environment.

An example of a supply chain attack made possible by agents

Let’s look at how your security agent’s unbridled access can wreak havoc in your cloud environment by opening you up to a supply chain attack. Imagine that a security agent uses a particular library to parse JSON, PDF, and other file types. Despite good internal security practices, the library contains a Remote Code Execution (RCE) vulnerability.

An attacker can create files to exploit this vulnerability. The files can have payloads that install a malicious tool, communicate with a Command & Control (CnC) server, or encrypt the data on the host and send a message to demand a ransom. This will not only trigger in a targeted attack but also in cases of attackers spreading these infecting files widely.

A security agent that utilizes the vulnerable library is a prime target for attackers. The payload will run with full permissions — with the ability to encrypt files, to communicate with a CnC server, and to even move laterally through your cloud environment.

So if agents can potentially expose you to a supply chain attack, how can you safely secure your cloud environment? The answer: deploy an agentless cloud security solution.

Orca’s Agentless SideScanning™ adheres to the principle of least privilege

As an agentless cloud native application protection platform (CNAPP), the Orca Security Platform offers numerous benefits, including fast deployment, full visibility, contextual insight and more. In addition, Orca’s platform fully adheres to the PoLP, limiting privileges to the absolute minimum. Instead of agents, Orca uses its proprietary SideScanning™ technology to scan cloud workloads out of band. And unlike agents, SideScanning doesn’t inherit the permissions of the workloads it scans. SideScanning can, for example, scan a cloud environment that’s running a banking system without permission to access the customer data.

If the above mentioned hypothetical RCE vulnerability is exploited in the Orca platform, the impact will be far more limited than for agent-based security solutions, for the following important reasons:

• No Internet connectivity: There is no malicious code running on an agent that could interact with a CnC because Orca does not use agents. The Orca SideScanner runs without Internet communication enabled.
• Read-only access: Orca’s SideScanning doesn’t have ‘write’ access to data and only accesses a read-only snapshot. Any ransom activity will have zero impact on the real data.
• Dedicated, ephemeral instances: Because SideScanning™ technology runs on dedicated instances, its exposure is significantly reduced. These instances are ephemeral with very limited network access, so they can only access the scanned data and send digest scan results to a specific and dedicated data store. They’re also not reused between scans or assets, further reducing the attack surface.

In addition to adherence to PoLP, Orca’s SideScanning provides many more benefits, including complete visibility and coverage without installing a single agent: Deploy the platform once and all of your cloud assets are covered — even idle, paused, and stopped workloads, orphaned systems, and devices/OS that can’t support agents.

It’s time to change the way you do security

The PoLP remains a best practice because it effectively reduces the scope of an attack surface. Security vendors of agent-based solutions do not adhere to PoLP since they build their agents to inherit the permissions of their hosts. This means that the security controls you rely on for protection are actually increasing your risk for supply chain attacks. It’s time for a new approach. It’s time for a security solution that gives you complete visibility without increasing your risk exposure. It’s time for Orca. Connect your first cloud account in minutes. Learn more.

Orca specializes in AWS Cloud Security, Google Cloud Platform Security, and Microsoft Azure Cloud Security.