ADR - The Future of Runtime
Application Detection Response is the hot off the press buzzword that's going to be the next big thing
While the average CISO may be content with the CrowdStrike “industry standard;” boots on the ground cloud security engineers know just how lacking modern Endpoint Detection & Response (EDR) offerings are in containerized environments. Challenges in EDR stem from their being rooted in Windows contexts, where the historical crown jewels were kept. The EDR transition to cloud workloads has been rocky, as major vendors have struggled to keep up with eBPF, Kube Audit, and Cloud log correlation possibilities, offering deeper insights across cloud workloads. Even as Linux agents have slowly matured, surfacing rich container and Kubernetes contexts have proven to be a continuing challenge for legacy EDR providers.
From EDR to CDR/KDR
To see why the evolution from EDR to Cloud Detection Response (CDR) was important, which UX makes more sense for investigating a container alert?
CrowdStrike:
If you want to operationalize detection and response inside container environments, it’s been clear for the last few years that you need to switch to a modern solution like: Rad, ARMO, Sweet, Upwind, or Sysdig.
I’ve written here with ARMO about Kubernetes Detection Response (KDR) being the heart of CDR, and why trying to do cloud detection without Kubernetes support is like trying to drive a car without an engine. Kubernetes is the heart of cloud architecture, and modern solutions need to have total coverage to stay relevant. Furthermore, because the Kubernetes ecosystem is rapidly evolving, it takes vendors with domain specific expertise to continue to keep up.
Despite having massive technological superiority over legacy EDR, this slice of tools struggles to differentiate to the market. Because CrowdStrike and SentinelOne do utilize eBPF and have container agents, only thorough testing reveals their shortcomings. They’re missing major correlation capabilities and detection rules across cloud relevant log sources.
Unfortunately, it can be hard for many CISOs to see why they need a modern CDR instead of just CrowdStrike. When you add to the confusion by every Cloud Native Application Protection Platform (CNAPP) including CDR as a checkbox, things get even more complicated. This is why I only consider something as a CDR if it supports Kubernetes agents - how can you say you’re doing cloud detection and response if you don’t support the primary orchestration used in the cloud?
From CDR to ADR
As soon as Miggo came out of stealth as an “Application Detection & Response (ADR)” provider, I knew this would be the future we were looking for with CDR. The language was quickly adopted by Oligo (edit: Correction, Oligo had it first!), and I think it will be only a matter of time before all of the CDR players switch to it in order to better differentiate their offering from the legacy players.
While CDR vendors are uniquely differentiated from legacy EDR, being able to see inside application functions is much more of a clear gap from existing players. Furthermore, the older Runtime Application Security Protection (RASP) space has very few players left because instrumentation has proven so challenging.
Despite Miggo and Oligo having radically different instrumentation methods, both differentiate by having visibility into function executions at runtime. This level of visibility differentiates them from the existing legacy providers with much more clarity than the CDR providers have used.
Professionals who have been around security long enough will recognize that ADR is really “just RASP” but I think this shift is more profound for two reasons (Oligo touches on some in their article as well):
The instrumentation is a lot simpler
The death nil of RASP has always been the difficulty in instrumentation, and the risk of troubleshooting if something goes wrong. Even though DataDog’s importing a library, or Contrast’s wrapping a start command, is theoretically simple, security users typically don’t have the expertise to roll these out themselves at scale. Encouraging security teams to do something so invasive was too much a loss of control for developers to feel confident with the exchange.
This is why I lean towards providers like Oligo that accomplish this visibility with an eBPF agent: security teams already have a well defined paradigm for deploying agents, and it’s easier to conceptualize a detection vs. response rule in an agent context.
Combining cloud, container, and application contexts give the holy grail of detection & response data
I view the goal of ADR as more profound than RASP anyways in its ability to correlate across Cloud, OS and App logs, although no one fully does this yet. I always use this simple, realistic attack to think through the visibility points of a modern detection and response platform.
I’ve liked CDR providers because they can detect steps 3-4 happening, and even stitch them together; however, they can only spot the remote shell once the process actually starts. Conversely, RASP can see steps 1-2, but not the rest of the chain. ADR providers differentiate by having access to all of the necessary data via a single instrumentation, even if the road ahead is a long one to build the full picture. I’ve typically seen advanced security teams work with developers to try and write custom application detections in their logs, but this approach never really scales.
In conclusion, I hope that ADR takes hold as the technology that clearly differentiates enough from legacy EDR providers to encourage practitioners to take another look. Right now, CDR vendors offer a more holistic opportunity to give visibility than EDR, and I hope teams will give them a chance in an evaluation. That said, it’s only a matter of time before ADR comes in as the complete solution.