Why 90% of Cloud Security Alerts Are Financially Irrelevant

Security tools are built to answer one question: how much damage could an attacker do from here?

That question measures blast radius. The potential scope of access. The worst-case data exposure. The maximum privilege an attacker could reach if they moved laterally from this foothold.

Blast radius is the right question for an advanced persistent threat. It is the wrong question for the attack that is actually hitting your AWS account right now.

Most cloud attacks are not APTs. They are automated scripts scanning for exposed credentials and misconfigured compute, looking for one thing: resources to hijack. MITRE ATT&CK technique T1496, Resource Hijacking, describes this precisely: adversaries may leverage the resources of compromised systems to complete resource-intensive tasks, such as cryptocurrency mining. The attacker does not want your data. They want your GPU instances, burning your budget at $8/hour per instance while your security queue is sorted by severity.

That is the burn rate problem. Blast-radius triage is not built to catch it.

Two Different Questions, Two Different Urgencies

Blast radius asks: what could happen?

Burn rate asks: what is happening right now, and what is it costing per hour?

A GuardDuty finding on an over-permissioned IAM role in a dev environment has a high blast radius. If an attacker exploited it, they could potentially access production data. But if there is no active exploitation, no anomalous API calls, and no corresponding cost signal, the blast radius is theoretical. The urgency is real but not immediate.

A Medium finding on an EC2 instance showing unusual outbound connections, combined with a 300% spike in data transfer costs and NAT Gateway egress to an external IP, has a lower blast radius score. But the burn rate is active. Money is leaving the account right now. The incident is not theoretical.

Under a severity-only triage model, the high-blast-radius dev finding gets investigated first. The active burn-rate incident waits.

That ordering is wrong for the category of attack that dominates cloud environments.

What Automated Cloud Attacks Actually Look Like

The threat model most security tools are calibrated for is a human attacker making deliberate, targeted decisions. The threat model that actually dominates cloud compromises is different.

Automated scanners continuously probe public endpoints and leaked credential databases. When a valid AWS access key appears in a public GitHub repository, automated tooling finds it within minutes. The Verizon 2025 Data Breach Investigations Report found that stolen credentials were involved in 88% of basic web application attacks. The speed of exploitation for exposed cloud credentials is measured in minutes, not days.

Once a valid key is found, the script does not pause to assess blast radius. It immediately calls ec2:RunInstances in multiple regions, launches GPU instances, and starts mining. The financial damage begins within the first hour. The GuardDuty finding may not surface for several hours depending on log ingestion latency.

The cost signal arrives first. Every time.

This is the category of attack where burn rate is the primary signal and blast radius is secondary. The attacker is not trying to exfiltrate data. They are trying to run compute on your bill. The financial signal is not a side effect of the attack. It is the attack.

The Triage Model That Catches Both

The fix is not to stop using severity. Blast radius matters for the attacks where data exfiltration or privilege escalation is the goal. The fix is to add burn rate as a parallel signal that can override severity-based ordering when active financial damage is confirmed.

A practical two-signal triage model:

Signal 1: Severity (blast radius) Standard GuardDuty, CSPM, and SIEM findings sorted by potential impact. This is your existing queue. Keep it.

Signal 2: Active burn rate Any security finding where the associated resource or IAM principal has a confirmed cost anomaly in the same time window moves to the top of the queue, regardless of severity classification.

The second signal requires one connection that most teams have not built: routing AWS Cost Anomaly Detection alerts to the same channel as security findings. When both signals arrive for the same resource within the same time window, that is your highest-priority investigation. Not because the blast radius is highest. Because the burn rate is active and confirmed.

Fact-check: Does this mean a Medium finding with a cost signal outranks a Critical finding without one?

For the category of automated resource hijacking attacks, yes. A Critical finding on a stopped instance with no active traffic and no cost anomaly is not an active incident. A Medium finding on a running instance with $2,000 in unexpected charges in the last 24 hours is. The AWS Security Incident Response Guide recommends scoping and containing active incidents before investigating potential ones. Burn rate is the clearest signal that an incident is active.

The Financially Irrelevant Majority

The 90% figure is an observation, not a precise measurement. The point is structural.

Most security queues contain a large number of findings on resources that are stopped, misconfigured but not exploited, or in environments with no active traffic. These findings are real. They represent genuine risk. They are not costing money right now.

The financially relevant minority shares a structure: active resources, active API calls, active network traffic, and a cost signal that confirms something is happening. These are the findings where the burn rate clock is running.

Sorting by severity alone distributes attention evenly across both categories. Adding burn rate as a triage signal concentrates attention on the category where the financial damage is active and compounding.

The 90% that are financially irrelevant are not a problem to solve. They are context that makes the financially relevant 10% visible.

Try CostObserver. Read-only access, no credit card, connects in minutes. Or explore the demo without signing up.