How to Choose a Cloud Detection and Response Platform for a Multi-Cloud SOC

Cloud detection and response (CDR) is the discipline of spotting and stopping attacker activity inside cloud control planes, identities and workloads, at the speed cloud attacks actually move.

This guide explains what a CDR capability has to cover, which telemetry it depends on, how to evaluate platforms without relying on marketing claims, and how a neutral set of well-known options compares.

It closes with detection queries and a response runbook your SOC can adapt this week.

Why cloud detection and response became its own discipline

Traditional detection grew up around endpoints and networks. In a cloud tenant, the most damaging actions happen through API calls: creating an access key, attaching an administrator policy, sharing a snapshot with an outside account, or turning off logging.

None of these touch an endpoint agent, and many look identical to legitimate automation.

The threat data supports the shift. CrowdStrike’s 2025 Threat Hunting Report, as reported by Infosecurity Magazine (2025), counted a 136% increase in cloud intrusions in the first half of 2025 compared with all of 2024.

The Verizon 2025 Data Breach Investigations Report found credential abuse was the initial access vector in 22% of breaches, and third-party involvement doubled to 30%.

In the cloud, stolen credentials and trusted third-party access are exactly the paths a control-plane attacker uses.

Speed matters too. GBHackers covered an AI-assisted intrusion that compromised an AWS environment in 72 hours, moving from one stolen access key to persistence and data theft.

A weekly posture scan will not catch that sequence. A detection pipeline that alerts within minutes might.

What a CDR capability actually covers

CDR is less a product category than a set of capabilities. Many vendors deliver it as the runtime half of a cloud-native application protection platform (CNAPP), while cloud providers ship native threat detection services.

Whatever the packaging, a working capability spans four layers.

Control plane

This layer covers management API activity from AWS CloudTrail, Azure Activity Logs and Google Cloud Audit Logs.

It is where you detect privilege escalation, persistence through new keys or roles, and defense evasion such as disabling trails.

Identity

Cloud identity providers (Entra ID, AWS IAM Identity Center, Google Workspace, Okta) produce sign-in and token events.

Attacks here include password spraying, MFA fatigue, device-code phishing and OAuth consent abuse.

Recent reporting on abuse of OAuth device codes and Entra ID enrollment shows how attackers gain persistent SaaS access without ever touching a password prompt.

Workload runtime

Virtual machines, containers, Kubernetes nodes and serverless functions need process, file and network visibility. This usually comes from an eBPF sensor or agent, because snapshot-based scanning sees state rather than live behavior.

Data and network

Storage access logs (S3 server access and data events, Azure Storage logs), VPC flow logs and DNS logs show exfiltration and command-and-control. They are expensive at volume, so most teams enable them selectively for sensitive resources.

Mapping cloud attacks to MITRE ATT&CK

The MITRE ATT&CK cloud matrix is the most practical way to define coverage. Rather than asking a vendor “do you detect cloud threats,” ask which of the techniques below they detect, from which log source, and with what default severity.

Tactic	Technique (ATT&CK ID)	Typical telemetry
Initial access	Valid Accounts: Cloud Accounts (T1078.004)	Sign-in logs, ConsoleLogin, AssumeRole events
Credential access	Unsecured Credentials: Cloud Instance Metadata API (T1552.005)	Runtime sensor, GuardDuty-style credential exfiltration findings
Persistence	Account Manipulation: Additional Cloud Credentials (T1098.001)	CreateAccessKey, service principal secret additions
Privilege escalation	Account Manipulation: Additional Cloud Roles (T1098.003)	AttachUserPolicy, role assignment writes
Defense evasion	Impair Defenses: Disable or Modify Cloud Logs (T1562.008)	StopLogging, DeleteTrail, diagnostic setting deletes
Discovery	Cloud Infrastructure Discovery (T1580)	Bursts of Describe/List calls from a new principal
Collection	Data from Cloud Storage (T1530)	S3 data events, storage access logs
Exfiltration	Transfer Data to Cloud Account (T1537)	Snapshot or AMI sharing, cross-account copy
Impact	Resource Hijacking (T1496)	Unexpected compute launches, AI model invocation spikes

Resource hijacking has broadened beyond cryptomining. The LLMjacking campaigns against Amazon Bedrock showed attackers using stolen keys to run expensive AI model invocations at the victim’s cost, which means Bedrock, Azure OpenAI and Vertex AI invocation logs now belong in your CDR scope.

Evaluation criteria for cloud detection and response platforms

