Consider a workload that passed its posture checks at deployment. Days later, a stolen credential is used to invoke a cloud API, a new payload reaches the workload, and the system begins communicating with attacker-controlled infrastructure. The configuration may still look compliant. The behavior does not.
Cloud Detection and Response (CDR) is a cloud-native security approach for identifying, analyzing, and responding to active threats across cloud workloads, services, infrastructure, and control-plane activity. It continuously examines runtime and cloud telemetry for evidence of malicious or suspicious behavior, then gives security teams the context needed to investigate and act.
CDR is the runtime detection layer of a modern Cloud-Native Application Protection Platform (CNAPP). It complements preventive controls such as Cloud Security Posture Management (CSPM), vulnerability management, identity security, and infrastructure-as-code scanning. Those controls reduce the chance of compromise. CDR addresses the moment when prevention is bypassed, an unknown threat appears, or legitimate access is abused.
The practical distinction: posture tells you what could happen; CDR supplies evidence about what is happening.
Cloud operations compress time. Resources appear and disappear quickly, identities call APIs instead of walking through a fixed network perimeter, and one application may span virtual machines, containers, Kubernetes, storage, managed services, and multiple cloud accounts. An investigation that begins with a single alert can require evidence from several control planes and teams.
A Secure Configuration Does Not Prove a Secure Runtime
CSPMCSPM can identify an exposed storage service, an overly permissive role, or a control that drifted out of policy. It cannot, by itself, determine that a workload is beaconing to command-and-control infrastructure, a cryptominer is consuming compute, or a compromised identity is making unusual API calls. Runtime monitoring closes that gap.
Cloud Attacks Cross Technical Boundaries
A cloud incident rarely remains a single host event. An attacker may enter through a vulnerable workload, assume a role, query cloud services, move laterally, and reach sensitive data. CDR therefore needs more than endpoint telemetry. It needs signals from network traffic, workload and container behavior, files and processes, identity activity, cloud audit logs, and provider-native detections.
Alert Volume Is Not the Same as Risk Clarity
A SOC can receive thousands of technically valid signals and still miss the event that matters. The useful question is not simply whether behavior is suspicious. It is whether the behavior affects an exposed or business-critical asset, intersects with an exploitable weakness, advances an attack path, or threatens sensitive services. Context turns a detection into a decision.
CDR products vary, but an effective operating model follows a consistent lifecycle. Each stage should reduce uncertainty and move the team closer to a justified action.
1. Collect cloud-native telemetry. Ingest relevant signals from network traffic and flow logs, workload and container activity, files and processes, cloud activity and audit logs, identity events, APIs, and provider-native security services. Coverage should match the organization’s actual architecture, not a generic checklist.
2. Detect suspicious behavior. Apply threat intelligence, behavioral analytics, rules, machine learning, or deep learning to find known and unknown threats. Useful detections include malware downloads, ransomware, cryptomining, port scans, brute-force attempts, lateral movement, command-and-control beaconing, unauthorized access, and anomalous API use.
3. Prioritize with cloud and business context. Enrich the event with the affected resource, owner, exposure, vulnerabilities, permissions, asset criticality, related identities, and potential blast radius. Severity without this context can send the team toward the loudest alert instead of the greatest business risk.
4. Investigate and validate. Reconstruct the sequence: what triggered the finding, which entities were involved, whether the behavior is still active, how the attacker could move, and what evidence supports the conclusion. Map detections to frameworks such as MITRE ATT&CK when that helps analysts compare behavior and coordinate response.
5. Respond with guardrails. Route the incident to the SOC, contain a workload, block or restrict communication, revoke or constrain access, rebuild from an approved image, patch the exploited weakness, or create an owner-specific remediation task. Automate repeatable, low-risk actions; require approval where containment could disrupt production.
6. Verify and improve. Confirm that malicious activity stopped, the exposure was removed, and the workload returned to an expected state. Feed the lesson into posture policy, detection tuning, response playbooks, and development controls so the same path is harder to reuse.
Example: a port scan from a production VM is more urgent when the same VM is internet exposed, carries an exploitable vulnerability, and can reach a sensitive service. CDR supplies the runtime signal; cloud exposure context explains why the team should act now.
CSPM and CDR are complementary controls. Treating one as a substitute for the other creates a blind spot either before or during an attack.
| Question | CSPM | CDR |
|---|---|---|
Primary question | Is the cloud configured securely? | What malicious or suspicious activity is happening now? |
Primary evidence | Configuration, policy, inventory, and compliance data | Network, workload, container, file, process, identity, API, and cloud activity telemetry |
Time orientation | Preventive and continuous posture assessment | Real-time or near-real-time runtime detection and investigation |
Typical finding | An internet-exposed resource or excessive permission | Beaconing, malware, cryptomining, lateral movement, or suspicious API use |
Typical action | Fix the configuration or permission | Investigate, contain, route, remediate, and verify |
The stronger operating model connects them. If CSPM finds an internet-exposed workload with excessive privileges, the team should reduce that exposure. If CDR later detects suspicious communication from the same workload, the prior posture findings become investigation context and the runtime event becomes evidence that the theoretical risk may be active.
A product comparison should test the complete detection-to-response workflow. Ask vendors to demonstrate how the solution handles a realistic incident in your architecture, including what the analyst sees, which evidence supports the finding, and how the response is verified.
Qualys CDR is an integral part of Qualys TotalCloud, an AI-powered CNAPP that brings cloud posture, workload, identity, container, code, data, SaaS, AI, and runtime risk into a shared operating model. The value of that connection is not merely a common dashboard. It is the ability to use runtime evidence to improve prioritization, validate exposure, and drive an accountable response.
Deep Learning AI Detects Known and Unknown Runtime ThreatsQualys CDR uses Deep Learning AI to analyze network traffic and malicious file activity for known and unknown threats without relying solely on traditional signatures. It can identify activity associated with malware and variants, ransomware, cryptominers, port scanning, unauthorized access, lateral movement, and command-and-control communication, including subtle beaconing patterns.
That distinction matters because a new payload or newly generated command-and-control domain may not yet appear in a signature or reputation feed. Behavioral evidence can surface the activity while it is still novel. Rule-based detection remains useful for well-defined cloud events; the objective is complementary coverage, not a claim that one technique replaces all others. See how Qualys applies Deep Learning AI to cloud detection
Multiple Signals Provide Layered Cloud Visibility For AWS environments, current Qualys TotalCloud capabilities combine CDR appliance-based eBPF runtime detection, network flow-log analysis, Amazon GuardDuty event integration, and AWS CloudTrail ingestion. CloudTrail detections cover suspicious API activity, unauthorized access attempts, and anomalous user behavior. TotalCloud also brings container runtime process, network, and file events into the CDR investigation experience and maps CDR findings to MITRE ATT&CK techniques. Review current TotalCloud CDR enhancements
The same CDR model extends across AWS, Azure, and Google Cloud; including Google Cloud detections from traffic, flow logs, and activity logs. This layered model is important because network behavior, workload behavior, and control-plane activity reveal different parts of an attack. Coverage should be validated by provider and workload type during solution design.
TruRisk Insights Adds Exposure and Business ContextA runtime alert becomes more useful when the analyst can see the surrounding risk. TotalCloud’s TruRisk Insights correlates runtime threats with vulnerabilities, misconfigurations, identity risk, exploitability, exposure, and asset criticality. Attack Path visualization helps teams understand how risk can propagate through connected resources and where a remediation can break the chain.
This is the core Qualys point of view: runtime evidence should influence exposure management. A CDR finding is not just an incident to close. It is proof that can change priority, validate an attack path, identify the most consequential control failure, and guide a durable fix. Learn how TotalCloud visualizes attack paths
CDR Strengthens Every Stage of the TotalCloud Lifecycle
Existing SOC Workflows Remain Part of the Design CDR should improve the SOC’s operating model, not force a parallel one. Qualys supports near-real-time forwarding of malicious file and network runtime events through webhooks to customer-managed SIEM and SOC platforms. Qualys CDR findings can also be integrated with Microsoft Sentinel so analysts can correlate cloud runtime evidence with other enterprise signals and use established incident workflows. Review the Qualys CDR webhook integration • Review the Microsoft Sentinel integration
1. Start with the cloud asset and ownership map. Know which accounts, subscriptions, projects, clusters, workloads, services, and identities are in scope. Record the business owner and criticality so a detection has an accountable destination.
2. Define the threats and decisions that matter. Prioritize scenarios such as credential abuse, malicious payloads, cryptomining, command-and-control traffic, lateral movement, and suspicious cloud API activity. For each, document the evidence threshold and expected action.
3. Design the telemetry mix deliberately. Map each threat scenario to the signals that can reveal it. Test for blind spots across providers, managed services, ephemeral containers, and encrypted or restricted network paths.
4. Integrate CDR with the SOC before an incident. Establish routing, severity mapping, escalation, evidence retention, on-call ownership, and communication with cloud and application teams. Practice the handoff in a tabletop or controlled test.
5. Automate in stages. Begin with enrichment and ticketing, then add low-risk containment. Use approvals for actions that could interrupt production, affect customer data, or remove access from a legitimate administrator.
6. Tune with outcomes, not alert counts alone. Track time to detect, time to validate, time to contain, repeat incidents, false-positive effort, and whether remediation removed the attack path. A lower alert count is useful only if coverage and response quality remain strong.
7. Feed runtime lessons back into prevention. When CDR confirms how an attacker entered or moved, update posture policies, identity controls, vulnerability priorities, golden images, and development guardrails.
CDR matters because cloud risk does not end when a deployment passes a posture check. Security teams need to know when a workload, identity, network path, container, or cloud service begins behaving in a way that indicates active exploitation or compromise.
The strongest CDR programs connect that evidence to the rest of cloud security. Qualys TotalCloud combines CDR with TruRisk Insights, posture, workload, identity, container, code, data, SaaS, and attack-path context so teams can move from detection to a defensible risk decision. The objective is straightforward: identify the live threat, focus on the business risk it creates, contain it with appropriate guardrails, and eliminate the exposure that allowed it.
Next step: see how Qualys TotalCloud CDR detects active cloud threats and connects runtime findings to prioritized response.
What is Cloud Detection and Response?
Cloud Detection and Response (CDR) is a cloud-native approach for continuously detecting, investigating, and responding to active threats across cloud workloads, services, infrastructure, identities, APIs, and control-plane activity.
Is CDR part of a CNAPP?
Yes. CDR commonly serves as the runtime detection and response layer of a Cloud-Native Application Protection Platform. In Qualys TotalCloud, CDR works with posture, workload, identity, container, code, data, SaaS, AI, and risk-prioritization capabilities.
What is the difference between CDR and CSPM?
CSPM evaluates cloud configurations, policies, and compliance to find preventable exposure. CDR monitors runtime and cloud activity for suspicious or malicious behavior. CSPM asks what could be exploited; CDR helps determine what may be happening now.
What threats can CDR detect?
CDR can detect activity such as malware, ransomware, cryptomining, command-and-control communication, port scanning, brute-force attempts, lateral movement, unauthorized access, suspicious workload behavior, and anomalous cloud API activity. Exact coverage depends on the product, telemetry, provider, and deployment.
How does AI improve cloud detection and response?
AI and machine learning can analyze large volumes of runtime and cloud telemetry for patterns that signatures and static rules may miss. Qualys uses Deep Learning AI for known and unknown malware and network threat detection, while rules remain useful for well-defined events such as suspicious cloud API activity.
Does CDR replace a SIEM or SOC?
No. CDR supplies cloud-native detections and investigation context. A SIEM or SOC can correlate those findings with identity, endpoint, network, and business signals and coordinate the broader incident response. Qualys supports CDR event forwarding through webhooks and integration with Microsoft Sentinel.
How does TruRisk improve CDR prioritization?
TruRisk Insights connects runtime findings with factors such as vulnerabilities, exploitability, misconfigurations, identity exposure, asset criticality, and attack paths. This helps teams distinguish an isolated signal from an active threat affecting an attackable, high-value asset.
Can CDR automate response?
CDR can trigger automated or guided actions such as enrichment, ticketing, escalation, access changes, network controls, workload containment, or rebuilding. Organizations should automate repeatable, low-risk actions and require human approval where a response could disrupt production.