Most cloud intrusions start with a valid credential, not a misconfiguration, so a tool that only scans configuration will not see the attacker who signs in with a stolen access key and starts enumerating your accounts. Cloud detection and response (CDR) products watch the cloud control plane, identity activity and workload runtime for that behaviour, then help you investigate and contain it. This vendor-neutral buyer's guide explains how to evaluate CDR tools on the telemetry they collect, the detections they ship, the response actions they can take safely and the clouds and services they actually cover. It is written for SOC leads, cloud security engineers and evaluation panels. If you are buying CDR as one module of a broader platform, read the CNAPP Buyer's Guide for the posture side; this page goes deeper on detection and response only.
Key takeaways
- Telemetry decides everything: confirm which control plane, data access, identity, network and runtime sources the product reads, and which ones you must switch on and pay for first.
- Identity is the main signal: the best detections follow a principal (user, role, service account, access key or workload identity) across services and clouds, not single API calls.
- Agentless and sensor-based detection answer different questions: audit logs show what was done to the cloud; runtime sensors show what happened inside a workload or container.
- Response must be scoped and reversible: disabling a key or quarantining an instance in production needs approvals, an audit trail and a tested undo.
- Test with emulated behaviour in your own accounts, mapped to ATT&CK cloud techniques, and measure time to alert and alert quality, not rule counts.
Define requirements
- Cloud estate: providers, number of accounts, subscriptions and projects, organisation structure, regions in use, Kubernetes clusters (managed and self-managed), serverless and the SaaS identity provider that federates into them.
- Log baseline: what is already collected and where. Several high-value sources are off by default: in the major providers' own documentation, object-level storage data events are not logged by default and are charged separately, and data access audit logs are disabled by default for most services. Self-managed Kubernetes API server auditing records nothing until you supply an audit policy. Budget for enabling them; a CDR tool cannot detect what is not logged. See the Kubernetes Audit Log Detection Guide.
- Operating model: who triages alerts (internal SOC, MDR or both), which SIEM and SOAR receive them, and who is allowed to take containment actions in production accounts out of hours. See the MDR Buyer's Guide.
- Native services: which of each provider's native threat detection services you already run, and whether the CDR tool must ingest, correlate or replace their findings.
- Scenarios: list the five to ten incidents you most need to catch, such as a leaked long-lived key, consent or role abuse, cryptomining, storage exfiltration, a compromised CI/CD role, container escape and logging being disabled.
- Constraints: data residency for logs, read-only versus write permissions acceptable for the tool, and retention needed for investigations.
Capability areas
| Area | What to look for | ATT&CK examples it should catch |
|---|---|---|
| Control plane detection | Analysis of management audit logs across every provider and region, near real time, with organisation-wide onboarding | T1580 Cloud Infrastructure Discovery, T1651 Cloud Administration Command, T1578.002 Create Cloud Instance |
| Identity threat detection | Baselines per principal, federation and role chaining followed to the original human or workload, new credentials and roles flagged, impossible use of keys | T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles, T1548.005 Temporary Elevated Cloud Access |
| Data plane detection | Use of storage, database and secrets access logs where enabled; unusual volume or new external principals | T1530 Data from Cloud Storage, T1537 Transfer Data to Cloud Account, T1555.006 Cloud Secrets Management Stores |
| Workload and container runtime | Sensor or eBPF-based process, file and network telemetry on hosts, containers and nodes; Kubernetes audit analysis | T1610 Deploy Container, T1611 Escape to Host, T1552.005 Cloud Instance Metadata API, T1496 Resource Hijacking |
| Defence impairment | Alerts when logging, detectors or alerting rules are disabled, deleted or redirected | T1685.002 Disable or Modify Cloud Log, T1666 Modify Cloud Resource Hierarchy |
| Correlation and context | Joins alerts with posture findings, asset criticality and attack paths; one incident per attack rather than one alert per event | Multi-stage chains across the techniques above |
| Investigation | Principal and resource timelines across clouds, session reconstruction, raw event access, forensic snapshot capture | Supports scoping after any technique |
| Response actions | Disable or rotate keys, revoke sessions, detach policies, quarantine instances or pods, block network paths, with approval steps and rollback | Containment of the scenarios above |
All technique IDs above are from ATT&CK v20. The full set is on the ATT&CK cloud matrix; use the providers' native rule and log details in the Cloud Detection Engineering Guide.
Evaluation criteria
| Criterion | Illustrative weight | Good evidence |
|---|---|---|
| Detection quality on your scenarios | 25% | Emulation results in your accounts: alerts raised, time to alert, context included, false positives per week |
| Telemetry and cloud coverage | 20% | Per provider and service matrix of log sources read, latency, and which need enabling; Kubernetes and serverless coverage |
| Identity attribution | 15% | Demonstrated tracing of an assumed role or federated session back to the originating identity and source |
| Response safety | 15% | Action list, required permissions, approval workflow, audit log, rollback for each action |
| Investigation and integration | 10% | Timelines, raw event access, export to SIEM in a documented schema, SOAR and ticketing integration |
| Security of the product | 10% | Connector permissions, use of federated or short-lived credentials, separation of read and write roles, vendor access controls |
| Commercials | 5% | Pricing unit (workloads, accounts, events or log volume), cost of enabling required logs, runtime sensor licensing |
Weights are illustrative. A single-cloud organisation that already runs the provider's native detection service and a capable SIEM may need correlation, identity attribution and response more than new detections. A multi-cloud estate with large Kubernetes use should weight coverage and runtime higher. In framework terms CDR supports NIST CSF 2.0 DE.CM-09 (runtime environments monitored), DE.AE-02 (adverse events analysed) and RS.MI-01 (incidents contained), and NIST SP 800-53 SI-4 system monitoring, AU-6 audit review and IR-4 incident handling.
Questions to ask vendors
- For each of our providers, which log sources do you read, which must we enable first, and what does enabling them cost us in provider charges?
- What is the typical delay from a cloud API call to your alert, and what is the slowest source?
- Show how you attribute an action taken by an assumed role or federated session to the human, workload or CI/CD pipeline behind it.
- Which detections need a runtime sensor and which work from logs only? What does the sensor run as, and how is it updated?
- List every response action, the permission each needs in our accounts, and how each is approved, logged and reversed.
- How do you detect someone disabling logging or your own connector, and what happens to coverage when they do?
- How do we tune or suppress a noisy detection, and is the change versioned and audited?
- Which identities do you use to connect to our accounts, are they federated or long-lived keys, and how do we revoke them?
- Can we export raw events, detections and incidents to our SIEM, and keep them if we leave?
Red flags
- Detection claims expressed as rule counts or "coverage of the ATT&CK matrix" with no emulation evidence on your accounts.
- A product described as CDR that only re-labels posture findings or forwards native provider alerts without correlation.
- Connectors that require long-lived access keys with broad write permissions for read-only detection.
- Automated response enabled by default in production, or actions with no rollback.
- No answer on which log sources must be enabled, so detection gaps only appear after purchase.
- Kubernetes "coverage" that is image scanning only, with no audit or runtime telemetry.
Proof of concept
- Choose two or three representative accounts or subscriptions, including one production-like environment and one Kubernetes cluster. Agree scenarios and success criteria in writing.
- Onboard with least-privilege read-only connectors first, using federated or short-lived credentials where offered. Record the permissions requested.
- Enable any missing log sources the vendor needs, in the test scope only, and record the provider cost.
- Run a defensive emulation plan in the test accounts with an issued test key and role: discovery calls from an unusual location (T1580), creation of a new access key for another principal (T1098.001), unusual compute creation, a storage read burst (T1530) and an attempt to stop logging (T1685.002). Use an agreed open-source emulation framework or scripted, approved API calls.
- Measure for each step: alert raised or not, time to alert, attribution to the test identity, and context provided.
- Trigger one response action with approval, such as disabling the test key, then roll it back and confirm both appear in the audit log.
- Run normal operations for two weeks and count false positives and the tuning effort needed.
- Export one week of detections and raw events to your SIEM and check the schema.
Revoke all proof of concept connectors and test credentials at the end. The CDR tool will hold some of the most privileged non-human identities in your cloud; see the Cloud Incident Response Guide for the response process it plugs into.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for cloud and identity security, including detection of misused cloud credentials, service accounts and workload identities. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: CNAPP Buyer's Guide · Cloud Detection Engineering Guide · Cloud Incident Response Guide · CIEM Buyers Guide · CNAPP RFP Template