What Is Cloud Detection and Response (CDR)?

A CSPM dashboard tells you an S3 bucket is public and an IAM role is over-permissioned. It does not tell you that, twenty minutes ago, an attacker assumed that role from a residential IP in another country, called the instance metadata API on a running EC2 host, and is now enumerating every bucket the role can reach. Posture tools see the open door. They do not see who walked through it.

Cloud Detection and Response (CDR) is the discipline that watches the door in real time. It is runtime threat detection and response built for cloud workloads, cloud identities, and the cloud control plane, the layer where misconfigurations stop being theoretical and become an active intrusion. This guide covers what CDR is, why the cloud needed its own detection-and-response practice rather than reusing endpoint tooling, where its telemetry comes from, the lifecycle it runs through, the real attacker techniques it catches, and how it differs from CSPM, CWPP, EDR, and XDR. It is written for SOC analysts, threat hunters, and cloud security engineers who have to answer "is this account compromised right now?" rather than "is this configuration ideal?"

What is Cloud Detection and Response (CDR)?

Cloud Detection and Response is the practice of continuously monitoring a cloud environment for active threats and responding to them while the attack is in progress. It spans three planes that an attacker moves across: the workloads (virtual machines, containers, serverless functions), the identities (IAM users, roles, federated principals, service accounts), and the control plane (the provider API that creates, modifies, and destroys all of the above).

The "detection" half ingests telemetry from those planes and turns it into alerts: a role assumed from an anomalous location, a security tool disabled, a snapshot shared to an external account. The "response" half contains the threat: revoke a session, quarantine an instance, disable a key, isolate a workload, all through the same provider API the attacker is abusing. The two halves are one loop, not two products. Detection that no one can act on is a dashboard, and response with nothing driving it is a runbook nobody opens.

CDR is a runtime, threat-facing discipline. That is the line that separates it from the posture tools alongside it. A posture scanner asks whether the environment is configured safely. CDR asks whether something is happening in the environment right now that should not be. Both matter, and a mature cloud program runs both, but they answer different questions and live at different points in an attack.

Why the cloud needs its own detection and response

Endpoint detection and response was built for a world of long-lived machines with an agent installed and a user sitting at a keyboard. The cloud broke every one of those assumptions, and that is why CDR exists as a distinct practice rather than EDR with a cloud label.

Workloads are ephemeral. A container can live for ninety seconds. An autoscaling group spins instances up and tears them down on demand. By the time a traditional alert reaches a queue, the host that generated it may be gone, taking its disk and memory with it. Detection has to happen at runtime, and evidence has to be captured before the workload disappears, because there is often nothing left to image afterward.

The control plane is the new attack surface. In an on-premises breach, an attacker who wants to copy a database has to touch the database server. In the cloud, they can call the provider API and snapshot the volume, share it to an account they control, and never touch the workload at all. The most damaging cloud actions, copying data, creating backdoor users, disabling logging, are API calls, not host activity. An endpoint agent never sees them. The audit log of the control plane does.

Attacks are identity-centric. Cloud intrusions rarely start with malware. They start with a credential: a leaked access key, a phished session token, an over-permissioned role assumed from somewhere it should not be. MITRE ATT&CK lists Valid Accounts (T1078) as a primary cloud initial-access technique precisely because stolen credentials look like legitimate use. The attacker logs in. There is no exploit to catch, only behavior to recognize, which makes cloud detection an identity-monitoring problem first and a workload problem second.

Shared responsibility splits the evidence. The provider secures the infrastructure; the customer secures what they run on it and who can reach it. The provider will not detect that your role was abused or your bucket was exfiltrated; that is your side of the line. CDR is how the customer holds up their half: it consumes the telemetry the provider exposes (audit logs, flow logs, identity events) and turns it into detection and response the provider does not do for you.

CDR telemetry: where the signal comes from

CDR is only as good as the telemetry it correlates, and cloud telemetry is scattered across services that were never designed to be read together. Four sources carry most of the signal.

