Posture management tells you what could go wrong in your cloud environment. Cloud detection and response (CDR) tells you what is going wrong right now, and gives you a way to stop it. For years many organizations invested heavily in the first and relied on a traditional SOC, built for endpoints and networks, for the second. The threat data from 2025 and 2026 shows why that approach is running out of road.
This playbook explains what has changed in cloud attacks, what a modern CDR capability consists of, and how to build one step by step, from telemetry through automated containment and forensic readiness.
What Changed: The Speed and Shape of Cloud Attacks
Google Cloud’s H1 2026 Cloud Threat Horizons Report, covering incidents from the second half of 2025, contains two findings every cloud security leader should absorb. First, exploitation of third-party software vulnerabilities became the leading initial access vector, at 44.5 percent of incidents, overtaking weak or missing credentials at 27.2 percent for the first time since the report began in 2021. Second, the window between disclosure and exploitation has shrunk from weeks to days. Google’s threat intelligence group observed cryptocurrency miners deployed within roughly 48 hours of the React2Shell vulnerability being disclosed, and in one supply chain case a compromised npm package let an actor abuse OpenID Connect trust to reach full AWS administrator permissions in under 72 hours.
The same report notes that major ransomware groups were deleting logs, core dumps and backups in late 2025 to hinder investigation and recovery. In other words, attackers are faster, they increasingly start from application and supply chain weaknesses rather than just stolen passwords, and they actively try to destroy the evidence defenders need.
Sysdig made a similar argument in 2023 when it published its 5/5/5 benchmark for cloud detection and response: five seconds to detect, five minutes to correlate and triage, and five minutes to begin a response. Its rationale was its own research finding that attackers who find an exploitable cloud target can execute an attack in under ten minutes. Whether or not you adopt those exact targets, the principle holds: cloud response time is measured in minutes, and manual, ticket-driven workflows cannot meet it.
What a Modern CDR Capability Includes
CDR is not a single product. It is a combination of telemetry, detection logic, context and response automation that spans the cloud control plane, workloads and identities. A complete capability usually covers:
- Control plane telemetry: AWS CloudTrail, Azure Activity and Entra ID logs, Google Cloud Audit Logs, and Kubernetes audit logs, collected from every account and region.
- Workload runtime telemetry: process, file and network activity from virtual machines, containers and serverless functions, often collected with eBPF-based sensors or agentless snapshots.
- Identity signals: sign-ins, token issuance, role assumptions, workload identity federation events and service account key usage.
- Network and data signals: VPC flow logs, DNS logs, storage access logs and WAF events.
- Context: asset inventory, posture findings, vulnerability data and data classification, so an alert on a public, vulnerable workload with access to sensitive data is ranked above the same alert in a sandbox.
- Response actions: automated or one-click containment such as revoking sessions, disabling keys, quarantining workloads, and snapshotting disks for forensics.
The Playbook: Building CDR Step by Step
Step 1: Centralize and Protect Your Logs First
Detection is impossible without evidence, and the Threat Horizons finding about log deletion makes log integrity a first-order concern. Enable organization-wide audit logging through AWS Organizations trails, Azure diagnostic settings applied by policy, and Google Cloud aggregated sinks. Send logs to a dedicated security account or project that workload administrators cannot modify. Apply object lock or retention locks to the archive, and alert on any attempt to stop, delete or reconfigure logging. Include data access logs for your most sensitive stores even though they cost more.
Step 2: Prioritize Identity-Centric Detections
Even with vulnerability exploitation rising, almost every cloud attack eventually becomes an identity problem: the attacker uses or steals credentials to move laterally and escalate. Start with detections such as:
- Creation of new access keys, service account keys or federated credentials outside your deployment pipelines.
- Role assumption chains that cross accounts unexpectedly or reach administrative roles.
- Changes to trust policies, OIDC provider configurations or workload identity pools.
- Sign-ins or API calls from infrastructure or geographies never seen for that identity.
- Disabling of security services, guardrails or logging.
- Mass enumeration calls typical of reconnaissance, such as listing all buckets, secrets or roles in a short window.
Use the native threat detection services, Amazon GuardDuty, Microsoft Defender for Cloud and Google Security Command Center, as a baseline. They are tuned against provider-wide telemetry you cannot see yourself. Then add custom detections that encode your own environment: which pipelines are allowed to create keys, which accounts should never talk to each other.
Step 3: Add Workload Runtime Detection Where It Matters
Container and virtual machine runtime sensors detect behaviors that control plane logs cannot: a web server spawning a shell, a container writing to a binary directory, outbound connections to mining pools, or a process reading the instance metadata service and then calling cloud APIs. Deploy runtime detection first on internet-facing workloads and on Kubernetes clusters that run CI/CD tooling, since both feature prominently in recent incident reporting. Open-source engines such as Falco and commercial CNAPP sensors both work; what matters is that their alerts land in the same pipeline as your identity detections.
Step 4: Correlate Into Stories, Not Alerts
Analysts lose the race when they investigate disconnected signals. Build correlation that links a runtime alert on a pod to the service account it uses, the cloud role that account can assume, and the API calls made with that role in the following minutes. Modern CNAPP and SIEM platforms increasingly do this automatically, and many now use AI assistants to summarize the resulting timeline. Treat those summaries as accelerators, not verdicts, and make sure the underlying evidence is one click away.
Step 5: Automate Containment for High-Confidence Scenarios
Decide in advance which scenarios justify automatic action and which require a human. Good candidates for automation are those where the action is reversible and the false-positive cost is low:
- Disabling an access key that is used from an unknown network immediately after creation.
- Revoking sessions and requiring re-authentication for an identity showing impossible travel plus privilege changes.
- Isolating a container or instance that connects to known cryptomining infrastructure, after taking a disk snapshot.
- Re-enabling logging that was disabled and paging the on-call engineer.
Implement these with SOAR tools, serverless functions triggered by events, or the response features of your CNAPP. Test them in a non-production account and log every automated action for audit.
Step 6: Build Forensic Readiness
Ephemeral infrastructure destroys evidence by design. Prepare a forensic account with tooling, pre-approved roles that can snapshot volumes and copy them across accounts, and runbooks for memory capture where your platform supports it. Define how long to retain container images and build artifacts so you can reconstruct what was running. The goal is to be able to answer, after an incident, exactly what the attacker accessed, which matters both for remediation and for regulatory reporting deadlines under regimes such as NIS2, DORA and the SEC disclosure rules.
Step 7: Measure and Rehearse
Track mean time to detect, mean time to triage and mean time to contain for cloud incidents separately from other incident types. Run purple-team exercises that replay realistic cloud attack paths, such as a vulnerable web application leading to metadata credential theft and lateral movement, and measure each stage against your targets.
In the cloud, the attacker’s first hour determines the outcome. Centralize tamper-resistant logs, detect identity abuse early, and automate the containment steps you already know you will take.
Operating Model: Who Does What
Tooling fails when nobody owns the space between the cloud platform team and the SOC. Cloud incidents need people who understand both attacker behavior and how IAM policies, VPCs and Kubernetes RBAC actually work. A workable operating model typically assigns responsibilities like this:
- Cloud security engineering owns log architecture, sensor deployment, preventive guardrails and the catalog of automated response actions.
- Detection engineering writes and tests cloud detections as code, maps them to MITRE ATT&CK cloud techniques, and retires noisy rules.
- The SOC triages cases, runs playbooks and escalates, with a named cloud specialist on each shift or on call.
- Platform and application teams are on the hook for remediating root causes, such as patching, removing excess permissions or redesigning trust relationships, within agreed service levels.
Smaller organizations rarely have all four functions in-house. A common pattern is to keep ownership of guardrails and remediation internally while using a managed detection and response provider for 24/7 triage, provided that provider has genuine cloud expertise and can execute your response actions rather than only forwarding alerts. Whatever the split, document escalation paths and decision rights for disruptive actions, such as shutting down a production workload, before an incident forces the question at 3 a.m.
Hypothetical Worked Example: From Vulnerable App to Contained Incident
Imagine a hypothetical retailer running a customer portal on Kubernetes in a public cloud. A critical vulnerability in a web framework is disclosed on a Monday; the patch is scheduled for the next sprint. On Wednesday an attacker exploits it.
Without CDR, the first sign might be a cloud bill alert days later showing GPU instances running in an unused region. With the playbook in place, the sequence looks different. Within seconds, the runtime sensor flags the web container spawning an unexpected shell and downloading a binary. The correlation engine links the pod to its workload identity and notes that the identity can assume a role with permission to launch instances. Within minutes, a control plane detection fires as that role attempts to create access keys. Because both signals involve the same identity, the SOAR playbook automatically snapshots the pod’s node, cordons it, revokes the role’s active sessions and disables the newly created keys. The on-call analyst receives a single case with the timeline, confirms the activity, and coordinates an emergency WAF rule and patch. The post-incident review adds a preventive control: the workload identity loses permission to create keys entirely.
Choosing Tools: Native, CNAPP or SIEM-Centric
There are three common architectures, and many organizations combine them:
- Cloud-native services such as GuardDuty, Defender for Cloud and Security Command Center offer quick coverage and provider-scale threat intelligence, but correlation across multiple clouds requires extra work.
- CNAPP-centric CDR combines posture context, runtime sensors and cloud log analysis in one graph, which makes prioritization and correlation strong, though SOC teams may still need to integrate it with their main case management.
- SIEM or security data lake-centric approaches give analysts one place to hunt across cloud, endpoint and SaaS, but require more detection engineering to match the cloud context a CNAPP provides out of the box.
Whatever you choose, insist on three properties: coverage of every account and cluster, the ability to attach asset and identity context to each alert, and programmable response actions.
Pitfalls to Avoid
- Collecting logs from production accounts only, leaving development and CI/CD accounts, which attackers love, unmonitored.
- Treating cryptomining alerts as low priority. Mining is often the visible symptom of an access path that could be used for data theft.
- Building automation that cannot be reversed or audited, which erodes trust and leads teams to switch it off.
- Relying on AI-generated alert summaries without validating them against raw evidence.
- Ignoring cost. Data access logs and runtime telemetry can be expensive; tier storage and filter noise rather than turning sources off.
Outlook: Where CDR Is Heading
Over the next few years, expect CDR to become more autonomous and more identity-driven. AI-assisted triage is already common in leading platforms, and agentic response, where software proposes and executes containment within defined guardrails, is the next step. At the same time, the growth of non-human identities and AI agents with cloud credentials means detections will increasingly focus on behavior of machine identities rather than people. Regulators are also raising expectations for tamper-resistant logging and rapid incident reporting, which turns forensic readiness from a nice-to-have into a compliance requirement.
Conclusion
Cloud detection and response is the counterpart to posture management, not a replacement for it. The organizations that keep pace with today’s attackers secure their logs first, focus detections on identity abuse, add runtime sensors where exposure is highest, correlate signals into stories, and automate the first containment steps. None of this requires a perfect toolset; it requires clear priorities, tested playbooks and a willingness to measure response in minutes.
How Hanoi Technology Can Help
Hanoi Technology helps organizations design cloud logging, detection engineering and automated response playbooks, and can operate them as a managed service.