Use criteria you can test in a proof of concept. The list below is vendor-neutral and maps to NIST CSF 2.0 Detect (DE) and Respond (RS) functions, described in the NIST Cybersecurity Framework 2.0.

1. Telemetry breadth. Which clouds, identity providers and SaaS apps are ingested natively? Are Kubernetes audit logs and AI service logs included?
2. Detection latency. Measure time from API call to alert. CloudTrail delivery to S3 can lag by minutes, so ask whether the platform consumes EventBridge or equivalent streaming sources.
3. Context and correlation. Does an alert on a new access key show the identity’s permissions, the resources it can reach, and known exposures on those resources? Correlating runtime events with posture data is the main reason teams buy a platform over writing rules in a SIEM.
4. Runtime depth. Agent or eBPF sensor coverage for Linux, Windows, containers and serverless, plus what happens when you deploy agentless only.
5. Response actions. Can it disable a key, revoke sessions, quarantine an instance or isolate a pod, and are those actions gated by approval?
6. Detection-as-code. Can you write, version and test custom rules, and export them to your SIEM? Look for Sigma support or a documented query language.
7. Noise and tuning. Ask for false-positive rates from a comparable customer and test with your own automation accounts, which generate most of the noise.
8. Cost model. Pricing by workload, by event volume or by cloud spend changes the bill dramatically at scale. Get a written quote against your real inventory.

Independent testing helps, with caveats. The 2025 ATT&CK Evaluations included cloud infrastructure for the first time, in a scenario inspired by Scattered Spider, and also tested detection of reconnaissance.

SecurityWeek (2025) reported eleven participating vendors and that Microsoft, Palo Alto Networks and SentinelOne withdrew. Treat the results as evidence about specific techniques, not as a ranking.

Comparing well-known CDR options

The table describes publicly documented approaches as of the review date. It is not a ranking, it contains no pricing, and features change quickly, so confirm every capability with the vendor during evaluation.

Option	Delivery model	Runtime visibility	Notes for evaluators
AWS GuardDuty, Microsoft Defender for Cloud, Google Security Command Center	Native cloud provider services	Optional runtime monitoring components	Strong depth in their own cloud, low deployment effort; multi-cloud correlation usually needs a SIEM or another layer
CrowdStrike Falcon Cloud Security	CNAPP with sensor and agentless components	Falcon sensor on hosts and containers	Fits teams already running Falcon on endpoints; ties cloud and endpoint telemetry together
Palo Alto Networks Cortex Cloud	CNAPP built on the Cortex platform, announced in 2025 as the successor direction for Prisma Cloud	Agent-based runtime	Positioned for SOCs using Cortex XSIAM or XDR
Wiz (Wiz Defend)	Agentless-first CNAPP with optional sensor; part of Google since the deal closed in March 2026	eBPF sensor (optional)	Graph-based context linking identities, exposures and runtime events; vendor states multi-cloud support continues
Orca Security	Agentless-first CNAPP with optional sensor	Sensor (optional)	Correlates side-scanned workload state with control-plane events
Sysdig Secure	CNAPP built around the open source Falco runtime engine	eBPF-based agent	Strong container and Kubernetes focus; Falco rules are open and inspectable

Most mature teams end up with a layered design: native provider detections for depth and low cost, a CNAPP or CDR platform for cross-cloud context and runtime, and the SIEM as the system of record.

Agentless-first vendors such as Orca Security and Wiz reduce deployment friction, but their live-process visibility depends on the optional sensor, so test both modes in the proof of concept.

Practitioner example: detection queries you can deploy

The following queries run against AWS CloudTrail data in Amazon Athena or a similar SQL-on-logs engine. Adjust table and column names to your schema, and exclude known automation roles before alerting.

Defense evasion: logging disabled (T1562.008)

SELECT eventtime, useridentity.arn, sourceipaddress, eventname, awsregion
FROM cloudtrail_logs
WHERE eventsource IN (‘cloudtrail.amazonaws.com’, ‘guardduty.amazonaws.com’, ‘config.amazonaws.com’)
  AND eventname IN (‘StopLogging’, ‘DeleteTrail’, ‘UpdateTrail’,
                    ‘DeleteDetector’, ‘StopConfigurationRecorder’)
  AND eventtime > to_iso8601(current_timestamp – interval ‘1’ day)
ORDER BY eventtime DESC;

Persistence: access key created for another user (T1098.001)

