Cloud Detection and Response (CDR): The Missing Layer in Cloud Security

CDR, SIEM, and CSPM (Cloud Security Posture Management) address different phases of the cloud security lifecycle, with genuine gaps between them.

CSPM detects misconfigurations before they are exploited: S3 buckets with public access, security groups with overly permissive ingress rules, IAM policies with wildcard permissions. CSPM operates on the static configuration state of cloud resources. It does not detect active attacker behavior because it does not monitor runtime events.

Traditional SIEM ingests cloud audit logs but applies generic correlation rules that lack cloud-native context. A rule that fires on 'failed authentication' has no way to distinguish a legitimate user who mistyped their MFA code from an attacker attempting credential stuffing against the cloud console. A rule that fires on 'new IAM user created' cannot determine whether the timing, region, and permissions of the new user represent normal administrative activity or an attacker establishing persistence.

CDR adds three capabilities that close this gap. Cloud-native behavioral baselining learns the normal patterns of API calls in your specific cloud environment: which identities call which APIs, from which IP addresses, at which times, for which resource types. Deviations from these baselines surface as anomalies regardless of whether they match a known-bad signature. Cloud attack technique detection provides coverage for the specific tactics used in cloud intrusions: T1580 (cloud infrastructure discovery), T1578 (modify cloud compute infrastructure), T1537 (transfer data to cloud account), and dozens more ATT&CK cloud techniques with detection logic that understands cloud API semantics. Cross-service lateral movement detection correlates activity across multiple cloud services to identify attack chains that span IAM, compute, storage, and managed services in sequences that individually look benign but together indicate an attack in progress.

CDR platforms ingest cloud-native telemetry from multiple layers: control plane audit logs, data plane activity logs, and runtime security signals from cloud workloads.

Control plane audit logs are the primary CDR data source. AWS CloudTrail records all API calls to AWS services, including who called which API, from which IP address, with which parameters, and what the result was. Azure Activity Logs provide equivalent coverage for the Azure control plane. GCP Cloud Audit Logs cover administrative, data access, system event, and policy-denied operations. These logs contain the signal for IAM abuse, resource manipulation, and persistence operations.

Data plane logs add visibility into what happens after cloud resources are accessed. AWS S3 Server Access Logs and CloudTrail data events capture individual object reads and writes. VPC Flow Logs capture network traffic metadata between cloud resources. CloudFront access logs capture CDN request patterns. Database query logs capture data access patterns at the application layer. Data plane logging is frequently incomplete in cloud environments because it is not enabled by default and generates high volumes and costs.

Runtime security for cloud workloads (EC2 instances, containers, Lambda functions) is the third data layer. eBPF-based runtime agents (Falco, AWS GuardDuty Runtime Monitoring, Wiz Runtime) capture system call activity from cloud workloads, detecting process executions, file operations, and network connections at the OS level. This layer covers the attack surface that control plane logs cannot see: what happens inside a compromised cloud instance after the attacker has gained code execution.

Effective CDR requires coverage across all three layers. Control plane-only CDR misses attacks that operate entirely within cloud workloads after initial access. Runtime-only CDR misses cloud control plane abuse that never touches a workload. Full-layer coverage is the architectural goal.

The CDR market is young and consolidating rapidly through acquisition. Several distinct platform categories have emerged.

Native cloud provider security services provide foundational CDR capabilities at low cost. AWS GuardDuty is the most mature native CDR service, analyzing CloudTrail, VPC Flow Logs, and DNS query logs to detect threat patterns specific to AWS environments. GuardDuty Malware Protection and Runtime Monitoring extend coverage to EC2 and container workloads. Microsoft Defender for Cloud provides equivalent coverage for Azure and multi-cloud environments. GCP Security Command Center covers Google Cloud. Native services have the advantage of deep integration with provider APIs and no data egress costs, but limited cross-cloud correlation for organizations with multi-cloud deployments.

Cloud-native CDR platforms including Lacework, Orca Security, and Wiz provide cloud-agnostic CDR with multi-cloud visibility. Lacework's Polygraph Data Platform applies unsupervised machine learning to cloud telemetry to detect anomalous behavior without signature-based rules. Orca Security uses agentless workload scanning combined with CloudTrail analysis. Wiz's Security Graph correlates configuration data with runtime telemetry to identify attack paths that static CSPM and runtime-only CDR each miss independently.

Extended detection and response (XDR) platforms including CrowdStrike Falcon Cloud Security and SentinelOne Singularity Cloud extend their endpoint security platforms into cloud-native detection. The advantage is unified investigation across endpoint, identity, and cloud telemetry in a single console. The consideration is that cloud depth may be shallower than purpose-built CDR platforms for organizations with complex multi-cloud environments.

For most enterprises, the architecture is native cloud provider CDR services as the baseline (AWS GuardDuty, Microsoft Defender for Cloud) with a commercial CDR or CNAPP platform for multi-cloud correlation, advanced analytics, and unified security operations.

CDR as a standalone tool produces cloud-specific alerts. CDR integrated into the SOC workflow produces investigated incidents with full context across cloud, endpoint, and identity telemetry.

The integration path has two components. SIEM integration routes CDR alerts into the central SIEM alongside alerts from EDR, network security, and identity tools. CDR platforms provide SIEM connectors for Splunk, Microsoft Sentinel, Google Chronicle, and major SIEM platforms. Routing CDR alerts through the SIEM enables cross-source correlation: a CDR alert about suspicious IAM activity correlated with an ITDR alert about the same user account and an EDR alert about the endpoint they were logged into produces a much higher-confidence incident than any individual alert alone.

SOAR integration automates the response actions that CDR incidents require. Cloud-specific response playbooks should cover: IAM key rotation and deactivation for compromised credentials; isolation of compromised compute instances through security group modification; S3 bucket policy lockdown for suspected data exfiltration; snapshot deletion for attacker-created persistence snapshots; and cross-account access revocation for assumed role compromises. These response actions require cloud API access that SOAR platforms need to be pre-authorized to take.

Cloud detection coverage mapping against ATT&CK for Cloud and ATT&CK for Containers identifies detection gaps. The ATT&CK cloud matrix covers Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, and Exfiltration for AWS, Azure, GCP, and container environments. Mapping your CDR detections against this matrix identifies which cloud attack techniques you can detect and which require new detection logic or data source additions.

Cloud-Native Application Protection Platform (CNAPP) is the Gartner-defined category that converges CSPM, cloud workload protection (CWPP), and CDR into a unified platform. Understanding where CDR fits within CNAPP clarifies vendor claims and platform selection.

CSPM within CNAPP handles configuration assessment: finding misconfigurations before they are exploited. CWPP handles workload protection: vulnerability scanning for container images, OS packages, and application dependencies; runtime security for containerized and serverless workloads. CDR handles active threat detection: behavioral analytics for cloud control plane and workload runtime activity.

Leading CNAPP platforms including Wiz, Orca Security, Prisma Cloud (Palo Alto Networks), Lacework, and Aqua Security converge these capabilities with varying depth across each pillar. Wiz's strength is in CSPM depth and security graph correlation. Lacework's strength is in CDR behavioral analytics. Aqua's strength is in container and Kubernetes runtime security. No single platform leads across all pillars.

For organizations evaluating CDR in 2026, the practical question is whether to buy CDR as a CNAPP component or as a standalone capability. Organizations already running a CNAPP platform should evaluate whether their current platform's CDR capabilities meet their detection requirements before adding a separate CDR tool. Organizations without a CNAPP platform can use CDR as an entry point into the category and expand to CSPM and CWPP coverage over time.