The last cloud threat detection demo I sat through opened with an ingestion number. Forty billion CloudTrail events a month, rendered as a live counter, and the account executive let it tick for a few seconds before moving on.
I asked the question I now open every one of these calls with: when a stolen access key gets used against a correctly configured bucket, what fires, and what does an analyst see? The answer was a saved filter in the log explorer. I'd been about to budget for a search bar as detection.
Cloud threat detection means identifying suspicious or malicious activity across control-plane, identity, data-plane, and workload-runtime telemetry, then routing the evidence into an owned response workflow while containment can still reduce harm.
In many of the demos I've sat through, what gets shown under that name turns out to be configuration scoring, log storage, or a saved search rather than tested behavior-based detection with an owned response path. The buyer's job is to tell them apart before signature.
In brief:
- A threat detection is triggered by time-bound activity that may indicate active misuse or attacker behavior. A posture finding evaluates a persistent exposure and can exist without any suspicious activity taking place.
- Identity telemetry is a high-value detection surface because valid-account abuse can resemble ordinary administration. CrowdStrike's 2026 Global Threat Report, which analyzes 2025 activity, found that valid-account abuse accounted for 35% of cloud incidents; across CrowdStrike detections, 82% were malware-free.
- I do not treat broad attack-technique mappings as proof that an enterprise security information and event management (SIEM) system has working detections. Storing cloud logs and detecting in them are different budgets.
- Detection reduces dwell time only when it feeds an owned response path: a staffed queue, a playbook, clear authority, and containment actions that can be executed within the attacker's window. Mandiant's 2025 dwell-time findings put global median dwell time at 11 days, with a 10-day median for internally discovered incidents and 26 days for incidents first reported by an external entity.
What cloud threat detection actually means
Detecting active attacks, not scoring configuration
I use cloud detection and response (CDR) for tools designed to detect and respond to threats inside cloud environments, while cloud security posture management (CSPM) discovers and helps resolve cloud infrastructure misconfigurations.
My working distinction is state versus behavior. Posture management evaluates the current or recent configuration state of cloud resources. Threat detection evaluates time-bound activity in audit, identity, data-plane, network, and runtime telemetry that may indicate active misuse or attacker behavior.
A persistent misconfiguration is usually a posture finding, but the event that creates, weakens, or changes that configuration can itself be a behavioral detection when its context indicates suspicious or unauthorized activity.
I laid out the posture-versus-detection model in the FoS piece on CSPM: posture asks whether the environment is configured to resist attack, while detection asks whether something is attacking it right now. CSPM can identify a security group that exposes RDP to the world, but that doesn't amount to a detection strategy for compromised applications and account credentials.
A public bucket with no reader is a posture finding. A burst of unusual GetObject activity from a never-seen principal against that bucket is a detection candidate, but only if S3 object-level CloudTrail data events, or an equivalent source, are enabled, retained, and ingested; that qualifier is what a threat detection line item should actually pay for.
What generates real detections in the cloud
I organize cloud detection around four core evidence domains: control plane, identity, data plane, and workload runtime. Network and CI/CD telemetry often provide critical supporting context, especially for egress, lateral movement, and deployment-pipeline abuse, though they're not the focus of this piece. Each domain has collection gaps that vendors tend to mention only after the proof-of-concept (PoC) bill arrives.
Control plane, identity, data plane, and workload runtime
On the control plane, cloud management events carry the identity, action, source, and client context needed to fire on account creation, policy attachment, logging impairment, or a security group opened to the internet.
The data plane is where I start the budget conversation: object access, function invocation, database activity, and resource-level operations as separate collection items, verifying that activity such as a secret read is visible.
For GCP data-access logging, I make deliberate coverage decisions across services. For EKS control-plane audit logging, I confirm the source is on, routed, retained, and included in the ingestion budget before pod access, RBAC changes, and service-account activity count as covered.
Identity is one of the highest-value cloud detection surfaces, because valid-account abuse can resemble ordinary administration. CrowdStrike's 2026 Global Threat Report, which analyzes 2025 activity, found that valid-account abuse accounted for 35% of cloud incidents, and 82% of CrowdStrike detections were malware-free.
Microsoft's 2025 data likewise shows identity-based attacks increasing and device-code phishing becoming a material technique. Identity telemetry should be collected and correlated alongside control-plane, data-plane, and runtime evidence rather than treated as a secondary enrichment source.
In Entra ID, I test whether device-code authentication is visible and distinguishable from normal sign-ins. In Okta, I test whether successful multi-factor authentication (MFA) resets by an unusual administrator or from an unfamiliar location create a usable alert.
Workload telemetry rounds it out: for Kubernetes, I use audit logs for API activity and require separate visibility into commands, processes, file access, and network connections inside a running container. I've left runtime specifics to the companion FoS piece on cloud runtime detection; a vendor covering only management events has control-plane visibility, not full coverage of identity, data-plane, and workload-runtime activity.
Runtime signals versus posture findings
A composite hybrid-cloud ransomware scenario shows why posture and detection findings shouldn't be treated as the same kind of operational work, even when a platform displays them in one console. The posture finding can exist for months: a non-human synced identity holding a highly privileged Entra ID role with no MFA.
The detection exists only during the minutes when an actor resets the on-premises password, an unexpected sync-driven privilege change follows, a new trust modification appears, data access spikes, and destructive storage activity begins. A posture tool may score the first condition for months without seeing that sequence.
Vendors often assume the required telemetry is available. For S3 ransomware using attacker-supplied encryption keys, I test object-level operations rather than assume management events alone are enough.
For a customer-owned SIEM or detection pipeline, that means testing what still fires if the managed CloudTrail trail, export, or downstream routing is stopped, and treating a StopLogging test as one resilience check, not proof against every failure mode in downstream forwarding or storage.
For a provider-native service such as GuardDuty, verify coverage by use case. AWS documents that GuardDuty consumes CloudTrail management events through an independent duplicated stream, so a customer-managed trail doesn't by itself control that analysis, but you still need to confirm Region and account coverage, supported data sources, and protection plans for the detections being claimed.
Why so much cloud threat detection is just logging
Cloud environments generate enormous log volume, but volume isn't the same as detection. Most cloud detection budgets die somewhere between log ingestion and an alert anyone actually acts on.
Alerts without response aren't the detection that matters
Broad log ingestion does not produce equivalent detection coverage, and I do not count telemetry mapped across attack techniques as coverage until its rules fire and connect to response. On the operations side, I still see SOCs send incoming data into a SIEM without a retrieval or management plan and rely on endpoint alerts as their primary response trigger.
In cloud reviews, I check that GuardDuty is enabled in every in-scope AWS Region and account and that centralized administration covers the intended organizations. I also verify the data sources needed for the vendor's claims are turned on, since partial coverage such as CloudTrail on management events only or Security Hub controls suppressed without a compensating detection is common.
The Snowflake-related breaches show the victim-side risk of exposed credentials. Mandiant reported that stolen credentials became its second most common initial infection vector overall in 2024, accounting for 16% of investigations, a direct reason to fund identity detection as its own line item rather than an afterthought bundled into logging.
The MDR trap: managed response that's really just forwarding
When I was evaluating managed detection and response (MDR) providers for a cloud-heavy environment, I pulled a month of the incumbent's escalations and sorted them by source. Most were GuardDuty findings forwarded with a severity number and a link; not one carried the CloudTrail event chain, the calling identity's history, or a proposed action.
For me, an MDR that forwards provider-native findings without evidence, context, or an action recommendation hasn't demonstrated managed response.
I've written separately about hygiene getting rebadged as cloud-native security; the logging version is subtler, because the data really is there, and an alert nobody can act on inside the attacker's window is a log entry with a notification attached.
Where detection has to become response
The statistics in the last section aren't abstract. Every one of them describes time an attacker spent inside an environment before a human acted on what the detection layer already knew.
What response adds, and where CDR earns its name
CrowdStrike's 2026 report says average eCrime breakout time, the interval from initial access to lateral movement, fell to 29 minutes in 2025, with the fastest observed breakout at 27 seconds. Mandiant's 2025 findings put global median dwell time at 11 days, up from 10 days the year before, with a 10-day median for internally discovered incidents and 26 days for incidents first reported by an external entity.
My AWS runbooks pre-authorize narrowly scoped API actions before an incident, including disabling a compromised access key and revoking active role sessions. AWS implements session revocation through a deny policy for sessions created before a specified timestamp, and the policy takes about 30 seconds to fully propagate, so the runbook also includes impact checks, audit logging, and a recovery path.
Moving an instance onto a quarantine security group is another option, while in Entra ID, I use sign-in-session revocation as one containment step and verify remaining access separately.
In GCP, my runbook requires a verified procedure for disabling an exposed service-account key once the exposure is confirmed. That's where CDR earns its name over CSPM or a SIEM alone: it connects the detection to one of these actions with the evidence chain attached, not just to a ticket.
Pre-authorization defines before the incident which high-confidence containment actions can be recommended, approved with one click, or executed automatically with rollback and auditability. Only the last category receives autonomous write access.
How to evaluate cloud threat detection you can trust
I use one PoC design regardless of who's selling: provider-native services such as GuardDuty and Microsoft Defender, runtime-led products such as Sysdig, and cloud-detection products such as Vectra AI, whose collection, correlation, and response boundaries differ.
What to make a vendor prove in a demo
In an isolated, disposable AWS PoC account with logging-restoration verified, I use an AWS-focused emulator such as Stratus Red Team to test whether stopping the CloudTrail trail, backdooring an IAM role's assume-role policy, and suspicious role assumption produce usable evidence; the alert should name the caller, source IP, and target role ARN.
In a separate Entra test tenant, I run a controlled, approved identity-administration exercise to validate alerts on privileged-role assignment, then check the ATT&CK mapping without assuming that label alone validates real correlation or response.
For each test I score whether an alert fires with the event chain and the emulator's user agent visible in the evidence. I then add a controlled credential-abuse chain: simulate access to an instance-profile role's temporary credentials, use that role to access S3 objects, and test whether the product links the identity context to the resulting data-plane activity. The pass condition is one incident that preserves the role, source workload, and object-access events.
What the PoC has to prove beyond the demo
The PoC should establish whether the product can correlate control-plane, identity, and workload evidence into an attack narrative; sample findings and screenshots test presentation, while real detonations test telemetry availability, normalization, detection logic, correlation, evidence retention, and routing. Repeat at least one test after changing the principal, source network, and target resource so the vendor cannot pass with a pre-staged exact match.
Two more asks: require a time-to-alert number and make the vendor explain the telemetry pipeline behind it, rather than accepting a sub-second claim without confirming the evidence came through the same source.
And require a response action executed live against a resource the sales engineer didn't pre-stage, because controlled demos do not reproduce attacker behavior. A half-day sandbox exercise is more useful than an ingestion counter: it tests telemetry, detection logic, evidence quality, routing, and response under conditions the vendor didn't stage.
Frequently asked questions about cloud threat detection
What is cloud threat detection?
Cloud threat detection is identifying an attacker's activity in cloud control plane, identity, data-plane, and workload telemetry while that activity is happening. It runs on streamed logs such as CloudTrail, Entra ID sign-in logs, Okta System Log, and runtime sensor data, and a detection fires on behavior: a never-seen principal assuming a role, a shell spawning in a container, a trail being stopped. Configuration reports describe exposure; detections describe attacker actions against it.
How is it different from CSPM and CNAPP?
CSPM evaluates configuration state through cloud-provider APIs and related inventory sources, then reports exposures or policy violations, with no attacker required and no clock running. CNAPP bundles posture, workload protection, and increasingly a runtime component. Cloud threat detection evaluates activity that may indicate active misuse across that runtime and identity layer, and a CNAPP that started as a posture tool may or may not do it well. The practical test is whether it can detect active behavior across multiple telemetry domains rather than merely place posture and runtime findings in the same console.
What is CDR (cloud detection and response)?
CDR is the detection layer plus a connected containment path: revoking IAM role sessions, invalidating Entra ID refresh tokens, disabling exposed service-account keys, isolating an instance or pod. It matters because some attacker actions unfold faster than a conventional analyst queue, and a CDR product should show the evidence chain for a detection and connect it to an approved action, whether native, one-click, policy-automated, or executed through an integrated response platform.
What telemetry do you need for cloud threat detection?
My minimum telemetry plan starts with control-plane audit logs such as CloudTrail, Azure Activity Log, and GCP Admin Activity, along with identity logs such as Entra ID sign-in and audit records, Okta System Log, and OAuth consent activity. It also needs workload telemetry such as Kubernetes audit logs plus a runtime sensor for in-container activity. I budget separately for data-plane, resource, and cluster sources that may need explicit enablement or additional ingestion, including CloudTrail data events, GCP Data Access logs, Azure resource diagnostic logs, and EKS control-plane logs. I verify exfiltration and secret-read scenarios against those sources rather than assume the program covers them.