# Myth: "My Detection System Is Enough" > Why cloud detection arrives too late, stays blind to IAM attack paths, and leaves a window wide enough to lose everything. * URL: * Author: Jean-Yves Pasquier * Published: 2026-06-24 * Tags: myths, cloud security, detection Ransomware attacks have become a billion-dollar industry. It is an evolving, hyper-profitable business that hits companies of all sizes and activities. In this post we return to our series on the most dangerous myths in cloud cybersecurity. So far we have visited [why every company is a target](https://blog.paniam.cloud/posts/why-smbs-are-prime-targets-in-the-ransomware-age.md), [why cloud providers alone can't always have your back](https://blog.paniam.cloud/posts/cloud-has-my-back.md), and [why backups and a willingness to pay a ransom are not a robust strategy](https://blog.paniam.cloud/posts/i_can_pay_the_ransom.md). Our fourth myth might be the most dangerous one yet: the belief that a strong detection system is enough to keep a business safe. Many cloud teams have a detection stack. CloudTrail is on, threat detection is enabled, logs flow into a SIEM, the dashboards glow green, and alerts fire when something looks wrong. So the reasoning goes: if an attacker shows up, we will see them, and we will respond. A smoke detector is a wonderful thing. It is also not a sprinkler, and it is certainly not a fireproof wall. It tells you the building is burning. It does nothing to stop the fire, and it cannot see the frayed wiring behind the drywall that started it. Treating cloud detection as your security strategy makes the same mistake: it confuses being _told_ about a disaster with being _protected_ from one. ## Detection Is Necessary. It Is Not Sufficient. Let's be clear up front: this post is not an argument against detection. You should use CloudTrail, threat detection, and a SIEM. Logging and monitoring are foundational, and a mature response capability has saved countless organizations from a bad day becoming a catastrophic one. But detection is the _last_ line of defense, not the _only_ one. It answers the question "did something bad just happen?" It does not answer "could something bad happen, and have I closed that door?" And what does that door lead to? It might lead to assets that are essential to your business. In the cloud, the gap between those two questions is where breaches live. Three structural blind spots make detection, on its own, a dangerous thing to rely on: it is blind to **time**, blind to **authorization paths**, and blind to **scale**. ## Blind Spot #1: Detection Is Late by Design Cloud detection is not real time, and the cloud providers say so themselves. AWS's own documentation states that [CloudTrail "typically delivers logs within an average of about 5 minutes of an API call. This time is not guaranteed."](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html) Read that twice. Five minutes is the _average_, and there is no service-level guarantee behind it. Independent measurement by [Tracebit](https://tracebit.com/blog/how-fast-is-cloudtrail-today-investigating-cloudtrail-delays-using-athena) found typical delivery closer to two and a half minutes, but with a long tail: in their data, individual events occasionally arrived **more than sixteen hours late**, with no SLA to lean on. It gets slower the moment you rely on the smarter features. CloudTrail Insights, the built-in anomaly detection feature, "may take **up to 36 hours**" to begin delivering events on a trail, and **up to 7 days** in CloudTrail Lake. Amazon GuardDuty exports a brand-new finding within about five minutes, but by default it aggregates _updates_ to an ongoing finding on a [six-hour cycle](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings_eventbridge.html). An attack that is actively unfolding can sit inside a single six-hour bucket before your tooling ever registers the attacker's next move. Now compare that to how fast attackers move. CrowdStrike's [2025 Global Threat Report](https://www.crowdstrike.com/en-us/blog/crowdstrike-2025-global-threat-report-findings/) measured the average eCrime "breakout time", the time from initial compromise to moving laterally, at **48 minutes**, down from 62 the year before. The fastest breakout they recorded was **51 seconds**. Your detection pipeline is buffering for minutes; the attacker is done in under one. And with the weaponization of frontier models, one can expect attackers to move even faster in the coming months. And this is just the per-event latency. At the macro level, the [IBM Cost of a Data Breach 2024](https://www.ibm.com/think/insights/whats-new-2024-cost-of-a-data-breach-report) report found the average breach still took **258 days** to identify and contain, rising to **292 days** for breaches that started with stolen credentials. By the time most breaches are detected, the attacker has had nine months. Detection is, by its nature, past tense. It tells you what already happened. The only question is how far in the past. ## Blind Spot #2: Detection Sees Events, Not Paths Even with instant, perfect logs, detection would still miss an entire category of risk, because it watches _events_, and the most dangerous cloud risks are _paths_. Consider a single API call: [`iam:UpdateAssumeRolePolicy`](https://blog.paniam.cloud/posts/lateral-movement-trust-policy.md). In a log, it is one line among thousands, indistinguishable from the legitimate infrastructure automation that calls it every day. Nothing about the event says "an attacker just rewrote a production role's trust policy to trust an account they control." The same is true of [`iam:PassRole` and `iam:AttachUserPolicy`](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/), the classic privilege-escalation primitives, and of a cross-account `sts:AssumeRole`. Each call, on its own, looks routine. The risk is not in any single event. It is in the _reachability_ that the configuration creates: who can become whom, and what they can touch once they get there. A low-privilege identity that can modify a trust policy can grant itself a role it was never meant to hold, and an [identity-based deny in your account does nothing to stop a principal in an account you do not control](https://blog.paniam.cloud/posts/lateral-movement-trust-policy.md). That path exists in your environment right now, before anyone takes it. It will not generate a single alert until the day it is exploited, and by then it is an incident, not a finding. This is why detection cannot carry the load alone. You cannot detect a path that nobody has taken yet. But you _can_ compute it in advance, by modeling the authorization graph instead of watching the event stream. The distinction matters more every year: CrowdStrike found that **79% of detections in 2024 were malware-free**, dominated by hands-on-keyboard identity abuse, exactly the activity that looks like legitimate use to a detection engine. This is where the real exposure sits: not in the intrusion itself, but in the configuration that made it reachable. A misconfigured trust policy, an over-broad `PassRole`, a forgotten cross-account trust. Detection is aimed at the break-in. The door was left open at the configuration layer, where detection does not look. ## Blind Spot #3: The Window Is Wide Enough to Lose Everything Here is where the first two blind spots compound into something fatal. Cloud networks are absurdly fast, and that bandwidth serves the attacker as well. Security researchers at [Resourcely](https://medium.com/resourcely/gone-in-60-seconds-518eea6b2b1e) measured what cloud-native exfiltration actually looks like. Running an optimized, massively parallel copy tool on an instance in the same region as the target data, they hit **over 800 files per second and 8 gigabytes per second**. At that rate, the researchers write, an exposed 1 TB bucket "could all end up in the attacker's AWS account in just over 2 minutes." Crucially, when the attacker copies from a victim account into an account they control in the same region, they add, "the transfer would be processed entirely from inside the cloud provider's data centers": no traffic crosses the public internet, where a network monitoring tool might catch it. Then comes the line that should end the debate. At that speed, the researchers note, an attacker "can exfiltrate around **2TB of data before the event log is even delivered to your security tooling.**" The exfiltration is not racing your detection. It has already finished before detection starts. This is not theoretical. Trend Micro documented [ransomware that abused Amazon S3 Transfer Acceleration](https://www.trendmicro.com/en_us/research/24/j/fake-lockbit-real-damage-ransomware-samples-abuse-aws-s3-to-stea.html) to move stolen files to attacker-controlled buckets, using a legitimate cloud feature precisely because it blends into normal traffic. The same enormous bandwidth that makes the cloud productive makes a cross-account heist a two-minute operation. ## What This Looks Like in Practice Put the three blind spots on one timeline. A single leaked access key, a single attacker, and your detection stack running exactly as designed: ```text T+0:00 Attacker uses a leaked key, enumerates identities and roles. Detection: nothing delivered yet. T+0:30 Attacker calls iam:UpdateAssumeRolePolicy, adding an account they control to a privileged role's trust policy. Detection: looks like routine automation; event not yet delivered. T+1:00 Cross-account sts:AssumeRole from the attacker's account. Detection: identity-based denies in your account do not apply. T+1:30 Assumed role lists buckets, starts an 8 GB/s copy to an attacker bucket in the same region. Detection: still inside the provider network, nothing on the wire. T+3:30 ~1 TB exfiltrated. The data is gone. T+5:00 The earliest CloudTrail events may now be landing in the bucket. The SIEM has not ingested them. No alert has fired. T+48:00 Industry-average "breakout time." Here, the data has been gone for 44 minutes. Hours later A GuardDuty finding surfaces, an analyst triages it, and the investigation begins on a breach that is already over. ``` Every box in that timeline is your detection working correctly. The problem is not a misconfigured SIEM or a missed alert. The problem is that detection, by construction, only starts its clock after the attacker has already stopped theirs. ## Detection Is the Last Line, Not the Only One The myth is not "detection is useless." Detection is essential, and you should invest in it. The myth is that detection is _enough_, that watching for bad things to happen is the same as preventing them. In the cloud, where logs arrive in minutes without a guarantee, where the real risk lives in authorization paths that never trip an alert, and where terabytes leave before the first event is delivered, that belief leaves a window an attacker can drive a truck through. The fix is not more detection. It is adding the layer that operates _before_ the clock starts: knowing which attack paths exist in your environment and closing them before anyone takes advantage of them. This is what we built PanIAM to do. Instead of watching the event stream, we model your cloud's authorization graph: who can assume which roles, who can modify a trust policy or pass a role, and what each of those identities can ultimately reach. We surface the privilege-escalation and cross-account paths that detection is blind to, and we show you the blast radius of a compromised identity, so you can cut the path before it becomes a 2 AM incident. Detection tells you about the fire after the building is gone. We help you find the frayed wiring behind the wall, and fix it while the lights are still on. > 📩 Want to see the attack paths your detection stack can't? Let's map your > cloud's authorization graph together, and close the doors before anyone walks > through them.