Control-plane audit logs. AWS CloudTrail, Azure Activity Log, and Google Cloud Audit Logs record every API call: who called it, from where, with which credential, and what they did. This is the spine of cloud detection. A backdoor IAM user, a shared snapshot, a disabled trail, a mass bucket enumeration all appear here as API events. If you read one telemetry source, read this one. The distinction between API-activity logging and metrics monitoring is itself a common point of confusion; the CloudTrail versus CloudWatch split is worth understanding before you build detections on top of either.

Runtime workload telemetry. Agents or eBPF sensors on instances and inside containers capture process execution, file changes, and network connections at the host. This is where you catch a cryptominer launched inside a container, a reverse shell on a compromised VM, or a process reading the instance metadata endpoint. eBPF is favored in cloud because it observes the kernel without a heavy agent, which suits short-lived workloads.

Identity and authentication events. Sign-ins, role assumptions, token issuance, MFA challenges, and federation events from the cloud IdP and IAM. This is the layer where credential abuse shows itself: impossible-travel logins, a role assumed by a principal that never used it before, a sudden spike in permission-probing API errors.

Network flow telemetry. VPC flow logs and equivalents record connections between workloads and to the internet. They surface lateral movement, command-and-control channels, and exfiltration paths that host telemetry alone can miss.

No single source is sufficient. A CloudTrail event saying a role was assumed is benign until you correlate it with the identity log showing the assumption came from an unrecognized IP and the flow log showing that session then reaching storage it never touched before. Correlation across sources is the work; the individual logs are just inputs.

The CDR lifecycle: detect, investigate, respond

CDR runs as a continuous loop with three stages. The value is in the loop closing fast, because cloud attacks move at API speed, an attacker can go from a stolen key to exfiltrated data in minutes, not days.

Detect. Telemetry from the four sources above streams in and is evaluated against detection logic: signatures for known-bad API calls, behavioral baselines for each identity and workload, and anomaly models for impossible travel or unusual data access. The output is an alert with enough context to be actionable, not a raw log line. Good detection here is tuned to cloud behavior, a developer assuming a role from a new laptop is normal; a service account suddenly enumerating IAM is not.

Investigate and correlate. A single alert is rarely the whole story. This stage stitches related events into one timeline: the leaked key, the role it assumed, the API calls that role made, the workloads it reached, the data it touched. Correlation across the control plane, identity, and workload telemetry is what turns five disconnected alerts into one intrusion narrative. This is also where most cloud SOC time goes, because the raw alert volume is high and the false-positive rate on naive cloud rules is brutal.

Respond and contain. Once an intrusion is confirmed, response acts through the cloud API to cut it off: revoke the active session and rotate the credential, quarantine the workload by tightening its security group, disable the compromised access key, snapshot a volatile instance for forensics before it scales away, and restore known-good configuration. The defining feature of cloud response is that the same control plane the attacker is abusing is also the lever the defender pulls, which is why much of it can be automated and why automation has to be governed carefully, an over-broad automated containment can take down production faster than the attacker would have.

The loop then feeds back: what you learned in the investigation tunes the next detection, and what you could not contain cleanly tunes the response playbook.

CDR vs CSPM vs EDR/XDR

The cloud security acronym soup is mostly about where a tool sits in time and scope. The cleanest way to separate them is to ask: does this tool prevent a bad state, or detect and stop an active threat? And does it watch endpoints, configurations, or the cloud itself?

Two distinctions matter most. First, CSPM is posture and prevention; CDR is runtime detection and response. CSPM tells you the IAM role is over-permissioned before anything happens. CDR tells you the role is being abused right now. They are complementary, not competing, CSPM shrinks the attack surface, CDR catches what gets through it. Gartner has since folded CSPM and CWPP together with CIEM into the broader CNAPP category, but the posture-versus-runtime line still holds inside it. The full CWPP vs CSPM breakdown covers how those posture tools split the workload-versus-configuration job between them.

