Why Agent-based Security Fails in Rapid Response Scenarios

Published:

May 24, 2022

Reading time:

8 Minutes

Cloud platform and security teams are well-aware of the challenges in swiftly responding to new vulnerabilities and zero-day threats. There are countless examples just in the past year of major threats that impacted cloud environments and applications and required rapid responses, including:

  • Log4Shell: Multiple critical CVEs and attack vectors were identified in the popular Log4j framework, requiring teams to identify all vulnerable applications and apply patches to several updated versions.
  • Linux DirtyPipe: A critical Linux privilege escalation vulnerability was published and named “Dirty Pipe”. This vulnerability affected every major Linux distribution from Linux kernel version 5.8 and above, allowing local unprivileged users to gain root privileges.
  • Spring4Shell: A critical remote code execution (RCE) vulnerability was identified in the Java Spring Core framework, requiring identification and patching all vulnerable applications.

With the continued adoption of open source software, security teams need to ensure they can quickly and efficiently identify vulnerable cloud assets and prioritize patching those assets that pose the greatest risk to the business.

Relying on agents impacts rapid response

Security teams are used to relying on agent-based security architectures or network scanners for discovering vulnerabilities and threats in on-premises environments. However, scanners and agents are not as easily deployed in cloud environments. Cloud assets can be very dynamic as they are spun up and torn down on demand, making them difficult to track, monitor, and manage. Due to the tremendous efforts required to deploy agents and scanners, traditional security solutions usually end up covering less than 50% of cloud assets.

As a result, cloud security teams cannot reliably answer basic questions such as:

  • How many of our cloud assets are vulnerable to this CVE?
  • Which assets are running the vulnerable version of the product or component?
  • Are any of these vulnerable assets Internet facing?
  • Which of these vulnerable assets could expose sensitive data or endanger critical business assets?

If your organization is not able to quickly answer these questions due to a lack of visibility into your cloud assets, this is literally a disaster waiting to happen. 

Time spent deploying agents on assets

When responding to emergency situations such as the Log4j vulnerability, it is simply not acceptable to only have the ability to locate vulnerabilities on half of your assets and just cross your fingers and hope they don’t occur on the other 50%. 

In these situations, organizations might start frantically trying to deploy agents on all the resources that they missed. Even though silent installations can often be used to deploy multiple agents in one go, it will still be a considerable effort that will take multiple hours, depending on how large and diverse the environment is. Considering that many organizations have hundreds of assets that may be missing agents, incident response is not an ideal time to deploy agents. 

Knowing where to deploy agents when you don’t have any visibility

According to a survey by Netskope, a shocking 97% of cloud applications used in the enterprise are shadow IT; in other words, unmanaged by the organization’s IT or security teams and often freely adopted. Needless to say, these applications are highly likely not to have any agents installed. But worse than that, how can IT install agents on resources they do not know exist? 

Sure, you could look at your Cloud Provider account overview to see which assets are running, but with VMs and cloud-native microservices being created continuously, this is really not the most efficient use of your security team’s time.

Agents do not support all operating systems

Another factor that hinders 100% visibility into cloud apps when relying on agents is that they simply do not support all operating systems. Legacy applications that have not yet been updated can be running older versions of OSes that organizations do not want to upgrade yet. This means that these applications will not be covered by the agent-based cloud security application and a critical CVE may be missed entirely. 

A recent example of this is the ‘UN3524’ botnet found by Mandiant. Mandiant researchers said: “The threat actor evaded detection by operating from devices in the victim environment’s blind spots, including servers running uncommon versions of Linux and network appliances running opaque OSes. These devices and appliances were running versions of operating systems that were unsupported by agent-based security tools”.

When agent updates are required to detect a new CVE

Even if you think you are in pretty good shape because you have recently increased your agent coverage and installed agents on as many resources as possible, you may be in for a nasty surprise. To detect a new CVE, security vendors sometimes require organizations to update their agents. This is the kind of scenario security teams dread in an emergency situation. Now, before they can even start detecting the new critical CVE, they must first update the agents on all their systems, which will take hours. This scenario has been shown in various vendor documentation portals (in this instance, CPU overhead can also be a concern). And all the while, systems could be vulnerable to the new CVE.

The benefits of SideScanning™ and the Orca Platform

It is always important to have complete coverage and insight into all your cloud applications and workloads, but even more so in rapid response situations. When zero-day threats or critical CVEs are exposed, the ability to quickly gain a thorough understanding of which VMs, containers, and serverless functions need to be fixed, and in what order, is essential to effectively protect your organization in the shortest amount of time.

By leveraging Orca’s SideScanningTM technology, The Orca Cloud Security Platform can collect data directly from your cloud configuration and the workload’s runtime block storage out-of-band, without requiring a single agent. This means that Orca can be deployed in minutes and always covers 100% assets, including new assets as they are added, including VMs, containers, and serverless, as well as cloud infrastructure resources like storage buckets, VPCs, and KMS keys. Orca even discovers and monitors idle, paused, and stopped workloads, orphaned systems, and devices that can’t support agents.

To demonstrate how Orca’s agentless platform is invaluable in rapid response scenarios, we will use the recent Log4j vulnerability as an example. In the week of Log4Shell, Orca Security had many organizations literally onboarding thousands of cloud accounts with hundreds of thousands of instances to check whether they had any assets vulnerable to Log4Shell. These organizations could never have gained this visibility if they needed to install an agent for each workload.

Peter Gerdenitsch, CISO of Raiffeisen Bank International AG and Orca customer, said: “Thanks to Orca, within hours we were able to quickly identify Log4j in our cloud estate. We were extremely impressed with the competency of Orca’s support staff who gave us great guidance and proactively updated us on new Log4j developments, proving that Orca is much more than a product but is also a trusted partner that has our back in difficult situations.”

From the News Widget to Locate Risks with a Single Click

Not every CVE will be major news like Log4Shell. However, new critical CVEs, with, for instance RCE or DDoS risks, appear all the time. If they are severe enough, they will also get media attention. To help customers stay ahead of new critical CVEs and zero-day threats, Orca includes a news widget that lists all the latest CVEs appearing in the news in a feed on the home dashboard, and automatically checks if the CVE is found in your environment.

So if your CISO asks you: ”Are we safe from that new critical CVE I just read about?” You will be able to open the entry in the News Widget and show your CISO right there and then whether there are any vulnerable assets in your environment. And because Orca’s platform always covers 100% of your assets, you can be sure that there are no hidden assets that could still be vulnerable without you knowing.

Will you be ready for the next critical CVE?

Why wait for the ‘next Log4j’ to painfully highlight that your cloud security coverage is significantly lacking? Orca is providing a free, no obligation risk assessment and 30-day trial so you can see for yourself what 100% comprehensive visibility looks like. Let Orca check your entire cloud environment on AWS, Azure, and Google Cloud and uncover any vulnerabilities and risks that your current cloud security solution may have missed. Not ready to get hands-on yet? Watch our 10-minute demo or download the Orca Security Platform Overview to learn more.