WITH keys AS (
  SELECT eventtime, useridentity.arn AS actor,
        json_extract_scalar(requestparameters, ‘$.userName’) AS target_user,
        sourceipaddress, useragent
  FROM cloudtrail_logs
  WHERE eventname IN (‘CreateAccessKey’)
    AND eventtime > to_iso8601(current_timestamp – interval ‘1’ day)
)
SELECT * FROM keys
WHERE target_user IS NOT NULL
  AND element_at(split(actor, ‘/’), -1) <> target_user;

Long-lived keys are the fuel for both rules. GBHackers reported 768 leaked AWS keys that were still active with administrator access, and infostealers fueling cloud credential theft keep that supply growing.

Pair these detections with a hunt for access keys older than 90 days, and prefer short-lived role credentials wherever possible.

Exfiltration: snapshot shared outside the organization (T1537)

Alert on ModifySnapshotAttribute or ModifyImageAttribute calls whose request parameters add a createVolumePermission or launchPermission for an account ID not on your allowlist.

This one rule catches a common, quiet exfiltration path that bypasses network controls entirely.

Practitioner example: a cloud incident response runbook

The following illustrative scenario assumes an alert fires for a CreateAccessKey call on an administrator user from an unfamiliar IP address. The steps follow the structure of NIST SP 800-61 Rev. 3, which aligns incident response with CSF 2.0.

1. Scope the principal. Pull every API call made by the source identity and the new key in the last 72 hours, across all regions. Attackers often work in regions you do not use.
2. Contain without destroying evidence. Deactivate (do not delete) the new key and the original credential, revoke active sessions with a deny policy conditioned on token issue time, and snapshot any instance the identity touched.
3. Hunt for persistence. Look for new IAM users, roles with external trust policies, Lambda functions, modified identity provider settings and changes to SCPs or permission boundaries.
4. Check impact. Review S3 data events, snapshot sharing, compute launches in unusual regions and AI service invocation volumes.
5. Recover and harden. Rotate affected secrets, remove persistence, and add a preventive control (for example an SCP that blocks CreateAccessKey for human users) so the same path is closed.
6. Feed detections back. Turn each confirmed attacker action into a tested rule and record the ATT&CK technique it covers.

Running a fair proof of concept

Pick two or three candidates and give each the same accounts, the same test window and the same attack script.

Open source emulation tools such as Stratus Red Team and Atomic Red Team include cloud techniques that map to ATT&CK, which makes results comparable.

Record time to alert, alert quality, false positives from your own automation and the effort needed to write one custom rule.

Involve the people who will live with the tool. A platform that scores well on detection but forces analysts to pivot across three consoles will slow response more than a small gap in coverage.

Finally, check data residency, log retention and whether the vendor’s read role in your accounts follows least privilege.

Key takeaways

• Cloud detection and response must cover control plane, identity, workload runtime and data access; missing any layer leaves a common attack path dark.
• Define coverage with the MITRE ATT&CK cloud matrix and ask vendors which techniques they detect, from which log source.
• Credential abuse drives a large share of breaches, so key creation, role changes and log tampering are the first detections to deploy.
• Native provider services, CNAPP-based CDR and the SIEM work best as layers rather than substitutes.
• Run a scripted proof of concept with identical attacks for every candidate and measure latency, noise and analyst effort.

FAQ

What is cloud detection and response (CDR)?

CDR is the set of tools and processes that detect and respond to attacks inside cloud environments by analyzing control-plane logs, identity events, workload runtime activity and data access. It focuses on live attacker behavior rather than static misconfigurations.

What is the difference between CDR and CSPM?

CSPM finds risky configurations such as public buckets or overly broad roles. CDR detects active threats, such as someone using a stolen key to disable logging. Most CNAPP platforms combine both so alerts include posture context.

Is CDR the same as XDR?

No. XDR started from endpoint telemetry and expanded outward, while CDR starts from cloud APIs, identities and workloads. Some vendors offer both, and many SOCs feed cloud detections into an XDR or SIEM for correlation.

Do I need agents for cloud detection and response?

Control-plane and identity detection work without agents because they rely on provider logs. Live process and container behavior usually needs an agent or eBPF sensor, so most teams deploy sensors on critical workloads and stay agentless elsewhere.

Which logs should I enable first for cloud threat detection?

Start with organization-wide CloudTrail (or Azure Activity and Entra ID sign-in logs, or Google Cloud Audit Logs), then the native threat detection service, then data events for sensitive storage, and finally flow and DNS logs where budget allows.