Second, CDR is to the cloud what EDR is to the endpoint. EDR watches a laptop's processes and files; CDR watches the control plane, the identities, and the workloads. XDR sits above both, correlating endpoint, network, identity, and cloud signal into one view, and CDR is increasingly the cloud feed into an XDR or SOC pipeline rather than a wholly separate console. Trying to cover cloud with endpoint EDR alone leaves the control plane, the most damaging cloud attack surface, completely unwatched, because EDR has no visibility into API calls that never touch a host.

Real cloud TTPs that CDR catches

CDR earns its place by catching attacker techniques that posture scanning and endpoint tooling structurally cannot see. These map to the MITRE ATT&CK cloud matrix.

Stolen credentials and valid-account abuse (T1078). An attacker uses a leaked access key or phished session to log in as a legitimate principal. There is no malware. CDR catches it as behavior: the credential is used from a new location, at an odd hour, to call APIs that identity has never called.

Instance metadata credential theft (T1552.005). A compromised workload reads the cloud instance metadata API to harvest the IAM role credentials attached to the instance, then uses them to pivot to other services. Runtime workload telemetry catches the process touching the metadata endpoint; control-plane logs catch the harvested role being used somewhere new. Enforcing IMDSv2 reduces this, but CDR is what tells you it is being attempted.

Impairing defenses (T1562). A common early move is to disable or delete logging, stopping a CloudTrail trail or deleting a log group, to blind the defender. The act of disabling logging is itself a high-fidelity CloudTrail event. A trail going silent or a "StopLogging" call is one of the clearest signals a cloud SOC can build a detection on.

Data theft from cloud storage (T1530) and resource hijacking. Mass enumeration and download from object storage, or spinning up expensive compute for cryptomining, both show up as anomalous API and billing patterns long before a posture scan runs again. Correlating the storage-access spike with the identity that drove it is exactly the cross-source work the investigation stage exists for.

The thread is that none of these involve an exploit in the classic sense. They are legitimate API calls made by an illegitimate actor, which is why they are invisible to tools that only check configuration or only watch endpoints, and visible to a discipline built to read cloud behavior in real time.

How CDR fits into a SOC

CDR is not a replacement SOC; it is the cloud-facing detection-and-response capability inside one. In practice it slots in three ways.

It is a telemetry feed and detection layer that normalizes cloud logs into alerts the existing SOC can triage, often forwarding into a SIEM or the cloud-native equivalent so cloud alerts sit in the same queue as endpoint and network alerts. A cloud SIEM is frequently the aggregation point where CDR detections land alongside everything else, giving analysts one place to correlate.

It is an investigation surface that gives analysts the cloud-specific context endpoint tools lack: which role, which account, which region, which API, which session. An analyst triaging a cloud alert needs that context inline or the investigation stalls.

And it is a response capability wired into the provider API, increasingly through SOAR-style automation so that high-confidence detections (a key disabled, a session revoked) can be contained in seconds without waiting for a human, while lower-confidence ones escalate to an analyst. The split between automated and manual containment is a tuning decision, not a default, and getting it wrong in either direction either slows response or breaks production.

For the analyst, the payoff is that cloud stops being a blind spot. The same loop that EDR provides on the endpoint, see the behavior, understand it, contain it, now exists for the cloud workloads, identities, and control plane that an endpoint agent was never built to watch.

The bottom line

Cloud Detection and Response is runtime threat detection and response built for the cloud's three attack planes: workloads, identities, and the control plane. It exists as its own discipline because the cloud broke the assumptions endpoint tooling was built on, workloads are ephemeral, the control plane is an API an attacker can abuse without ever touching a host, and intrusions start with stolen credentials rather than malware. The work is correlating control-plane logs, identity events, runtime workload telemetry, and network flow into one intrusion narrative, then containing it through the same API the attacker is using.

The cleanest way to place CDR among its neighbors is by time and scope. CSPM and CWPP are posture and prevention, they shrink the attack surface before anything happens. EDR and XDR are runtime detection and response for endpoints and across domains. CDR is runtime detection and response for the cloud itself, catching the valid-account abuse, metadata credential theft, logging tampering, and data exfiltration that those tools structurally cannot see. For a SOC, it turns the cloud from a blind spot into one more queue an analyst can actually work.